Determining the minimum representable increment/decrement possible?

BrowserUk has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Determining the minimum representable increment/decrement possible? by davido (Cardinal) on Jun 15, 2016 at 15:52 UTC
This post is based on the following theory: <theory>Since Perl's floating point precision is constrained by what can be stored in an NV, the minimal change to a floating point value that Perl should be able to accommodate would be obtained by twiddling the least significant bit in an NV.</theory> Here's an example (which may be completely bogus) of what I'm getting at. Unfortunately my understanding of Perl's internal representation of a float within an NV is limited, so this approach is at best just intended to explore the possibility. `use strict; use warnings; my $fp = 1/2; # m/2^n may be represented perfectly in base 2. printf "%25.32g\n", $fp; my $p = pack 'F', $fp; my $b = unpack 'b', $p; print "$b\n"; $b =~ s/(.)/$1 ? 0 : 1/e; print "$b\n"; my $np = pack 'b', $b; my $nfp = unpack 'F', $np; printf "%25.32g\n", $nfp;` [download] The output: `0.5 0000000000000000000000000000000000000000000000000000011111111100 1000000000000000000000000000000000000000000000000000011111111100 0.50000000000000011102230246251565` [download] So it would appear that the least significant change that can be represented in an NV that was holding the decimal floating point value of 0.5 would be 0.00000000000000011102230246251565. In my example, I started with a value that I knew could be represented precisely in native base-2 format, and essentially ended up with another number that can be stored precisely in native base-2. It just happens to be a number that is rather ugly in base 10. Apologies if this is getting off into the wrong field of weeds, or if my example inadequately implements the theory I put forth, but the topic seemed interesting and I thought I'd post my exploration. Dave	[reply] [d/l] [select]
Re^2: Determining the minimum representable increment/decrement possible? by ExReg (Priest) on Jun 15, 2016 at 17:52 UTC
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.	[reply] [d/l]
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
Re^5: Determining the minimum representable increment/decrement possible? by ExReg (Priest) on Jun 15, 2016 at 21:47 UTC
Some notes below your chosen depth have not been shown here
Re^2: Determining the minimum representable increment/decrement possible? by anonymized user 468275 (Curate) on Jun 15, 2016 at 16:38 UTC
But it still comes down to the definition of floating point. There are fifteen or sixteen decimal digits maximum in Perl's floating point implementation, so stagnation will occur at either the sixteenth or seventeenth significant digit, irrespective of the exponent. Having said that there is a limit to the absolute value of the exponent before Perl cries 'Inf'. Curiously, it will also cry Inf when approaching zero which seems a bit flaky to me, when it could just zero the thing. Update: Inf as in infinity. Ambiguity being a famous line from an old film, 'Carry on Cleo', where Caesar cries: 'Infamy, infamy, they've all go it in fer me' One world, one people	[reply]
Re^2: Determining the minimum representable increment/decrement possible? by BrowserUk (Patriarch) on Jun 15, 2016 at 19:18 UTC
Is your perl compiled to use long doubles for NV? I ask because my perl is using normal doubles and I get different results to you: `printf "% 25.32g\n", unpack 'F', pack 'b*', '1000000000000000000000000 +000000000000000000000000000011111111100';; 0.50000000000000011` [download] (In general I think you've hit on at least part of the solution to my quest; though it is complicated by the production of denormals; which I'm still trying to wrap my head around; so I ll get back to you once I've wrapped my brain around them.) With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :) In the absence of evidence, opinion is indistinguishable from prejudice. Not understood.	[reply] [d/l]
Re^3: Determining the minimum representable increment/decrement possible? by ikegami (Patriarch) on Jun 15, 2016 at 20:14 UTC
I think this is due to differences in the C library. You're using a Windows build, right? I think this has been unified in 5.22.	[reply]
Re: Determining the minimum representable increment/decrement possible? by Marshall (Canon) on Jun 15, 2016 at 15:40 UTC
You have one heck of a complicated question! There are additional complications with the Intel FPU in terms of reproducible results. The FPU uses 80 bits internally for its calculations so its using more bits for intermediate calculations than went in. You may find this article of interest: Intel FPU Precision . As opposed to your commonly quoted link above, this one is more like: "What most computer scientists probably don't need to know about floating point"! However some of this may be required for your question. I hope this "how the guts work" article helps in at least what the hardware is doing part.	[reply]
Re^2: Determining the minimum representable increment/decrement possible? by BrowserUk (Patriarch) on Jun 15, 2016 at 16:07 UTC
The FPU uses 80 bits That's true of the old 8087 FPUs (and later on-chip compatible units), but (almost) no compiler more than say 7 or 8 years old still uses the old 80-bit fpr0 .. fpr8 registers and associated instructions. My cpu is ~10 years old, and it has MMX (only uses the lower 64-bits of the 87-style registers. ) and SSE, SSE2, SSE3, SSSE3, which use the lower 64-bits of the 128-bit xmmm register set. (The D compiler provides a 80-bit fp native type.) With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :) In the absence of evidence, opinion is indistinguishable from prejudice. Not understood.	[reply]
Re: Determining the minimum representable increment/decrement possible? by pryrt (Abbot) on Jun 15, 2016 at 22:14 UTC
Basically, to determine what the smallest delta for a given floating-point, decompose that value's ieee representation into sign, fraction, and exponent. My perl's NV is double-precision (53bit precision): from MSB to LSB, sign bit, 11 exponent bits, and 52 fractional bits (plus an implied 1), for sign(1+fract_bits/2^52)(2exp), where (which my perl's NV is), the smallest change would be 2(-52+exp). So you should just need to know your exp for the current representation (not forgetting to subtract 1023 from the 11bit exponent number). If your NV is more precise (lucky you), just adjust it appropriately. What I'm unsure about is whether if you take a denormal number, and add a small fraction, whether it re-normalizes it before doing the addition, or whether it's limited by its existing denormal exponent. The last time floating point came up (in Integers sometimes turn into Reals after substraction), I started work on a module that will expand an ieee754 double-precision float into sign(1+fract)2^exp, based on the internal representation. Unfortunately, that module isn't ready for prime-time. But I'll still link you to a Expand.pm development copy, along with debug.pl (which will eventually become my .t file(s) -- but for now, shows you how I currently can use my functions). This may or may not help you delve deeper into the problem. Right now it's focused on 53-bit precision... and hampered by the fact that I want it to work on a machine at $work that is limited to perl 5.6, so I cannot use the `>` modifier for pack/unpack) but the same ideas should work for you... update: change urls to a more "permanent" location	[reply] [d/l]
Re^2: Determining the minimum representable increment/decrement possible? by BrowserUk (Patriarch) on Jun 15, 2016 at 22:38 UTC
Basically, to determine what the smallest delta for a given floating-point, decompose that value's ieee representation into sign, fraction, and exponent. My perl's NV is double-precision (53bit precision): from MSB to LSB, sign bit, 11 exponent bits, and 52 fractional bits (plus an implied 1), for sign(1+fract_bits/2^52)(2exp), where (which my perl's NV is), the smallest change would be 2(-52+exp). So you should just need to know your exp for the current representation (not forgetting to subtract 1023 from the 11bit exponent number). If your NV is more precise (lucky you), just adjust it appropriately. That's a nice insight. Thankyou. If I need to go this route, that is almost certainly the way to do it. However, I'm not certain of this yet, but I think my OP question may not actually be required. The problem appears to be -- I'm still struggling with x64 assembler to try and confirm this -- that I'm encountering a lot of denormal numbers; and if I can avoid them, the underlying problem that my OP was an attempt to solve, goes away. And the problem with avoiding denormal numbers is that the purpose of the code that is generating them is a Newton-Raphson iteration to converge on zero. The exact place where denormals raise their ugly heads. The solution may be (maybe?) to add a constant (say 1 or 2) to both sides of the equations and converge to that number instead. (Not sure about that; but it might work :) I started work on a module that will expand an ieee754 double-precision float into sign(1+fract)2^exp, based on the internal representation. You might find Exploring IEEE754 floating point bit patterns. (and as you're working with 5.6 , the version at Re^2: Exploring IEEE754 floating point bit patterns.) interesting or even useful. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :) In the absence of evidence, opinion is indistinguishable from prejudice. Not understood.	[reply]
Re^3: Determining the minimum representable increment/decrement possible? by pryrt (Abbot) on Jun 15, 2016 at 23:35 UTC
Wow! Your convergence criteria are a lot more stringent than mine ever have been, if you're trying to get below a 1bit shift for a 53-bit precision number. (In anything I've tried to converge, I've never cared about less than ~1ppm.) Your offset technique to avoid the denormals sounds promising. And thanks for the links; I'll keep them bookmarked when I get a change to work on my module more.	[reply]
Re^4: Determining the minimum representable increment/decrement possible? by BrowserUk (Patriarch) on Jun 16, 2016 at 00:34 UTC
Re^3: Determining the minimum representable increment/decrement possible? by pryrt (Abbot) on Jun 30, 2016 at 23:50 UTC
I'm sure you've moved beyond this... but for future searchers: While trying to implement some ULP-manipulating routines in my Data::IEEE754::Tools development (which I used to call Expand.pm), I was googling to fix a bug, and was led to Data::Float, which actually has most of the tools I was trying to implement in my module. Using that CPAN module, I was able to write a sub which found the ULP for any finite value (normal or denormal); it returns INF or NAN when one of those was passed. use warnings; use strict; use feature qw/say/; use Data::Float qw/pow2 float_parts float_hex significand_bits min_normal min_normal_exp min_finite min_finite_exp max_finite pos_zero neg_zero pos_infinity neg_infinity nan float_is_zero float_is_finite/; sub find_ulp($) { my $nv = shift; my $vh = float_hex($nv); if(!float_is_finite($nv)) { # INF or NAN say "ulp($nv:$vh) = $nv:$vh"; return $nv; } my $e = float_is_zero($nv) ? (min_finite_exp) : ( (float_parts($n +v))[1] - significand_bits ); my $uv = pow2($e); my $uh = float_hex($uv); say "ulp($nv:$vh) = $uv:$uh"; return $uv; } find_ulp($_) foreach (2.0, 1.0, 0.5, 0.16, max_finite, min_normal, min +_normal/2., min_finite, pos_zero, neg_zero , pos_infinity , neg_infin +ity , nan); __END__ ulp(2:+0x1.0000000000000p+1) = 4.44089209850063e-016:+0x1.000000000000 +0p-51 ulp(1:+0x1.0000000000000p+0) = 2.22044604925031e-016:+0x1.000000000000 +0p-52 ulp(0.5:+0x1.0000000000000p-1) = 1.11022302462516e-016:+0x1.0000000000 +000p-53 ulp(0.16:+0x1.47ae147ae147bp-3) = 2.77555756156289e-017:+0x1.000000000 +0000p-55 ulp(1.79769313486232e+308:+0x1.fffffffffffffp+1023) = 1.99584030953472 +e+292:+0x1.0000000000000p+971 ulp(2.2250738585072e-308:+0x1.0000000000000p-1022) = 4.94065645841247e +-324:+0x0.0000000000001p-1022 ulp(1.1125369292536e-308:+0x0.8000000000000p-1022) = 4.94065645841247e +-324:+0x0.0000000000001p-1022 ulp(4.94065645841247e-324:+0x0.0000000000001p-1022) = 4.94065645841247 +e-324:+0x0.0000000000001p-1022 ulp(0:+0.0) = 4.94065645841247e-324:+0x0.0000000000001p-1022 ulp(0:-0.0) = 4.94065645841247e-324:+0x0.0000000000001p-1022 ulp(Inf:+inf) = Inf:+inf ulp(-Inf:-inf) = -Inf:-inf ulp(NaN:nan) = NaN:nan [download]	[reply] [d/l]
Re^4: Determining the minimum representable increment/decrement possible? by syphilis (Archbishop) on Jul 01, 2016 at 01:09 UTC
Re^4: Determining the minimum representable increment/decrement possible? by BrowserUk (Patriarch) on Jul 04, 2016 at 14:21 UTC
Re^5: Determining the minimum representable increment/decrement possible? by BrowserUk (Patriarch) on Jul 04, 2016 at 15:01 UTC
Re: Determining the minimum representable increment/decrement possible? by syphilis (Archbishop) on Jun 16, 2016 at 13:18 UTC
For an Inline::C solution, the following works ok for me with gcc on Windows: `use strict; use warnings; use Inline C => Config => BUILD_NOISY => 1, ; use Inline C => <<'EOC'; double nxtafter(double in, double dir) { return nextafter(in, dir); } EOC my $pos_inf = (99 99) 99; my $neg_inf = -$pos_inf; my $next_down = nxtafter(1.9041105342991877e+258, $neg_inf); printf "%.16e\n", $next_down; my $next_up = nxtafter(-8.2727285363069939e-293, $pos_inf); printf "%.16e\n", $next_up; __END__ Outputs: 1.9041105342991875e+258 -8.2727285363069927e-293` [download] With the latest MS compiler that I have (14.00.40310.41) I need to replace "nextafter" with "_nextafter" in order to get the script to compile. But it then produces incorrect results anyway: `1.9041105342991884e+258 -7.9999999999999937e-293` [download] Perhaps a more recent MS compiler fares better. Cheers, Rob	[reply] [d/l] [select]
Re^2: Determining the minimum representable increment/decrement possible? by BrowserUk (Patriarch) on Jun 16, 2016 at 13:24 UTC
I'm probably being thick here, but where does nextafter() come from? With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :) In the absence of evidence, opinion is indistinguishable from prejudice. Not understood.	[reply]
Re^3: Determining the minimum representable increment/decrement possible? by syphilis (Archbishop) on Jun 16, 2016 at 14:03 UTC
... where does nextafter() come from? As pryrt noted, it's in math.h - which perl.h already (indirectly) includes. With my MS compiler, I found matches for the string "nextafter" in: `C:\_64\Platform_SDK\Include\crt\float.h C:\_64\Platform_SDK\Include\crt\fpieee.h C:\_64\Platform_SDK\Include\crt\math.h C:\_64\Platform_SDK\src\crt\float.h C:\_64\Platform_SDK\src\crt\fpieee.h` [download] Cheers, Rob	[reply] [d/l]
Re^3: Determining the minimum representable increment/decrement possible? by pryrt (Abbot) on Jun 16, 2016 at 13:43 UTC
it looks like it's in math.h -- I didn't know about it until syphilis's post, either... I love how much I learn here. :-)	[reply]
Re^3: Determining the minimum representable increment/decrement possible? by fullermd (Priest) on Jul 05, 2016 at 07:29 UTC
For completeness, `nextafter()` is specified as part of `math.h` in C99 (section 7.12.11.3 in the N1256 draft).	[reply] [d/l] [select]
Re: Determining the minimum representable increment/decrement possible? by syphilis (Archbishop) on Jun 16, 2016 at 09:34 UTC
Firstly, don't assume that perl will assign either of those values correctly. At around those precisions, it's not uncommon for perl to assign values that are off by (up to) a few ULPs. I would do it with Math::MPFR (though the real credit goes to the mpfr library): use strict; use warnings; use Math::MPFR qw(:mpfr); # Set $prec and $out_prec appropriately my $prec = 53; # NV has 53-bit significand # my $prec = 64; # NV has 64-bit significand # my $prec = 106; # NV has 106-bit significand # my $prec = 113; # NV has 113-bit significand Rmpfr_set_default_prec($prec); my $str1 = '1.9041105342991877e+258'; my $str2 = '-8.2727285363069939e-293'; my $obj1 = Math::MPFR->new($str1); my $obj2 = Math::MPFR->new($str2); Rmpfr_nextbelow($obj1); Rmpfr_nextabove($obj2); print "$obj1\n$obj2\n"; # To convert the objects to NVs: my $nv1 = Rmpfr_get_NV($obj1, MPFR_RNDN); my $nv2 = Rmpfr_get_NV($obj2, MPFR_RNDN); my $out_prec = 17; # 53-bit significand # my $out_prec = 21; # 64-bit significand # my $out_prec = 33; # 106-bit significand # my $out_prec = 36; # 113-bit significand $out_prec--; printf "%.${out_prec}e\n%.${out_prec}e\n", $nv1, $nv2; __END__ Outputs: 1.9041105342991875e258 -8.2727285363069927e-293 1.9041105342991875e+258 -8.2727285363069927e-293 [download] To put it glibly, we just need to increase/decrease the value by one ULP. Cheers, Rob	[reply] [d/l]
Re^2: Determining the minimum representable increment/decrement possible? by syphilis (Archbishop) on Jun 16, 2016 at 09:47 UTC
At around those precisions ... I meant "At around those exponents... ". I would have made this correction as an update to the original post .... but the option to make that update is seemingly currently unavailable. UPDATE: hippo has just pointed me to the thread where this recent change (which occurred while I was away) was discussed. ++ to BrowserUk for pushing for the option to re-instate the update box to its original location and ++ to jdporter for enabling that option. Cheers, Rob	[reply]
Re: Determining the minimum representable increment/decrement possible? by syphilis (Archbishop) on Jun 17, 2016 at 12:38 UTC
`$fp2 = -8.2727285363069939e-293;; printf "% 25.17g\n", $fp2;; -7.9999999999999948e-293 ### WTF? ###` [download] Hadn't noticed this before - a perl that produces that result is simply brainfucked. I can reproduce that garbage on a perl-5.18.0 that I built with my Platform_SDK compiler on Windows 7: `C:\>perl -le "printf '%.16e', -8.2727285363069939e-293;" -7.9999999999999948e-293` [download] Yet, according to the very same perl, the 2 values are entirely different: `C:\>perl -le "print scalar reverse unpack 'h', pack 'd<', -7.99999999 +99999948e-293;" 83465a792c83e3b6 C:\>perl -le "print scalar reverse unpack 'h', pack 'd<', -8.27272853 +63069939e-293;" 83498bf832dfdfab` [download] UIM, this is not perl's fault. (But I am mistaken - see UPDATE and UPDATE2.) Perls built (from the same source) with gcc on the same machine do not suffer this problem. I would not rely on the accuracy of any floating point result that such a perl produced. UPDATE: After some double-checking I have found that the mingw-w64 gcc-4.7.x x64 compilers built perl-5.18.x with exactly the same problem as the Platform_SDK compiler build. The problem went away with perl-5.20.0 onwards, but I don't know if that was because of changes to the perl source. I used later versions of gcc to build 5.20.0 onwards - and maybe that's what fixed the issue. UPDATE2: The problem with 5.18.0 is simply that perl assigns the wrong value to the NV - instead of assigning the hex format 834a6aec8f941351, it assigns 83498bf832dfdfab, which by my calculation is off by 245,141,108,700,070 ULPs. (Such inaccuracies are usually quite small, and I was thrown by the large size of this one.) Cheers, Rob	[reply] [d/l] [select]
Re^2: Determining the minimum representable increment/decrement possible? (Perl's scanf broken?) by BrowserUk (Patriarch) on Jun 17, 2016 at 13:41 UTC
Indeed. The previous post was done using 5.10.1; this is 5.22: `C:\Program Files>\Perl22\bin\perl.exe \perl22\bin\p1.pl printf "% 25.17g\n", -8.2727285363069939e-293;; -8.2727285363069883e-293 ## manually reali +gned to highlight the difference. [0]{} Perl>` [download] Of more importance is the source of the numbers that apparently cannot be represented by 64-bit floating point. At least in perl. They are produced & output by the C++ code I'm optimising. I originally thought that the C++ math was producing denormals and C++ was outputting them unnormalised, but that does not seem to be the case: `print join ' ', unpack 'a1 a11 a52', scalar reverse unpack 'b64', pack + 'd', $_ for -8.2727285363069939e-293, -8.2727285363069883e-293;; 1 00000110100 1010011010101110110010001111100101000001001101001100 1 00000110100 1010011010101110110010001111100101000001001101000111` [download] Even the latest perl seems just to be getting the conversion wrong!? Both numbers are representable with 64-bit Ieee754 numbers, so why Perl should silently convert one to the other is something of a mystery. Basically, Perl's (or the underlying CRT) input routine just seems to be broken. Update: The 5.22 perl I'm using is built with the same compiler and libraries as the C++ code; so this seems to be a PerlIO issue rather than a CRT issue. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :) In the absence of evidence, opinion is indistinguishable from prejudice. Not understood.	[reply] [d/l] [select]
Re^3: Determining the minimum representable increment/decrement possible? (Perl's scanf broken?) by syphilis (Archbishop) on Jun 17, 2016 at 14:37 UTC
printf "% 25.17g\n", -8.2727285363069939e-293;; -8.2727285363069883e-293 Yeah, I get the same with mingw-built x64 5.22.0. This is the perl bug I alluded to in my first post that mis-assigns values by up to a few ULPs. If you check the hex format (assigned by perl) of -8.2727285363069939e-293 you'll find: `C:\_32>perl -le "print scalar reverse unpack 'h', pack 'd<', -8.27272 +85363069939e-293;" 834a6aec8f94134c` [download] However, the correct hex format of -8.2727285363069939e-293 is 834a6aec8f941351. 834a6aec8f94134c does in fact correspond to -8.2727285363069883e-293 - so perl is doing the conversion from internal form to decimal string correctly. It's just the initial conversion from decimal string to internal form that was incorrect. Sadly, no-one seems interested in fixing this - though I think that's because of the degree of difficulty rather than actual "disinterest". If this level of inaccuracy bothers you (as it does me) then one solution is to assign using POSIX::strtod: `C:\_32>perl -MPOSIX -le "print scalar reverse unpack 'h', pack 'd<', +POSIX::strtod('-8.2727285363069939e-293');" 834a6aec8f941351 C:\_32>perl -MPOSIX -le "printf '% 25.17g', POSIX::strtod('-8.27272853 +63069939e-293');" -8.2727285363069939e-293` [download] This way you put your faith in the C compiler and that seems to be a safer bet. (That's probably good enough, though I'd rather put my faith in the mpfr library.) Cheers, Rob	[reply] [d/l] [select]
Re^4: Determining the minimum representable increment/decrement possible? (Perl's scanf broken?) by BrowserUk (Patriarch) on Jun 17, 2016 at 14:47 UTC
Re^5: Determining the minimum representable increment/decrement possible? (Perl's scanf broken?) by syphilis (Archbishop) on Jun 17, 2016 at 15:22 UTC
Some notes below your chosen depth have not been shown here
Re^5: Determining the minimum representable increment/decrement possible? (Perl's scanf broken?) by ikegami (Patriarch) on Jun 19, 2016 at 04:45 UTC
Re: Determining the minimum representable increment/decrement possible? by BillKSmith (Monsignor) on Jun 15, 2016 at 18:43 UTC
As is often the case, your difficult problem is really two problems. '1.9041105342991877e+258' is a floating point value to a mathematician, but to perl it is a string. When you convert that string to your computer's floating point and back to a string, the resulting string may not be exactly the same. This has nothing to do with addition. The addition introduces another problem. When the value that you add is sufficiently small, You do not change the floating point representation. If it is just large enough to change the representation, you may not be able to tell after converting back to a string. Sorry, the interaction of these two problems is much to complicated for me. A pure perl issue can complicate things some more. A scalar has a string and a numeric value. Perl does an excellent job of choosing the right one, but in special cases, it can surprise us. I doubt that this is a concern for any of your examples. Bill	[reply]
Re^2: Determining the minimum representable increment/decrement possible? by BrowserUk (Patriarch) on Jun 15, 2016 at 19:06 UTC
'1.9041105342991877e+258' is a floating point value to a mathematician, but to perl it is a string. Sorry, but that is a red-herring: `printf "% 25.17g\n", 1.9041105342991877e+258;; 1.9041105342991886e+258` [download] With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :) In the absence of evidence, opinion is indistinguishable from prejudice. Not understood.	[reply] [d/l]
Re: Determining the minimum representable increment/decrement possible? by ikegami (Patriarch) on Jun 15, 2016 at 20:20 UTC
How portable do you need this to be in terms of Perl version and architecture?	[reply]

Determining the minimum representable increment/decrement possible?

But the problem gets more interesting.