On Fri, Jun 10, 2022, 19:30 Gilles Sadowski <gillese...@gmail.com> wrote:
> The current implementation of "Complex" encapsulates two "double" fields > (not > a "double[]"). > Should we make two, at first separate, discussions: One for the > implementation > of the "complex number" concept, and another for (n-dimensional) lists of > them? > Yes. We could also change existing Complex type from two double fields to double[] and even make it implement new ComplexNumber interface? This should maintain runtime compatibility? For the interface, I suggest ComplexDouble (and ComplexFloat) intead of ComplexNumber? > A) ComplexCartesianImpl data structure will change to double[] > > realAndImgPair > > What gain do you expect from involving an array here? > We can make Complex class implement new ComplexList and ComplexNumber interface.. I was thinking this would allow efficient reuse of functions processing lists also to be used on single numbers (Complex) which is also a list of size 1 > B) ComplexList can use single double[] for realAndImg parts (similar to > all > > external implementations such as jtransform) > > Yes (because of the gain in RAM usage). > But AFAICT, the goal would be to make the "double[]" an "implementation > detail" of "ComplexList" and have all operators handle "ComplexList" (or > any n-dimensional "cube") as their input/output (?). > > Yes. Also looking at jtransform naming, I suggest ComplexDoubleArray (and ComplexFloatArray) instead of ComplexList? Jtransform has support for large arrays (size greater than integer.max with array index of type long. Do we need to support that now or add that support later if needed? Thanks Sumanth
