You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Liudmila Kornilova (JIRA)" <ji...@apache.org> on 2019/07/23 08:58:00 UTC

[jira] [Comment Edited] (CASSANDRA-15232) Arithmetic operators over decimal truncate results

    [ https://issues.apache.org/jira/browse/CASSANDRA-15232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16890801#comment-16890801 ] 

Liudmila Kornilova edited comment on CASSANDRA-15232 at 7/23/19 8:57 AM:
-------------------------------------------------------------------------

Hello [~benedict],

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


was (Author: override):
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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org