I think that having a top-level type for complex numbers would be
nicer than extension types, so it would look like
table Complex {
precision: Precision;
}
and the representation is a packed tuple of two floating point numbers
of the indicated precision (I think this is the standard way that
people do complex numbers, but would be good to know if there are any
variations out there)
On Wed, Jun 9, 2021 at 12:56 PM Antoine Pitrou <anto...@python.org> wrote:
>
>
> Le 09/06/2021 à 17:52, Micah Kornfield a écrit :
> >
> > Adding a new first-class type in Arrow requires working integration tests
> > between C++ and Java libraries (once the idea is informally agreed upon)
> > and then a final vote for approval. We haven't formalized extension types
> > but I imagine a similar cross language requirement would be agreed upon.
> > Implementation of computation wouldn't be required for adding a new type.
> > Different language bindings have taken different approaches on how much
> > additional computational elements are packaged in them.
>
> While dedicated types are not strictly required, compute functions would
> be much easier to add for a first-class dedicated complex datatype
> rather than for an extension type.
>
> Since complex numbers are quite common in some domains, and since they
> are conceptually simply, IMHO it would make sense to add them to the
> native Arrow datatypes (at least COMPLEX64 and COMPLEX128).
>
> Regards
>
> Antoine.
