On Tue, 17 Feb 2026 20:00:56 GMT, Andy Goryachev <[email protected]> wrote:
>> The code is not copied, it's an implementation of the algorithm presented in >> the referenced paper. The algorithm is what I would call state of the art, >> it's used in several standard libraries: >> 1. [Go since v1.16](https://go.dev/doc/go1.16#strconvpkgstrconv) >> 2. [Rust since >> v1.55](https://blog.rust-lang.org/2021/09/09/Rust-1.55.0/#faster-more-correct-float-parsing) >> 3. [GNU >> libstdc++](https://gcc.gnu.org/pipermail/libstdc%2B%2B-cvs/2022q1/037428.html) >> 4. [LLVM libc](https://libc.llvm.org/configure.html) has a toggle for it >> >> The problem with `Double.parseDouble()` is not that it's slow, or mainly >> that it requires substring allocation (although that's unfortunate), it's >> that it parses a Java-specific number grammar, where it should be parsing >> CSS numbers. >> >> The purpose of code review also can't be to demonstrate that Lemire's >> algorithm is indistinguishable from the JDK's algorithm. How would you even >> do that? I certainly can't prove that mathematically, and enumerating all >> doubles is impossible. If this algorithm produces correctly-rounded doubles, >> then it must be equivalent to the JDK algorithm. As I said, the algorithm is >> state of the art, and people more knowledgeable than I have obviously >> concluded that it's correct, so I think we can leave it at that. >> >> What remains is to verify that the _implementation_ of the algorithm is >> correct, and from all the testing I haven't found a single example that >> would be different from the JDK algorithm. > >> What remains is to verify that the implementation of the algorithm is correct > > exactly, thanks for correcting. how do we do that? > >> The problem with Double.parseDouble() is not that it's slow, or mainly that >> it requires substring allocation > > I agree! my comment still stands - this is something we should ask the JDK, > maybe to provide a `Double.parseDouble(CharSequence, int start, int end)`. > This does not preclude us from providing an implementation in the mean time. > >> it's an implementation of the algorithm presented in the referenced paper. > > so you are the author, correct? > > We still need to review the implementation. The recent changes made it more > complex than earlier, so I'm the author of the implementation. Asking for another overload of `Double.parseDouble(CharSequence, int, int)` doesn't change the fact that this is parsing a Java-specific number grammar. Usually, we require three reviewers for enhancements that significantly change FX, are particularly high risk, or that have a large API surface. This is neither of these cases (it's just color parsing so far), so I think two reviewers is still sufficient. I also think that normal review standards should apply here (and these are significantly lower that what you'd do if you changed `Double.parseDouble()`). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2818895320
