DX-90291: Gandiva: fix round(double, scale) overflow for large values

[victor6567758]

SUMMARY

round(double_field, 100) returned Infinity for large values.

Cause: round_float64_int32 and round_float32_int32 (ROUND_DECIMAL_TO_SCALE) multiplied the number by 10^scale before rounding. That overflowed to inf (or to NaN for a huge scale). For a large scale it also lost the last digit, for example round(451.65, 100) returned 451.65000000000003.

Fix: return the number unchanged when abs(number) >= 2^52 / 10^scale. The check runs before the multiplication, so nothing can overflow. At that magnitude the scaled value has no fractional part, so there is nothing to round. The negated comparison also returns NaN and ±inf unchanged. A huge positive scale such
as 400, where 10^scale is inf, returns the input too.

Note: if (!(fabs(number) < kMaxRoundableScaledValue / scale_multiplier)): Negated < so that NaN, for which every comparison is false, also takes the early return along with large values and ±inf.

Known limits (out of scope):

• A hugely negative scale (multiplier 0) still gives NaN.
• Within about one ulp of abs(number * 10^scal) ≈ 2^52, the multiply-round-divide approach can be one ulp off at ties. The old code did the same, so this is not a regression.

TEST

Tests: new assertions in TestExtendedMathOps.TestRoundDecimal (large values, their negatives, and a last-digit case at scale 100).

SELECT double_field,round(double_field,3),round(double_field,4),round(double_field,7),round(double_field,10),round(double_field,100),round(double_field,8),round(double_field,-100) FROM gandiva_functions."numbers.parquet" where double_field != 0 is attached to the story: https://dremio.atlassian.net/browse/DX-90291?issueKey=DX-90291

[alinaliBQ]

overall lgtm

[lriggs]

Learned something new:

Ulp: unit in the last place or unit of least precision (ulp) is the spacing between two consecutive floating-point numbers, i.e., the value the least significant digit (rightmost digit) represents if it is 1. It is used as a measure of accuracy in numeric calculations.

[victor6567758]

@alinaliBQ @lriggs please review after suggested fixes.

[lriggs]

Also consider creating a GH issue in apache/arrow and making this fix upstream as well.