On Wed, Jun 9, 2021 at 11: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
Agreed. As Micha mentioned, adding these types don't seem to interfere with
any existing protocol, I'd like to take this approach going forward.
> , 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)
>
I believe that this is the binary representation in C, C++, Native Python
and NumPy.
Does Arrow support adapters If the native binary representation in other
languages
(Java/Rust/R/Julia) don't have a matching binary representation?
Does the C/C++ representation take precedence?
- Java does not seem to natively support complex numbers:
https://stackoverflow.com/questions/2997053/does-java-have-a-class-for-complex-numbers.
There's an Apache Commons but the imaginary may be packed before the real:
class
https://github.com/apache/commons-numbers/blob/9b67b8e6890a47dcfc26388da2b4ee03758a9a94/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java#L228-L231
- Rust does not natively support complex numbers:
https://users.rust-lang.org/t/complex-number-in-rust-language/41081/3,
but there's a num_complex crate that supports the C/C++ style packed
struct:
https://autumnai.github.io/cuticula/num/complex/struct.Complex.html
- Julia seems to support the C/C++ style packed struct:
https://github.com/JuliaLang/julia/blob/f1174888e8b9351a76996db328db13f130c23af8/base/complex.jl#L13-L16
- I don't know R at all, but I'd imagine it's stance towards data is
Python/Numpy-like. Can anyone provide input here?
Regards,
Simon
> 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.
>
