[ https://issues.apache.org/jira/browse/CASSANDRA-15232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16890801#comment-16890801 ]
Liudmila Kornilova commented on CASSANDRA-15232: ------------------------------------------------ This is how postgres calculates scale https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/numeric.c#L7800 Before this commit Cassandra used to limit precision off all operations to 34 (maximum number of significant digits) After this commit: * add, multiply and subtract operations limit precision to 10000 digits * add, multiply and subtract trim trailing zeros, so operations do not affect scale/precision of next operations * division sets minimum scale to 32. So 1000 / 3 produces 333.33333333333333333333333333333333 (32 digits after dot) * division also tries to guess the position of first significant digit in result (this idea is taken from postgres) so 0.00001 / 3 will produce 5+32=37 digits after dot, 32 of them will be significant * division sets maximum scale to 1000 (the constant is also taken from postgres) * division will not use scale that is lower that scale of any operands The PR is not 100% ready because mod operation needs to be implemented > Arithmetic operators over decimal truncate results > -------------------------------------------------- > > Key: CASSANDRA-15232 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15232 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics > Reporter: Benedict > Assignee: Liudmila Kornilova > Priority: Normal > Labels: pull-request-available > Fix For: 4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The decimal operators hard-code a 128 bit precision for their computations. > Probably a precision needs to be configured or decided somehow, but it’s not > clear why 128bit was chosen. Particularly for multiplication and addition, > it’s very unclear why we truncate, which is different to our behaviour for > e.g. sum() aggregates. Probably for division we should also ensure that we > do not reduce the precision of the two operands. A minimum of decimal128 > seems reasonable, but a maximum does not. -- This message was sent by Atlassian JIRA (v7.6.14#76016) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org