RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2]

[Raffaello Giulietti]

On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4511638: Double.toString(double) sometimes produces incorrect results

(ungarbled comment from Guy Steele)

Hi, thanks for writing to me! I am glad to “meet” you. Schubfach looks like an excellent idea; I have simply been trying to assess just how confident we can be about the correctness of the final code. The explanations you have just provided to me about the proof process and testing are very reassuring. I will keep those in mind as I finish re-reading your paper, and will have more to say on Friday. And if you happen to have a list of a few examples where the current Java implementation of FP print fails but Schubfach succeeds, I would be very interested to study them. Thanks!

—Guy

----

(my answer)

Hi,

it's my pleasure to virtually meet the mythical Guy Steele!

For some reason, your comments end up garbled on this PR GitHub page and don't appear at all on the core-libs-dev mailing list. You may perhaps try to post them in plain ASCII?


You can find some of the anomalies in the bug report from exactly 20 years ago! [1]

A tiny collection of the anomalies are coded in the tests [2], [3]. Here's the relevant excerpt for doubles:

    /*
     * There are tons of doubles that are rendered incorrectly by older JDK.
     * While the renderings correctly round back to the original value,
     * they are longer than needed or are not the closest decimal to the double.
     * Here are just a very few examples.
     */
    private static final String[] Anomalies = {
            /* JDK renders these, and others, with 18 digits! */
            "2.82879384806159E17", "1.387364135037754E18",
            "1.45800632428665E17",

            /* JDK renders these longer than needed */
            "1.6E-322", "6.3E-322",
            "7.3879E20", "2.0E23", "7.0E22", "9.2E22",
            "9.5E21", "3.1E22", "5.63E21", "8.41E21",

            /* JDK does not render these, and many others, as the closest */
            "9.9E-324", "9.9E-323",
            "1.9400994884341945E25", "3.6131332396758635E25",
            "2.5138990223946153E25",
    };

To be clear and as emphasized in the comment, the outputs of the current JDK implementation are all information preserving. I could never find a real error in this regard.
However, typing 2e23 and getting back 1.9999999999999998E23 as a response is surprising and unnecessary if one knows David Matula's results from the late '60-ies.

Also, many powers of 2 are output with way too many digits on current JDK.

Schubfach's outputs pass the stringent tests.


Greetings
Raffaello

----

[1] https://bugs.openjdk.java.net/browse/JDK-4511638
[2] https://github.com/openjdk/jdk/pull/3402/files#diff-ee9b0bcfb171cb200f6aa1e3de972b61ca363f95bb8079255af912ae30026937
[3] https://github.com/openjdk/jdk/pull/3402/files#diff-c4a866bc9e7d1beb5342823f9f6cff1fe4f69c96b61620b96cc26d739f9c999f

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

PR: https://git.openjdk.java.net/jdk/pull/3402