On Fri, 13 Feb 2026 20:53:53 GMT, Michael Strauß <[email protected]> wrote:
>> 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. perhaps a short version of this explanation should be added to the javadoc, to explain the behavior (especially since it differs from `Double.parseDouble()`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2806068494
