Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 days ago.
This post was edited and submitted for review 8 days ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
We analyzed a program which was supposedly used for cracking some cryptographic algorithms.
During the investigations we determined that the program input size can be varied in a wide range and for N-bit input the program result is also always N bit long. Additionally, we found that the program working time depends significantly on input length N, especially when N is greater than 10-15. Our test also reveals that the program working time depends only on Input length, not the input itself.
During our tests, we fixed the following working times with an accuracy of one hundredth of a second):
N=2-16.38 seconds
N=5 - 16.38 seconds
N = 10 - 16.44 seconds
N = 15 - 18.39 seconds
N = 20 - 1 minute 4.22 seconds
We also planned to test the program for N = 25 and N = 30, but for both cases the program didn't finish within half an hour and was forced to terminate it. Finally, we decided for N = 30 to not terminate the program, but to wait a little bit longer. The result was 18 hours 16 minutes 14.62 seconds. We repeated the test for N = 30 and it gave us exactly the same result, more than 18 hours. Tasks: a) Find the program working times for the following three cases - N = 25, N = 40 and N = 50. b) Explain your result and solution process.
At first I thought of finding a linear relation between N and time taken, t. Obviously that failed.
Then I realized that the t for N=2 and N=5 are nearly identical (here they are identical because they have been rounded to two digits after the decimal). Which emphasizes that the change in t only becomes more apparent when N>=10.
So, I tried to write t as a function of N, since t only depends on the size of the input.
Seeing the exponential growth my first idea was to write it as f(t)=Ce^N+k; where C and k are constants and e is euler's number.
That approach does not hold up. Afterwards I thought of trying powers of 2 because it's a computer question but I'm kind of lost.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 1 year ago.
Improve this question
If I started with a sha256 hash such as
3f46fdad8e5d6e04e0612d262b3c03649f4224e04d209295ef7de7dc3ffd78a7
and rehashed it continuously (without salting):
i) What is the shortest time it would take before it started cycling in a loop or back onto the same value if at all?
ii) If it did cycle back on itself, could we assume that it had been cracked?
iii) How long would this take using modern GPU cracking techniques?
iv) If all the intermediary hashes were recorded in some kind of rainbow tables - presumably all the hashes within that cycle would be compromised?
v) What is to stop someone computing these cycles and offering cracks to sha256 hashes - likewise for other hashing protocols...
For Extra marks - What is the probability this question would be asked in this forum 60 billion years ago?
If values generated by sha256 can be assumed to be distributed uniformly and randomly, then there exists with probability 1−1/e (about 63%) a 256-bit sequence whose sha256 hash is equal to itself. If so, the minimum sequence length is one.
On the other hand, based on the pigeonhole principle, we know that the sequence must repeat after no more than 2256 iterations. This doesn't say anything about the brokenness of sha256.
The maximum cycle length is 2256 ≈ 1.16×1077 iterations. If you can evaluate 1012 hashes per second, then working your way through all possible hashes would take you about 1065 seconds (about one quindecillion times the age of the earth). Even if you're fortunate enough find a loop in a tiny fraction of that time, you're still liable to be waiting for trillions of years.
Good luck with that. If every atom in our galaxy was used to store a separate hash value, you would run out of space after storing less than one billionth of the total number of hashes. (Source: number of atoms in milky way galaxy ≈ 1068)
See 3 and 4
A similar question was asked about 9 years ago.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
At the moment I'm playing with the LSM303DLHC accelerometer/magnetometer/thermometer.
This is its datasheet: http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00027543.pdf
Everything is working quite well, but I don't know how to interpret the output values. The datasheet (page 9) says something like "1 mg/LSB" (no, it's not milligramm :D) about the linear acceleration sensitivity in my configuration. What the hell should that mean? Same with temperature sensor output change (8 LSB/°C) and magnetic gain setting (1100 LSB/gauss), only the other way around.
For example, what to do with this accelerometer output: 16384? That is my measured gravitational acceleration.
Now I got the trick. There are several things on this MEMS you have to know, but which are not mentioned in the datasheet:
The accelerometer's output register is just 12 bits and not 16 bits, so you need to right-shift the value by 4 and multiply it with 0,001 G. Furthermore it's little-endian.
The magnetometer's output register is 16 bits, but big-endian. Furthermore the vector order is (X|Z|Y) not (X|Y|Z). To calculate the correct value you need to devide X and Y by 980 gauss⁻¹, while it's 1100 gauss⁻¹ for Z.
The temperature sensor works, but it's not calibrated. So you can use it to measure temperature change, but no absolute temperatures. It's also just 12 bits, but big-endian and you have to devide the output by 8 C⁻¹.
With that Information it's possible to use the LSM303DLHC. But who the hell invented this? "Let's build a new accelerometer, magnetometer and thermometer in one package and screw the user up by mixing word length and endianness up without mentioning it in the datasheet."
LSB/unit or Unit/LSB is the factor(called sensitivity) with which you have to multiply the raw sensor data.
Say Sensor A has X,Y and Z registers ,
the values coming in each of the registers needs to be Divided/multiplied with the LSB/unit or Unit/LSB factor.
This is because the data sheet says # the particular fullscale you will have this much sensitivity(LSB/unit or Unit/LSB)
for LSB/Unit :
x lsb means - 1 unit
1 lsb means - 1/x unit
value lsb(value in the register) = (1/x)*(value in the register) - Apply unitary method here.
similarly for Unit/LSB you have to multiply the sensitivity.
You can build Accelerometer,Magnetometer or Temperature sensor or may be Gyro-meter in one module, but what if a customer/User wants only one sensor?
Rgds,
Rp
The datasheet is definitively unclear regarding the interpretation of the Acceleration registers.
Genesis Rock solution assume it is 12-bits, which works. (Another solution is to assume gain is 16 mg/LSB instead of 1 mg/LSB, but as the last 4 bits of the accelerations seem to always be zeros the former solution makes more sense).
But both for the temperature and acceleration, if you take into account only the 12 most significant bits. The last two bits are still also always zero, so the effective resolution would be 10-bits which is confusing.
I also can't make sense of the temperature reading unless there is an unknown offset not specified in the datasheet.
I hope others can confirm they are getting the same results.
Regarding the 12 bit output of the accelerometer: there is a high-resolution flag on control register 4. It's off by default and there's no information on what high resolution means. I'm guessing that it might enable 16 bit output. Also on control register 4 is a flag to set the endianness of the accelerometer output. It's little endian by default. The data sheet is pretty weak overall.
The simple and embarrassing fact is that none of the responses have hit the target of the question.
The result is buried in another parameter that is supplied in the data sheet: the sensitivity.
for example the FXAS21002C for 2000 dps sensitivity is 62.5 mdps/LSB (=0.0626 dps/LSB).
the zero offset is 25 LSB thus the value in dps units is 0.0625 * 25 = 1.5625 dps
the same IMU has another sensitivity for 250 dps which is 7.825 mdps/LSB (=0.007825 dps/LSB) and since the offset is also 25 LSB then the calculation will expose the real value of 0.0078125 * 25 = 0.1953 dps
the example can be found here: https://learn.adafruit.com/comparing-gyroscope-datasheets/overview
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
I have a function
f(x)=(1^1)*(2^2)*(3^3)*.....(x^x)
i have to calculate (f(x)/(f(x-r)*f(r)))modulo c
i can calculate f(x) and (f(x-r)*f(r)).
assume f(x) is a
and f(x-r)*f(r) is b.
c is some number that is very larger. ``
so i how can calculate (a/b)%c
your f(x) is just ᴨ (PI cumulative multiplication) squared
it is hard to write it in here so i will deifine g(x0,x1) instead
g(x0,x1)=x0*(x0+1)*(x0+2)*...*x1
so:
f(x)=g(1,x)^2
computing h(x,r,c)=f(x)/(f(x-r)*f(r))%c
when you rewrite it to g() you get:
h(x,r,c)=((g(1,x)/(g(1,x-r)*g(1,r)))^2)%c
now simplify (and lower magnitude) as much as you can
so compute sqr as last (no need to have in sub-results)
get rid of duplicate therms
there are two options get rid of g(1,x-r) or g(1,r)
choose what is better for you I would chose whichever is bigger
so if (x-r>r) then:
h(x,r,c)=(g(x-r+1,x)/g(1,r)^2)%c
else:
h(x,r,c)=(g(r+1,x)/g(1,x-r)^2)%c
some math tweaks
you should compute both therms a,b (from (a/b)%c) parallel
when both can be divided by any of first few primes then divide them booth to keep the magnitude low
something like::
`if ((a&1==0)&&(b&1==0)) { a>>=1; b>>=1; } // dividing by prime = 2 ... this is usually enough
but if your magnitudes are very big then may be you should add also some like 3,5,7,...
but always measure the performance drop and stop if it drops too much
if x is big and r is small
then compute b first
and while computing a
in addition to primes check also if the sub-result is divisible also by b
if it is then divide a by b and add the result to the final division result
some speed boost
you can compute partial a,b
and start testing the divisibility only if booth have magnitudes bigger then some treshold
also you can make the computation waiting for each other
so if a>1000000 then wait until the b is also so big or whole
and do the same also in revers (if b>100000 ....)
the bigger treshold the better speed but you are limited by your integer implementation
if using bigints then you should use treshold smaller then halve the bits of the base number ...
Hope I did not make some silly math mistake...
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
At the moment I'm playing with the LSM303DLHC accelerometer/magnetometer/thermometer.
This is its datasheet: http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00027543.pdf
Everything is working quite well, but I don't know how to interpret the output values. The datasheet (page 9) says something like "1 mg/LSB" (no, it's not milligramm :D) about the linear acceleration sensitivity in my configuration. What the hell should that mean? Same with temperature sensor output change (8 LSB/°C) and magnetic gain setting (1100 LSB/gauss), only the other way around.
For example, what to do with this accelerometer output: 16384? That is my measured gravitational acceleration.
Now I got the trick. There are several things on this MEMS you have to know, but which are not mentioned in the datasheet:
The accelerometer's output register is just 12 bits and not 16 bits, so you need to right-shift the value by 4 and multiply it with 0,001 G. Furthermore it's little-endian.
The magnetometer's output register is 16 bits, but big-endian. Furthermore the vector order is (X|Z|Y) not (X|Y|Z). To calculate the correct value you need to devide X and Y by 980 gauss⁻¹, while it's 1100 gauss⁻¹ for Z.
The temperature sensor works, but it's not calibrated. So you can use it to measure temperature change, but no absolute temperatures. It's also just 12 bits, but big-endian and you have to devide the output by 8 C⁻¹.
With that Information it's possible to use the LSM303DLHC. But who the hell invented this? "Let's build a new accelerometer, magnetometer and thermometer in one package and screw the user up by mixing word length and endianness up without mentioning it in the datasheet."
LSB/unit or Unit/LSB is the factor(called sensitivity) with which you have to multiply the raw sensor data.
Say Sensor A has X,Y and Z registers ,
the values coming in each of the registers needs to be Divided/multiplied with the LSB/unit or Unit/LSB factor.
This is because the data sheet says # the particular fullscale you will have this much sensitivity(LSB/unit or Unit/LSB)
for LSB/Unit :
x lsb means - 1 unit
1 lsb means - 1/x unit
value lsb(value in the register) = (1/x)*(value in the register) - Apply unitary method here.
similarly for Unit/LSB you have to multiply the sensitivity.
You can build Accelerometer,Magnetometer or Temperature sensor or may be Gyro-meter in one module, but what if a customer/User wants only one sensor?
Rgds,
Rp
The datasheet is definitively unclear regarding the interpretation of the Acceleration registers.
Genesis Rock solution assume it is 12-bits, which works. (Another solution is to assume gain is 16 mg/LSB instead of 1 mg/LSB, but as the last 4 bits of the accelerations seem to always be zeros the former solution makes more sense).
But both for the temperature and acceleration, if you take into account only the 12 most significant bits. The last two bits are still also always zero, so the effective resolution would be 10-bits which is confusing.
I also can't make sense of the temperature reading unless there is an unknown offset not specified in the datasheet.
I hope others can confirm they are getting the same results.
Regarding the 12 bit output of the accelerometer: there is a high-resolution flag on control register 4. It's off by default and there's no information on what high resolution means. I'm guessing that it might enable 16 bit output. Also on control register 4 is a flag to set the endianness of the accelerometer output. It's little endian by default. The data sheet is pretty weak overall.
The simple and embarrassing fact is that none of the responses have hit the target of the question.
The result is buried in another parameter that is supplied in the data sheet: the sensitivity.
for example the FXAS21002C for 2000 dps sensitivity is 62.5 mdps/LSB (=0.0626 dps/LSB).
the zero offset is 25 LSB thus the value in dps units is 0.0625 * 25 = 1.5625 dps
the same IMU has another sensitivity for 250 dps which is 7.825 mdps/LSB (=0.007825 dps/LSB) and since the offset is also 25 LSB then the calculation will expose the real value of 0.0078125 * 25 = 0.1953 dps
the example can be found here: https://learn.adafruit.com/comparing-gyroscope-datasheets/overview
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm asking this question here because I believe this is more of a programmatic issue than anything else.
I'm using a TI-84 Plus Sliver Edition calculator that contains logical operators that can test for less-than, greater-than, and equality. I find that when I input the expression:
2^34 == 2^34 - 1
it gives me a surprising 1 for true. It's worth mentioning that my calculator can't precisely output the result of 2^34. Rather, it uses the exponential notation for it and any other powers greater than 33. Is this a potential factor in the boolean output?
Furthermore, the equality test only returns true if the second expression is subtracting by 1 to 9. When the number is >= 10 it then correctly returns false.
Could it be a rounding error? Why is this expression returning true?
Your calculator cant keep track of numbers that large.
Every calculator has a set level of precision (lets say 10 digits). Every answer the calculator gives is rounded so that the answer has that many digits, then it shifts the decimal place as much as it needs to in order to make the number big or small (in your case very large).
Your number is so large that when you subtract 1, that causes a change after the 10th digit. This then gets rounded back to what you started with, and then compared. So naturally, it thinks they are the same number (to the precision it is capable of).