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
