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