[
https://issues.apache.org/jira/browse/AVRO-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16969235#comment-16969235
]
Ryan Skraba commented on AVRO-2620:
-----------------------------------
The PR contains a fix for Java and C++ (and some documentation for Javascript).
I can't imagine this is a huge priority – I can't think of a good reason to
need 310 significant digits in a decimal number! Cryptography keys? But
there's no reason *not* to fix it.
I looked for implementations of :
{{floor(log ~10~(2 ^8 × n - 1^ - 1))}}
and replaced with :
{{floor(log ~10~(2) × (8 × n - 1))}}
There's a missing "minus 1" step in the second formula – it's OK to omit it
because 2 ^X^-1 and 2 ^X^ are guaranteed to contain the same number of decimal
digits for any X.
> Max precision on decimal/fixed LogicalType is wrong
> ---------------------------------------------------
>
> Key: AVRO-2620
> URL: https://issues.apache.org/jira/browse/AVRO-2620
> Project: Apache Avro
> Issue Type: Bug
> Components: java
> Reporter: Ryan Skraba
> Assignee: Ryan Skraba
> Priority: Minor
>
> A decimal logical type with an underlying fixed bytes type is invalid if the
> precision is greater than can be contained in the fixed bytes. The
> calculation for
> [max
> precision|https://github.com/apache/avro/blob/a2098bd88361b5ff9298c462a2dccafbb0c2c508/lang/java/avro/src/main/java/org/apache/avro/LogicalTypes.java#L262]
> can return a wrong value when the fixed bytes size is greater than 128.
> For a fixed size of *129*, the {{Math.pow(2, 8 * size - 1)}} part of this
> formula will return {{Double.INFINITY}}, and the max precision will be
> considered {{Long.MAX_VALUE}}. The expected value is 310 digits precision.
> We can apply the log power rule to avoid overflow, or some bit-twiddling
> approximation (like
> [java.math.BigDecimal|https://github.com/openjdk/jdk/blob/jdk8-b120/jdk/src/share/classes/java/math/BigDecimal.java#L3779]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
