jorgecarleitao commented on issue #1779: URL: https://github.com/apache/arrow-rs/issues/1779#issuecomment-1146037480
Sorry, I am probably misreading this - I am not following what is the non-compliance. The Python documentation exemplifies: > As an example, decimal128(7, 3) can exactly represent the numbers 1234.567 and -1234.567 (encoded internally as the 128-bit integers 1234567 and -1234567, respectively) (so, 7 digits, 3 of them are decimal) we offer the example > For example the number 123.45 has precision 5 and scale 2. The spec is https://github.com/apache/arrow/blob/master/format/Schema.fbs#L185 (copied for readability below) ``` /// Exact decimal value represented as an integer value in two's /// complement. Currently only 128-bit (16-byte) and 256-bit (32-byte) integers /// are used. The representation uses the endianness indicated /// in the Schema. table Decimal { /// Total number of decimal digits precision: int; /// Number of digits after the decimal point "." scale: int; /// Number of bits per value. The only accepted widths are 128 and 256. /// We use bitWidth for consistency with Int::bitWidth. bitWidth: int = 128; } ``` Aren't they all aligned? > In particular with the current rust definition it is unclear how to represent numbers with more than 38 digits, either because of leading or trailing 0s. The Python docs continue > [Decimal128Type](https://arrow.apache.org/docs/cpp/api/datatype.html?highlight=decimal#classarrow_1_1_decimal128_type) has a maximum precision of 38 significant digits which also seems aligned? -- 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]
