[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=16890801#comment-16890801 ] Liudmila Kornilova edited comment on CASSANDRA-15232 at 7/24/19 8:10 AM: - Hello [~benedict], This is how postgres calculates scale https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/numeric.c#L7800 I created this work-in-process pull request https://github.com/apache/cassandra/pull/334 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 1 digits * division sets minimum scale to 32. So 1000 / 3 produces 333. (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.1 / 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 was (Author: override): Hello [~benedict], This is how postgres calculates scale https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/numeric.c#L7800 I created this work-in-process pull request https://github.com/apache/cassandra/pull/334 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 1 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. (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.1 / 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: 1h 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
[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=16890801#comment-16890801 ] Liudmila Kornilova edited comment on CASSANDRA-15232 at 7/23/19 8:58 AM: - Hello [~benedict], This is how postgres calculates scale https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/numeric.c#L7800 I created this work-in-process pull request https://github.com/apache/cassandra/pull/334 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 1 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. (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.1 / 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): Hello [~benedict], This is how postgres calculates scale https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/numeric.c#L7800 I created this WIP commit https://github.com/apache/cassandra/pull/334 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 1 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. (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.1 / 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
[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=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 I created this WIP commit https://github.com/apache/cassandra/pull/334 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 1 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. (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.1 / 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): 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 1 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. (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.1 / 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
[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=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 1 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. (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.1 / 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 1 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. (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.1 / 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
