Thanks Alex for the feedback, I'll work on a ComplexList class that implements the List interface and is backed by a single double array in interleaved format. I'll have something ready to look at by tomorrow.
Thanks, Sumanth On Tue, 2 Aug 2022 at 03:52, Alex Herbert <alex.d.herb...@gmail.com> wrote: > On Mon, 1 Aug 2022 at 17:38, Sumanth Rajkumar <rajkumar.suma...@gmail.com> > wrote: > > > Hi, > > > > > I think that Alex's suggestion still holds: Better focus on one > > > task at a time. Are the "list" and "matrix" features related? > > > > OK, Will focus on list features first and focus on extending all existing > > methods on the Complex class to Lists. > > > > UnaryOperators will apply the operation (using refactored static methods) > > to each element. > > BinaryOperators for lists will have two variants. > > For the first variant, the second operand is a single complex number that > > is applied as second operand for all elements on List > > The second variant operates on two Lists. Can we look at this later? > > > > For an operand that is a single complex number then this should be > satisfied by passing a lambda function to the unary forEach. The same would > be the same for a single double factor. So these seem redundant and can be > covered by documentation. > > I would suggest you create a List<Complex> implementation that only > satisfies the list interface in an optimal manner. If you extend > java.util.AbstractList the minimal implementation is often not optimal for > the storage (for example the spliterator and the forEach constructs). > > The support for a JDK Collection may not have to add any additional methods > for processing. It would merely replace using ArrayList<Complex>. Numerical > processing of complex numbers could be added instead to a more focussed > data structure that does not support the entire Collection API, i.e. the > vector and matrix concepts previously proposed. > > > > > > > Do we have one use case for the "list" feature? > > > I see there a lot factory methods that seem to defeat the > > > intended purpose (AFAIU Matt's remark) of letting the caller > > > decide on the input format. > > > Similarly, the "parse" feature should be left to the code that > > > handles the input. IOW shouldn't we separate the concerns > > > of converting the input (array, stream, list of strings, ...) from > > > what can be done with a "list" instance? > > > > Since the lists can have different underlying data storage > implementations > > such as > > a) single double primitive array or DoubleBuffer in interleaved format > > b) single double primitive array or DoubleBuffer in sub array format > > c) separate arrays/DoubleBuffers for real and imaginary parts > > > > Based on earlier discussions, Alex wanted the iteration logic over the > list > > to apply the operators to be within the List implementation > > So each implementation will have its own implementation of operators that > > is optimal for its data storage > > > > For now, should we focus on more than 1 implementation? If it is just 1 > > implementation, which one can I pick up first? > > > > 1 implementation is the best start point to build the API. > > > > Should we have a common interface (minimum methods/operations that all > > implementations should support)? > > > > That makes sense. However a known backing format for the data will allow > optimal computation. So once the API is established for a single data > structure format we can test speed of computation when mixing backing data > structures. > > > > > > If so, I can first focus on finalizing the List interface and then look > at > > implementations > > > > I was also looking at the EJML api's [1]. > > They support three API styles a) Procedural b) SimpleMatrix and c) > > Equations (Matlab style) > > > > It looks like we will be implementing the SimpleMatrix style. Should we > > also consider other approaches? > > > > Equations requires parsing text input. I would put that out-of-scope. I > would say an OO style is the most natural from a Java perspective. The API > could be similar to the matrix functionality in Commons Math. > > Alex >
