[CALCITE-6395] Significant precision loss when representing REAL literals

[mihaibudiu]

No description provided.

[mihaibudiu]

This PR actually removes some code to fix a bug. Should be easy to review!

[snuyanzin]

I wonder whether will we have similar issue with

CAST(FLOAT AS VARCHAR)

calcite/core/src/main/java/org/apache/calcite/runtime/SqlFunctions.java

Lines 3511 to 3520 in 19debd3

	/** CAST(FLOAT AS VARCHAR). */
	public static String toString(float x) {
	if (x == 0) {
	return "0E0";
	}
	BigDecimal bigDecimal =
	new BigDecimal(x, MathContext.DECIMAL32).stripTrailingZeros();
	final String s = bigDecimal.toString();
	return PATTERN_0_STAR_E.matcher(s).replaceAll("E").replace("E+", "E");
	}

[mihaibudiu]

Frankly I don't understand why in that place the float has to be converted to a decimal and then to a string. One can do the conversion directly. The question is whether I fix this in this PR or file another issue. If it's small enough I will bundle it here.

[mihaibudiu]

The truth is that float only has about 7 decimal digits of precision, so one could argue that the original answer provided by Calcite was legal. However, it makes it much easier to test code if the result provided by Calcite for CAST(CAST string AS REAL) AS BIGINT) is the same as the Java result of (long)Float.parseFloat(string), at least when running on the same CPU.

[mihaibudiu]

I have fixed this path as well in a subsequent commit.
Just because Calcite uses Decimal literals to represent FP values doesn't mean it has to convert to Decimal when converting to strings.

[snuyanzin]

Thanks for fixing that, also checked that there is no more usages of MathContext.DECIMAL32 in code

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud