Faster double parser?
Brian Burkhalter
brian.burkhalter at oracle.com
Mon Apr 5 17:09:21 UTC 2021
The mailing list mangled formatting. My comments are prefixed below by β->β.
On Apr 5, 2021, at 9:52 AM, Brian Burkhalter <brian.burkhalter at oracle.com<mailto:brian.burkhalter at oracle.com>> wrote:
On Apr 5, 2021, at 4:11 AM, Andrew Haley <aph at redhat.com<mailto:aph at redhat.com><mailto:aph at redhat.com>> wrote:
On 4/5/21 9:08 AM, Alan Bateman wrote:
On 04/04/2021 09:53, Andrew Haley wrote:
:
We also have a candidate for a String -> toDouble parser from Raffaello
Giulietti:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html
As far as I can see there's nothing wrong with it, but it got stuck in
review. This was a bad failure of our review processes, I'm afraid. I
wonder if we will do any better with this one.
Yeah, there was a lengthy discussion about this at the OpenJDK Committer
Workshop just after FOSDEM 2020. Brian Burkhalter and Andrew Dinn had
both put time into looking at the proposal it but the conclusion was
that Raffaello's paper "The Schubfach way to render doubles" needed a
review from from an expert in this area.
-> I spent some time on it a while back but got bogged down.
I wonder. The implementation has even been proved correct for floats by
exhaustion. (Of course that's not possible for doubles.)
-> I exhaustively verified it for floats. I also ran round-trip tests for doubles which ran for days without error. Of course one can only disprove by counterexample, not prove by anecdote.
I submit, therefore, that we could at least use the float version without
reasonable fear of breaking something.
-> That is a good suggestion.
We seem to be paralysed by this one.
Guy Steele was mentioned but I don't know if he was approached about it.
-> Indirectly.
-> Another aspect which was raised was supportability: is it sufficiently understood for us to support? On that note I would ask βIs FloatingDecimal sufficiently understood to support?β I think the answer to both questions is the same.
More information about the core-libs-dev
mailing list