It certainly could be. Would float16 be done as a canonical extension type if it were proposed today?
On Thu, Nov 9, 2023 at 9:36 AM David Li <lidav...@apache.org> wrote: > cuDF has decimal32/decimal64 [1]. > > Would a canonical extension type [2] be appropriate here? I think that's > come up as a solution before. > > [1]: https://docs.rapids.ai/api/cudf/stable/user_guide/data-types/ > [2]: https://arrow.apache.org/docs/format/CanonicalExtensions.html > > On Thu, Nov 9, 2023, at 11:56, Antoine Pitrou wrote: > > Or they could trivially use a int64 column for that, since the scale is > > fixed anyway, and you're probably not going to multiply money values > > together. > > > > > > Le 09/11/2023 à 17:54, Curt Hagenlocher a écrit : > >> If Arrow had a decimal64 type, someone could choose to use that for a > >> PostgreSQL money column knowing that there are edge cases where they may > >> get an undesired result. > >> > >> On Thu, Nov 9, 2023 at 8:42 AM Antoine Pitrou <anto...@python.org> > wrote: > >> > >>> > >>> Le 09/11/2023 à 17:23, Curt Hagenlocher a écrit : > >>>> Or more succinctly, > >>>> "111,111,111,111,111.1111" will fit into a decimal64; would you > prevent > >>> it > >>>> from being stored in one so that you can describe the column as > >>>> "decimal(18, 4)"? > >>> > >>> That's what we do for other decimal types, see PyArrow below: > >>> ``` > >>> >>> pa.array([111_111_111_111_111_1111]).cast(pa.decimal128(18, 0)) > >>> Traceback (most recent call last): > >>> [...] > >>> ArrowInvalid: Precision is not great enough for the result. It should > be > >>> at least 19 > >>> ``` > >>> > >>> > >> >
