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? > 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? Should we have a common interface (minimum methods/operations that all implementations should support)? 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? Thanks, Sumanth [1] http://ejml.org/wiki/index.php?title=Main_Page#:~:text=EJML%20has%20three,of%20writing%20equations On Fri, 29 Jul 2022 at 10:41, Gilles Sadowski <gillese...@gmail.com> wrote: > Hello. > > Le jeu. 28 juil. 2022 à 22:28, Sumanth Rajkumar > <rajkumar.suma...@gmail.com> a écrit : > > > > Hi, > > > > I've completed the task of refactoring all complex operations to static > > functions and it has been merged to the complex-gsoc-2022 branch. Thank > you > > for all the help to make this happen. > > > > I wanted to talk about the next task and get some inputs from all of you > on > > how to start. > > > > Now, I'm going to be working on complex list and matrix support. I have > > already begun working on this which can be seen in my github branch [1]. > > > > Right now, my work is based on the idea of a mutable list representation > of > > a set of complex numbers (List<Complex>) using a backing double[] for > > storage. > > > > I know Matt mentioned using Buffers as well and so I was hoping if you > can > > give a little more detail about this. If there are any other suggestions, > > please let me know. > > > > Thanks, > > > > Sumanth > > > > [1] > > > https://github.com/sumanth-rajkumar/commons-numbers/tree/NUMBERS-186.complex_list_and_matrix_support > > I think that Alex's suggestion still holds: Better focus on one > task at a time. Are the "list" and "matrix" features related? > > 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? > > Do we target linear algebra for complex numbers? > What use-cases for the "ComplexMatrix" and "ComplexVector" > interfaces? > > Regards, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
