[ https://issues.apache.org/jira/browse/CASSANDRA-18647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Williams updated CASSANDRA-18647: ----------------------------------------- Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: CQL/Semantics Discovered By: User Report Fix Version/s: 5.x Severity: Normal Status: Open (was: Triage Needed) > 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 > Components: CQL/Semantics > Reporter: Nadav Har'El > Priority: Normal > Fix For: 5.x > > > 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org