[
https://issues.apache.org/jira/browse/CASSANDRA-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575621#comment-14575621
]
Robert Stupp commented on CASSANDRA-9550:
-----------------------------------------
bq. you lose the value of the BigDecimal.precision field during serialization
means the following: {{precision}} (_number of digits in the unscaled value_)
is a transient field in {{BigDecimal}} that's used for computations. It's not
critical to lose it during serialization since you can always re-add it using
{{BigDecimal.plus(MathContext)}} and losing the {{precision}} field doesn't
affect the value (but setting another, lower precision can due to rounding).
Another "attribute" is _rounding-mode_, which is applied to *individual*
operations on {{BigDecimal}} - it's not _stored_ in BD. IMO _rounding-mode_ is
also important in correct maths - not only for financial maths. (Some wrong
multiply+round ops can make the difference whether manufactured parts match or
are just garbage.)
I'm a bit skeptic to add a new {{NUMERIC(p,s)}} type since we have to represent
that internally using {{BigDecimal}} - so ending up using the same data type.
And we don't do any maths on {{BigDecimal}} in C* core except what UDFs do.
OTOH it's easy in an application to put a {{public static final MathContext
FINANCIAL_MATH_CONTEXT;}} somewhere - but maybe adds some burden to UDF
implementations. Is this your point, [~brianmhess]] ?
> Support fixed precision data type
> ---------------------------------
>
> Key: CASSANDRA-9550
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9550
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Brian Hess
>
> SQL databases support a fixed precision data type. When converting data
> models from SQL DBs to Cassandra, the choices are not clear. DOUBLE or FLOAT
> are possibilities, but with UDFs and Aggregates this is actually a lot less
> clear, as you really do need fixed precision arithmetic. That is, one flaw
> with floating-point math is that the order of the operations can change the
> final result. That is not an issue with fixed precision arithmetic (though
> other trade-offs are there).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
