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
>
