Ah, thanks - the pointer towards SQL helps a lot. Negative scale seems like it would still make sense - it would represent a positive exponent. I think that's basically how Java's BigDecimal or Python's decimal.Decimal work. It sounds like the intention is to line up closer to SQL, though, which is fair enough.
Thanks again! On Thu, Mar 4, 2021 at 7:58 PM Micah Kornfield <[email protected]> wrote: > > Hi Spencer, > I believe precision and scale from the Avro specification have their > origins from DBMS/SQL systems (at least that where I first learned these > definitions). > > Precision is the maximum number of decimal digits that the decimal should > represent. (generally it only makes sense to represent numbers with at > least 1 digit, hence the positive constraint). > > Scale is the fixed number of fractional digits (the ones to the right of > the decimal place). (can range from 0 if no fraction is desired to > precision). > > -Micah > > On Thu, Mar 4, 2021 at 6:03 PM Spencer Nelson <[email protected]> wrote: > > > The current (1.10.1) Avro spec is a little light on explanation for > > the decimal logical type: > > https://avro.apache.org/docs/1.10.1/spec.html#Decimal. > > > > It says "scale" is "a JSON integer representing the scale," and > > "precision" is "a JSON integer representing the (maximum) precision of > > decimals stored in this type." > > > > Scale is further specified to be non-negative, and precision is positive. > > > > What are the precision and scale required to represent a decimal like > > "1.234E10?" I would think that has a scale of 10 and a precision of 4. > > But from perusing code, it appears that this would be treated as a > > decimal with a scale of 0, and a precision of 10, which seems quite > > far off! If I'm right about that (and I might not be!), then why is a > > scale strictly non-negative, and why are all the meaningless zeroes > > included in describing "precision?" > >
