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
