On Fri, 20 Feb 2026 00:59:24 GMT, Michael Strauß <[email protected]> wrote:

>> Here are some test cases that may be worth including, because they relate to 
>> different code paths, or might break in case some of the rounding rules 
>> aren't implemented correctly. They come directly from examples in the 
>> algorithm's original paper. Rounding in the code is done exactly as 
>> prescribed in the algorithm everywhere I checked.
>> 
>> assertSameDouble(0.2, "0.2");
>> assertSameDouble(0.2, "0.20000000000000001110");
>> assertSameDouble(0.19999999999999998335, "0.19999999999999998335");
>> assertSameDouble(9000000000000000., "9000000000000000.5");
>> assertSameDouble(9000000000000002., "9000000000000001.5");
>> assertSameDouble(9000000000000002., "9000000000000002.5");
>> assertSameDouble(1e22, "1e22");
>> assertSameDouble(1e23, "1e23");
>> assertSameDouble(7450580596923828125e-27, "7450580596923828125e-27");
>> assertSameDouble(2440254496e57, "2440254496e57");
>> assertSameDouble(9007199254740993., "9007199254740993");
>> assertSameDouble(9.109e-31, "9.109e-31");
>> 
>> Testing indicates all but the third one work. There, the algorithm isn't 
>> even used, though.
>
> I've added these tests. The reason why 
> `assertSameDouble(0.19999999999999998335, "0.19999999999999998335")` fails is 
> because there are more digits in the number than fit in a `long`, and thus 
> the actual number being parsed is truncated.

Interestingly, the test passes if we use Lemire's algorithm with the truncated 
significand instead of using the fallback. This might be a coincidence.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2830940879

Reply via email to