Hi Alex and Gilles,
For the complex functional interfaces, we have so far been working on
different options but all operate on single complex numbers one at a time...
Instead can we design around Functional Interfaces that work on List/Arrays
instead?
Interface ComplexDoubleArray{
/* Methods for set/get by index as well as set/get array ranges on
primitive double arrays*/
void set(int index, int sourceIndex, int len, double[] realAndImgPairs)
void get(int index, int destIndex, int len, double[] realAndImgPairs)
void set(int index, ComplexDouble c)
ComplexDouble get(int index)
Iterator<ComplexDouble> iterator( int index, int length)
DoubleStream realAndImgPairs (int index, int length)
...
}
@FunctionalInterface
Interface ComplexDoubleUnaryOperator{
void apply(ComplexDoubleArray input, ComplexDoubleArray output, int
inputoffset, int outputoffset, int length);
}
This has following advantages
1) iterating implementations over lists will now be in the complex function
instead of ComplexList data structures allowing for different
implementations. For example we could have multi threaded java.util.stream
based operation on lists and single threaded cursor while loop based
implementation as suggested before by Alex.
2) it will be required to take advantage of simd parallelism as discussed
before. For example conjugate operation on Complex list (double[] of real
and imaginary pairs) would be vector multiplication with array [
1,-1,1-1,..]
If functional interface enforce operation on one complex number at a time,
we might not be able take advantage of simd optimizations?
3) operation on single complex number is now just operation on list/array
of size 1. We can make existing Complex class implement ComplexDoubleArray
interface
Thanks
Sumanth
On Sat, Jun 11, 2022, 11:00 Sumanth Rajkumar <rajkumar.suma...@gmail.com>
wrote:
>
>
> 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
>
>
