[
https://issues.apache.org/jira/browse/CASSANDRA-18647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17740047#comment-17740047
]
Nadav Har'El edited comment on CASSANDRA-18647 at 7/5/23 7:35 AM:
------------------------------------------------------------------
By the way, there is a unit test - testNumericCastsInSelectionClause in
test/unit/org/apache/cassandra/cql3/functions/CastFctsTest.java - that should
have caught this bug. The problem is that it compares the result of the cast
not to any specific value but to BigDecimal.valueOf(5.2F), and this
BigDecimal.valueOf(float) is exactly the same function that the Cassandra
implementation uses for this purpose, so the implementation and the test have
the same bug and the test doesn't verify anything.
I found the cause of this bug. It turns out that BigDecimal does *not* have a
float overload, only a double. The Java documentation says that:
{quote}valueOf(double val) Translates a double into a BigDecimal, using the
double's canonical string representation provided by the
Double.toString(double) method.
{quote}
So the solution of how to turn a float into a Decimal is easy - just use
*Float.toString(float)* and then construct a BigDecimal using that string - do
*not* use BigDecimal.valueOf(double) on a float.
So it seems the fix would be a two-line patch to getDecimalConversionFunction()
in src/java/org/apache/cassandra/cql3/functions/CastFcts.java to do that. And
also fix the test, of course.
was (Author: nyh):
By the way, there is a unit test - testNumericCastsInSelectionClause in
test/unit/org/apache/cassandra/cql3/functions/CastFctsTest.java - that should
have caught this bug. The problem is that it compares the result of the cast
not to any specific value but to BigDecimal.valueOf(5.2F), and this
BigDecimal.valueOf(float) is apparently the same function that the Cassandra
implementation uses for this purpose, so if the implementation has a bug the
test doesn't verify anything.
I know the cause of this bug. It turns out that BigDecimal does *not* have a
float overload, only a double. The Java documentation says that:
{quote}valueOf(double val) Translates a double into a BigDecimal, using the
double's canonical string representation provided by the
Double.toString(double) method.
{quote}
So the solution of how to turn a float into a Decimal is easy - just use
*Float.toString(float)* and then construct a BigDecimal using that string - do
*not* use BigDecimal.valueOf(double) on a float.
So it seems the fix would be a two-line patch to getDecimalConversionFunction()
in src/java/org/apache/cassandra/cql3/functions/CastFcts.java to do that. And
also fix the test, of course.
> CASTing a float to decimal adds wrong digits
> --------------------------------------------
>
> Key: CASSANDRA-18647
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18647
> Project: Cassandra
> Issue Type: Bug
> Reporter: Nadav Har'El
> Priority: Normal
>
> If I create a table with a *float* (32-bit) column, and cast it to the
> *decimal* type, the casting wrongly passes through the double (64-bit) type
> and picks up extra, wrong, digits. For example, if we have a column e of type
> "float", and run
> INSERT INTO tbl (p, e) VALUES (1, 5.2)
> SELECT CAST(e AS decimal) FROM tbl WHERE p=1
> The result is the "decimal" value 5.199999809265137, with all those extra
> wrong digits. It would have been better to get back the decimal value 5.2,
> with only two significant digits.
> It appears that this happens because Cassandra's implementation first
> converts the 32-bit float into a 64-bit double, and only then converts that -
> with all the silly extra digits it picked up in the first conversion - into a
> "decimal" value.
> Contrast this with CAST(e AS text) which works correctly - it returns the
> string "5.2" - only the actual digits of the 32-bit floating point value are
> converted to the string, without inventing additional digits in the process.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
