abhinav-phi opened a new pull request, #68733:
URL: https://github.com/apache/doris/pull/68733

   ### What problem does this PR solve?
   
   Issue Number: close #68722
   
   Related PR: #68729 (same file, different method — that one is the BOOLEAN 
branch, this is the
   integral branch; whichever lands first the other rebases without conflict)
   
   Problem Summary:
   
   `FractionalLiteral.uncheckedCastTo(<integral type>)` built its working 
decimal with
   `new BigDecimal(value.toString())`. For a `Float`/`Double` that is the 
*shortest decimal
   representation* of the value, not the value itself, so the folded integral 
is derived from the
   text rather than from the binary magnitude. BE converts the binary value.
   
   ```
   SELECT CAST(CAST(1e38 AS DOUBLE) AS LARGEINT) AS fe, CAST(d1 AS LARGEINT) AS 
be FROM t;
   
+-----------------------------------------+------------------------------------------+
   | 100000000000000000000000000000000000000 | 
99999999999999997748809823456034029568   |
   
+-----------------------------------------+------------------------------------------+
   ```
   
   `1e38` as a double really is `99999999999999997748809823456034029568`; 
`Double.toString(1e38)` is
   `"1.0E38"`, and `new BigDecimal("1.0E38")` is exactly 10^38 — hence the 
mismatch, and a constant
   fold that LARGEINT cannot even represent round-trip.
   
   The fix keeps the decimal-string behaviour for `BigDecimal` sources (decimal 
literals are already
   exact) and uses the binary value for `Float`/`Double` sources, which is what 
BE does. Truncation
   toward zero, the finite check and the overflow check are unchanged, so
   `CAST(12.999 AS INT) = 12`, `CAST(-12.999 AS BIGINT) = -12` and out-of-range 
values still throw
   `CastException` — all of which the existing assertions still cover.
   
   The date-like branch of the same method still uses `getValue().toString()`; 
a `DOUBLE` -> `DATE`
   fold goes through a day-number encoding where the decimal-vs-binary question 
needs its own look at
   BE, so it is deliberately left out of this change.
   
   ### Release note
   
   None
   
   ### Check List (For Author)
   
   - Test <!-- At least one of them must be included. -->
       - [ ] Regression test
       - [x] Unit Test
       - [ ] Manual test (add detailed scripts or steps below)
       - [ ] No need to test or manual test. Explain why:
   
     New `DoubleLiteralTest.testCastToIntegralUsesTheBinaryValue` asserts the 
reported case
     (`CAST(1e38 AS LARGEINT)` -> `99999999999999997748809823456034029568`), 
that the exactly
     representable case is unchanged (`CAST(1e9 AS LARGEINT)` -> `1000000000`), 
that ordinary
     truncation still trims toward zero (`CAST(-12.999 AS BIGINT)` -> `-12`) 
and that an out-of-range
     magnitude still raises `CastException` instead of saturating.
   
     Red, on `master` with only the test added:
   
     ```
     [ERROR]   DoubleLiteralTest.testCastToIntegralUsesTheBinaryValue:388
               expected: <99999999999999997748809823456034029568> but was: 
<100000000000000000000000000000000000000>
     ```
   
     Green, with the fix (whole net):
   
     ```
     DoubleLiteralTest        Tests run: 3,  Failures: 0   (focused run: BUILD 
SUCCESS, exit 0)
     FloatLiteralTest         Tests run: 3,  Failures: 0
     LargeIntLiteralTest      Tests run: 3,  Failures: 0
     IntegerLiteralTest       Tests run: 2,  Failures: 0
     DecimalLiteralTest       Tests run: 2,  Failures: 0
     CompareLiteralTest       Tests run: 2,  Failures: 0
     CastTest                 Tests run: 23, Failures: 0
     ConstantProjectionFoldingTest Tests run: 1, Failures: 0
     org.apache.doris.analysis.FloatLiteralTest Tests run: 2, Failures: 0
     ```
   
     Two `FoldConstantTest` failures remain in the net; they are **pre-existing 
on this machine and
     unrelated** — they reproduce identically on pristine `master` with every 
edit of mine stashed, and
     they are session-time-zone dependent timestamp assertions:
   
     ```
     [ERROR]   FoldConstantTest.testDateConstructFunction:1552 expected: 
<'1977-06-03 17:57:24'> but was: <'1977-06-03 15:27:24'>
     [ERROR]   FoldConstantTest.testFoldString:581 expected: <'2025-10-27 
14:58:08.100000'> but was: <'2025-10-27 12:28:08.100000'>
     ```
   
     Command (project flags from `run-fe-ut.sh`):
   
     ```
     mvn test -pl fe-core -am -Dcheckstyle.skip=true -DfailIfNoTests=false \
         -Dmaven.build.cache.enabled=false -Dtest=DoubleLiteralTest
     ```
   
     Environment: JDK 17.0.20 (Temurin), Maven 3.9.16, thrift 0.24.0 from the 
prebuilt thirdparty
     package, Ubuntu 22.04 under WSL2. Style gate `mvn -pl fe-core 
checkstyle:check` ->
     `You have 0 Checkstyle violations.`
   
   - Behavior changed:
       - [ ] No.
       - [x] Yes. <!-- Explain the behavior change -->
         Folding a `FLOAT`/`DOUBLE` literal to an integral type now uses the 
binary value, so cases
         where the shortest decimal differs from the binary magnitude (the 
reported `1e38` -> LARGEINT)
         return the BE result. Values that are exactly representable, and all 
truncation/overflow
         behaviour, are unchanged.
   
   - Does this need documentation?
       - [x] No.
       - [ ] Yes. <!-- Add document PR link here. -->
   
   ### Check List (For Reviewer who merge this PR)
   
   - [ ] Confirm the release note
   - [ ] Confirm test cases
   - [ ] Confirm document
   - [ ] Add branch pick label
   
   ### AI assistance disclosure
   
   An AI coding agent was used to draft this change and the new test. I read 
and reviewed every line
   myself, ran the FE unit tests above on the exact commit in this branch 
(including the pristine-master
   control run for `FoldConstantTest`), and I take responsibility for the 
result.
   


-- 
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]

Reply via email to