REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

[Raffaello Giulietti]

If the float (binary32) case is of any guidance about the soundness of 
the algorithm and the validity of the implementation, *all* of the 2^32 
float bit patterns pass the extensive tests of the contribution in less 
than a couple of hours, as mentioned in past posts.

As a peace of mind, even simpler and quicker but not as extensive, 
anybody can check by very simple means that the String outcomes at least 
convert back to the original floats and are never longer than the 
current OpenJDK outcomes.

Exhaustive testing all 2^64 doubles is unreasonable on contemporary 
hardware, even in the cloud. Nevertheless, many trillions have been tested.


Greetings
Raffaello



On 2020-04-30 18:31, Raffaello Giulietti wrote:
 > On 2020-04-30 15:29, Alan Bateman wrote:
 >> On 30/04/2020 13:54, Raffaello Giulietti wrote:
 >>> Hi,
 >>>
 >>> after more than one year after first publication, the patches [1] 
and the CSR [2] are still awaiting a review...
 >>>
 >>>
 >>> Here's a breakdown of estimated times:
 >>> * Reading the CSR: 15-30 min. This can be done and approved 
independently.
 >>> * Checking that the implementation matches the documentation [3]: 
1-2 hours.
 >>> * Reading the detailed documentation: 0.5-1.0 days.
 >>> * Overall review of the code, including the extensive tests: 
0.5-1.0 days.
 >> This is impressive work. As I think was mentioned before, taking 
this on would require significant review effort and long term committent 
to maintain it. Has the paper been peer reviewed? Is the algorithm used 
by any other languages or run-times? I know Brian Burkhalter (and maybe 
Andrew Dinn too?) have put time into trying to read this but it's a 
significant effort and a lot more than a few days.
 >>
 >> -Alan
 >
 > Hi,
 >
 > the writing has not undergone a formal peer review: this is why I 
care not to denote it as "paper", whenever I remember to do so.
 >
 > I doubt a 27 pages long document written by an unknown individual not 
associated with any academic or industrial entity will ever be taken 
into consideration, not to say peer reviewed. That requires formally 
more "credible" writers supported by "authoritative" institutions, for 
some definition of "credible" and "authoritative".
 >
 > The drafts and the first published version of the writing have been 
read over and over again by the late Dmitry Nadezhin, though. Dmitry was 
a JDK 8 Project Author associated with Oracle before his premature death 
last year. Apart from a couple of typos, he didn't complain about 
logical errors and was pleased with the outcome. Dmitry also contributed 
to an essential theorem and its proof, certified by ACL2 code.
 >
 > Of course, I understand that having a published formal paper and the 
algorithm used somewhere else would add to the credibility and simplify 
acceptance in the OpenJDK. However, I guess that many novel technologies 
of all kind first appear in the OpenJDK than anywhere else (with 
associated risks probably higher than those of my contribution). 
Granted, they are much more strategical than my work to the good health, 
the progress and the future of this fantastic ecosystem.
 >
 > Andrew Dinn expressed interested, indeed, but was (and probably still 
is) busy with many other duties.
 > Brian Burkhalter, my sponsor, read part of the writing some time ago 
and keeps the code on his webrev repo. He, too, is probably busy with 
other activities.
 >
 > My estimate about the reviewing times assumes genuine enthusiasm and 
full immersion. With continuous interruptions to re-surface to tackle 
other duties, the times inflate for sure.
 >
 > Seems that nobody has a chance or sufficient motivation to spend time 
with a review because the algorithm is novel and not used in the large. 
On the other hand, the algorithm is not used in the large exactly 
because it is novel and needs a review...
 > Adding to this, since more than 20 years there's a working, although 
expensive and not fully correct algorithm in the OpenJDK, so why bother 
to replace it, right?
 >
 > I've no idea on how to overcome this stall. I feel kind of stuck, 
sitting here and waiting for somebody to step forward.
 >
 >
 > Greetings
 > Raffaello
 >