BESEN is implemented in ObjectPascal, so I’ve ported&with-own-features-enhanced the dtoa.c algorithms from C to ObjectPascal, and additionally to dtoa.c’s strtod I’ve wrote my own routine (which is based purely on arbitrary precision big integer operations without any FPU/SSE* operations) as second string-to-double-convert-routine, which give the exact results as dtoa.c’s strtod, but works even on x64/AMD64 without SSE exceptions (because FreePascal generates on x64/AMD64 SSE* instruction instead of x87 FPU operartions and the floating point exception masking function in FreePascal isn’t working correctly for SSE), so BESEN is using to ObjectPascal ported dtoa.c’s strtod on the 32-bit x86 target and on all other non-x86/x64/AMD64 targets and my own routine on the x64/AMD64 target, and for double-to-string converts it uses always the ported dtoa function with some enhancments/modifications/fixes from me, due to security as heap/buffer overflows and so on.

And the original double-converting routines from FreePascal and Delphi are more or less on the precision level by Visual C++ from the table top. And if you can want, I can check it truely with test programs with FreePascal and Delphi.

Thanks for the detailed comment.

I took a look at section 15.7.4.5 (p. 155). It also says this:

An implementation is permitted to extend the behaviour of toFixed for values of fractionDigits less than 0 or greater than 20. In this case toFixed would not necessarily throw RangeError for such values.

You’ll also note that, while JavaScript in IE does in fact limit the number of digits to 20, JavaScript in Firefox limits the number of digits to 100. (And I contend that, since 100 is OK, why not 1,074?)

Since you mentioned it, I tried out bc and dc. Of course, they’re arbitrary-precision calculators, so they should handle any value.

bc
==

bc
scale=2000
dyadic=2^-2000
dyadic

(prints out 2^-2000 accurately, a 2000 digit number, bigger than can fit in a double.)

dc
==

dc
(I pasted the 2000 digit 2^-1000 value here)
p
(prints out 2^-2000 accurately)

I tried out serialize and unserialize — you’re right, there are similar limitations.

2^-143 is the smallest negative power of two that PHP can serialize. However, it can only unserialize up to 2^-40!

I will amend the bug report.

Here are the testcases:

This code works — it prints:
d:8.9683101716788292539118693330554632401936764280097009392452370
16894662929189507849514484405517578125E-44;

<?php
 //Serialize 2^-143
 $dyadic = //Compute as (2^-50)^2 * 2^-43 to break up
 0.00000000000000088817841970012523233890533447265625*
 0.00000000000000088817841970012523233890533447265625*
 0.0000000000001136868377216160297393798828125;
 echo serialize ($dyadic);
?>

This code fails — it prints:
d:4.4841550858394146269559346665277316200968382140048504696226185
08447331464594753924757242202758789062E-44;

<?php
 //Serialize 2^-144
 $dyadic = //Compute as (2^-50)^2 * 2^-44 to break up
 0.00000000000000088817841970012523233890533447265625*
 0.00000000000000088817841970012523233890533447265625*
 0.00000000000005684341886080801486968994140625;
 echo serialize ($dyadic);
?>

This code works — it prints:
0.0000000000009094947017729282379150390625

<?php
 //Serialize and unserialize 2^-40
 $dyadic = 0.0000000000009094947017729282379150390625;
 printf ("%1.40f",unserialize(serialize($dyadic)));
?>

This code fails — it prints:
0.0000000000004547473508864641189575195312

<?php
 //Serialize and unserialize 2^-41
 $dyadic = 0.00000000000045474735088646411895751953125;
 printf ("%1.41f",unserialize(serialize($dyadic)));
?>

(I did not try the “largest fraction” testcases but I’d imagine they’d have similar limitations.)

This actually means that not only is precision lost when printing out doubles like the one you use in your example, but the precision may also be lost when serializing/unserializing them, which is painful.

This may have changed by now, though; I last researched it near the end of PHP4′s lifetime. It was a surprise to me, to say the least (we were having weird issues with floating point numbers in some of our automated tests that turned out to be due to serialize()/unserialize().)

Thanks for taking the time to comment.

I tried changing php.ini as you suggested and I saw no difference.

In the PHP source, in \ext\standard\formatted_print.c, there is this line of code: #define MAX_FLOAT_PRECISION 40. I’ve been assuming this was the culprit.

P.S. Thanks for reopening the PHP bug!

precision=1024

and run your PHP tests again.