Hello, as agreed, I've started a JIRA ticket on this long-standing issue (see MATH-765). This ticket is really meant as a summary of the discussions which should take place on the mailing list, so please refrain from adding comments (unless absolutely necessary). Children tickets will be linked to this parent ticket once we agree on concrete tasks.
At the moment, there is nothing really fancy on this ticket. I merely compared the interfaces of RealMatrix and RealVector, and drew a few conclusions. I would be interested by your feed-back on the comments I've made. My first suggestion would be on the visitor design pattern vs. map(UnivariateFunction). The former is specified in the RealMatrix interface, the latter is specified in the RealVector abstract class. I think both concepts are similar, and both are useful: - visitors know about the cell they are visiting, - map() doesn't. Maybe it would be nice as a first step to unify these concepts. Two options there 1. Specify both in both interfaces, 2. Specify only the visitor design pattern, and create a factory which would return a visitor from a UnivariateFunction (ignoring the indices of the current cell). A second step could then be to remove most of the norm calculations from the matrix and vector interfaces, and implement these functionalities as visitors. Other major issues are - tagging interfaces/marker methods to dispatch the objects to the most optimized algorithm (e.g. multiplication of sparse, symmetric, and so on matrices). See http://markmail.org/thread/vkwe5x2jtozcjkge http://markmail.org/thread/j4xjdtchpw33xpgr - implementation of "views" of a matrix/vector. IIRC, Ted suggested such a feature a while ago. This would be a very useful feature (just like a[3:5] in matlab, octave, python and the likes). This I think would also be a very useful addition. These are just a few thoughts, I'm curious to read what everyone thinks. Thanks beforehand for your feedback! Sébastien --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
