raghav-reglobe commented on issue #69215: URL: https://github.com/apache/doris/issues/69215#issuecomment-6245285463
Thanks for the independent reproduction — the two mechanisms you describe are exactly the two the fix in #69216 addresses (the int-to-double conversion of a numerator past 2^53, and the double-then-narrow parse for a FLOAT target). **Build.** The numbers in the report come from master at f937d950d45 plus the change as it stands in #69216; default settings, V2 variant ingestion (the default). **Added to the PR (commit 3b685f4c7c8):** - `FunctionCastToFloatTest.decimal_to_float_pinned_witnesses_and_boundaries`: both witnesses with their signs flipped, pinned as hex-float / exact float literals independent of any conversion helper (`29201.024999999998` → `0x1.c844199999999p+14`; `-9000000000.000000009` → `-9000000512` as FLOAT, agreeing with your note that it is not a tie), numerators `2^53-1`, `2^53`, `2^53+1`, scales 22 and 23 (the last scale whose power of ten is exact in binary64, and the first beyond it), small numerators where only the division rounds (`0.1` → `0x1.999999999999ap-4`, `0.7` → `0x1.6666666666666p-1`), and DECIMAL256 `10^40` overflowing to `+inf` as FLOAT while DOUBLE reads `1e40`. - `regression-test/suites/variant_p0/test_variant_decimal_cast_double.groovy`: a `VARIANT<MATCH_NAME 'p': DECIMAL(38,12)>` template path makes the element decimal-backed; the direct `CAST(v['p'] AS DOUBLE)` must equal both the text route and `Double.parseDouble` of the element's own text, for the witnesses with both signs. **On the other points.** - DECIMALV2 goes through the same conversion: both `_from_decimalv3` overloads (the V3 one on `from.value`, the V2 one on `from.value()`) call `decimal_to_float_exact`; `test_decimalv2_keeps_scale_when_cast_to_float_and_double` covers it. DECIMAL32/64/128/256 are the parametrized `test_from_decimal`, whose expectations now follow the digits instead of the two-rounding formula. - Overflow: `fast_float::from_chars` sets the value to ±infinity on `result_out_of_range`, so a wide DECIMAL256 → FLOAT still yields infinity; the existing `test_from_decimal_overflow` plus the new `10^40` case pin it. - The strict `< 2^53` bound is deliberately conservative; `2^53` itself would also be exact, as you say. - STRING → FLOAT's own intermediate-double narrowing in `StringParser::string_to_float` is out of scope for this PR and noted in its description; it deserves its own change. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
