[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-core-libs-dev
Subject:    Why you want a better specification and a fast implementation of Double.toString(double)
From:       Raffaello Giulietti <raffaello.giulietti () gmail ! com>
Date:       2019-09-24 21:24:20
Message-ID: 6668f01c-8a93-8cc9-8622-59c725a64dbe () gmail ! com
[Download RAW message or body]

Hi,

I'd like this community to help me pushing a new spec and the 
accompanying implementation of Double.toString(double) and 
Float.toString(float) into the OpenJDK 14 release.

All material has already been submitted to this mailing list months ago 
[2] and passes tier 1 tests. Yet, there hasn't been much discussion or 
progress.

I understand that everybody is busy with many other big and small 
issues, duties and enhancements. But while my sponsor Brian Burkhalter 
started to look at it, he can't do everything alone, so I'm still 
looking for reviewers interested in the subject.

I would also be much interested in tactics, strategies and techniques to 
accelerate the review and approval process. Languishing here and waiting 
for good souls is not a nice position to be ;-)



Greetings
Raffaello

----

Q: Why a new implementation? What's wrong with the current one?

A: The current one tries to adhere to the rather non-mathematical 
current spec and does so in a costly and buggy way. Not that the bugs 
produce patently wrong results, but they are annoying anyway. They can 
all be categorized under the "too many digits" kind of bug.



Q: Isn't there a risk in replacing the current implementation with a new 
one?

A: Every change in the OpenJDK bears potential risks. On the other hand, 
the proposed implementation has been extensively tested in all aspects, 
without troubles. The risks are related more to reliance on current 
(mis)behavior than to unnoticed bugs in the new implementation.



Q: What are the cons of the new implementation?

A: Technically, there are none known to me. As alluded above, the only 
disadvantage is that the new outcomes are sometimes different, and then 
for the better (shorter outputs). Code that relies on the exact current 
behavior can possibly break.
For example, a test that expects Double.toString(2e23) to produce 
"1.9999999999999998E23", as currently done, rather than "2.0E23", as 
returned by the new implementation, will fail.



Q: Can you list some of the pros of the new implementation?

A: Two stand out:
(1) on the average, a conversion is about 15x faster (around 90 ns on a 
6 years old home-grade laptop)
(2) no temporary objects are ever allocated



Q: Why is there a need for another spec?

A: Because the current one is rather unclear in its main goal. In 
addition, it intermingles the selection of a decimal to represent the 
floating-point number with its formatting, which adds to the unclarity.



Q: What about the proposed spec.
A: It clearly separates the rather simple, mathematical and 100% 
unambiguous selection of the decimal from the formatting aspects.



Q: Which kind of help is needed?

A: You can:
(1) Take a look at the proposed spec [1] and send questions and comments 
to this mailing list.
(2) Take a look at the overall structure of the implementation [2] 
(webrev is in [3]) and discuss it here, even without understanding the 
underlying algorithms. The focus could be on quality, conventions, etc.
(3) Take a look at the accompanying paper [4] which presents all the 
nitty-gritty details and let me know if there's something unclear or wrong.
(4) You can try out the code. It is now about 6 months old, meant for 
and tested on OpenJDK 13. I guess it will work on OpenJDK 14 as well, 
but I didn't try out as of today.



Q: What is the investment in time?

A: The spec can be read and understood in about 10-15 minutes.
The paper needs 0.5-1.0 days, depending on your willingness to 
understand every detail. Once the paper has been worked out, however, 
the core of the implementation is straightforward to understand, say a 
couple of hours.

----

[1] https://bugs.openjdk.java.net/browse/JDK-8202555
[2] 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059783.html
[3] http://cr.openjdk.java.net/~bpb/4511638/webrev.03/
[4] https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058


[prev in list] [next in list] [prev in thread] [next in thread]