zeroshade commented on code in PR #43957:
URL: https://github.com/apache/arrow/pull/43957#discussion_r1767138767
##########
cpp/src/arrow/util/decimal_internal.h:
##########
@@ -442,8 +516,9 @@ struct RealTraits<float> {
static constexpr float two_to_192(float x) { return x == 0 ? 0 : kFloatInf; }
static constexpr int kMantissaBits = 24;
- // ceil(log10(2 ^ kMantissaBits))
- static constexpr int kMantissaDigits = 8;
+ // log10(2 ^ kMantissaBits) ~= 7.2, let's be conservative to ensure more
accuracy
+ // with our conversions for Decimal values
Review Comment:
I reran the tests to confirm, and yea it's only the Decimal32 case which
runs into this problem (and only for Float since the double case falls back to
the approx algorithm).
In the float case, Decimal32 won't hit the condition to fall back on the
approx algorithm as MaxPrecision == 9 and MantissaDigits is 8 (or 7 if I keep
this change). In either case, using 7 for the mantissa digits is likely more
accurate given that log10(2 ^ 24) is ~7.2 as opposed to doubles which uses 16
because log(2 ^ 53) ~= 15.9 so it makes sense to ceiling that to 16.
The only alternative would be to just have Decimal32 *always* go to the
approx algorithm even for the float case despite maxprecision being larger than
the mantissa digits.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
