> > 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.
It seems like maybe this is an area to focus on? I'm not sure conceptually simple is the right criteria to apply here. For instance Complex number appear to be a user defined type in Postgres [1]. [1] https://www.postgresql.org/docs/9.0/xoper.html On Wed, Jun 9, 2021 at 2:25 PM Wes McKinney <wesmck...@gmail.com> wrote: > 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. >
