On Fri, 13 Feb 2026 19:14:41 GMT, Andy Goryachev <[email protected]> wrote:
>> Michael Strauß has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Review comments > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/parser/CssNumberParser.java > line 46: > >> 44: * This implementation is allocation-free and avoids per-digit >> floating-point math by accumulating >> 45: * a (truncated) base-10 significand and a base-10 exponent. It does >> not aim for "perfectly rounded" >> 46: * conversion for extremely long representations, but generally >> returns values within 2 ULPs of the > > what is the source of error in this case? would it make sense to explain > (even though it's not a public class)? Double parsing can be lossy if you think of the input as an _exact_ number. Some algorithms parse an exact number into the nearest representable double by (conceptually) first converting the number with infinite precision, and then rounding to the nearest double. `Double.parseDouble()` does that, while the simpler algorithm in this PR doesn't. It's not like one algorithm is exact and the other isn't, it's more like this algorithm sometimes won't give you the nearest representable double, but be off by an ulp. `Double.parseDouble()` will always give you the nearest representable double. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2806049409
