Re^2: Determining the minimum representable increment/decrement possible?

Following up on the excellent answer davido came up with, and using the code he gave, 1.9041105342991877e+258 gives the binary value 0100001110111101100010001110100001001000001011011111000110101110

Going the other way, the binary string just obtained is displayed as 1.90411053429919e+258

Increasing the least significant bytes to see when we see a change,

0100001110111101100010001110100001001000001011011111000110101110 - sti
+ll 1.90411053429919e+258

1100001110111101100010001110100001001000001011011111000110101110 - sti
+ll 1.90411053429919e+258

1110001110111101100010001110100001001000001011011111000110101110 - sti
+ll 1.90411053429919e+258

1111001110111101100010001110100001001000001011011111000110101110 - sti
+ll 1.90411053429919e+258

1111101110111101100010001110100001001000001011011111000110101110 - sti
+ll 1.90411053429919e+258

1111111110111101100010001110100001001000001011011111000110101110 - fin
+ally 1.9041105342992e+258
[download]

Why did we have to go in 6 bits from the end to see a change in the floating point representation?

There are 53 bits in the mantissa, and if the last 6 don't show, that means that there are only 47 being used for the display in floating point. log(2^47)/log(10) gives us about 14 significant digits. This is what the answers above seem to indicate.

I think that the answer is going to depend on how many digits the machine displays for a given IEEE754 value. For my machine, I need to change the value by roughly about 10^-14 from its original value to see a change.

P.S. I hope I transcribed everything correctly here. As always, I have to use another machine to run the perl.

Comment on Re^2: Determining the minimum representable increment/decrement possible? Download Code

Replies are listed 'Best First'.
Re^3: Determining the minimum representable increment/decrement possible? by ExReg (Priest) on Jun 15, 2016 at 18:52 UTC
Excuse me while I clear out my cranial flatus. I was not forcing the maximum precision. I was using the default. If I add the `printf "%25.32"` as dvido had I would have gotten slightly different results: `0100001110111101100010001110100001001000001011011111000110101110 - 1.9 +041105342991886e+258 1100001110111101100010001110100001001000001011011111000110101110 - 1.9 +041105342991888e+258` [download] It would appear that in this case, 1.9041105342991887e+258 is not possible to store. Using all 53 bits of mantissa, I still get about 15.95 digits instead of the 14. Each case will be different and require converting to binary, twiddling the bits, and seeing what you get.	[reply] [d/l] [select]
Re^4: Determining the minimum representable increment/decrement possible? by davido (Cardinal) on Jun 15, 2016 at 19:36 UTC
It would appear that in this case, 1.9041105342991887e+258 is not possible to store. That is because 1.9041105342991887e+258 does not fit into `m/2^n`, and therefore cannot be represented precisely in base 2. You would need a couple more bits to push the rounding error further out, but that's just kicking the can down the road. In other words, the binary representation of this floating point value results in a non-terminating sequence, much as 1/3rd results in a non-terminating sequence in base 10. Dave	[reply] [d/l]
Re^5: Determining the minimum representable increment/decrement possible? by ExReg (Priest) on Jun 15, 2016 at 21:47 UTC
Very true. But since perl is using double precision on my machine, you will never get that number. You would need quad precision to represent 1.9041105342991887e+258.	[reply]
Re^6: Determining the minimum representable increment/decrement possible? by BrowserUk (Patriarch) on Jun 15, 2016 at 21:52 UTC


Think about Loose Coupling
	PerlMonks