Hi, I have made a preliminary complex list implementation class which is backed by a single double array in interleaved format. I made some test cases for the forEach methods as well. This can be viewed here [1]. Please let me know what you think and if I'm on the right track.
Thanks, Sumanth [1] https://github.com/sumanth-rajkumar/commons-numbers/tree/NUMBERS-186.complex_list_support/commons-numbers-complex/src On Tue, 2 Aug 2022 at 13:26, Sumanth Rajkumar <rajkumar.suma...@gmail.com> wrote: > 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 >> >
