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
