I also think it is a good idea, but with the addition of thinking parallelisation into the framework (e.g. in the map functionality). Whether it should be done in a branch or not, I don't know, but I guess the people who do know will reply on that :-).
Cheers, Mikkel. 2011/11/23 Ted Dunning <ted.dunn...@gmail.com>: > I still think it is a good idea. > > Sent from my iPhone > > On Nov 22, 2011, at 23:27, Sébastien Brisard <sebastien.bris...@m4x.org> > wrote: > >> Hello, >> I would like to revive a discussion which took place a few months ago, >> about the design of the matrix and vector classes. As far as I remember, >> what came out was that these classes would benefit from a more functional >> approach, à la Mahout. Additionally, I think Ted suggested that we >> introduce Views of a given matrix. I know we should be careful not to be >> too quick, but I think we should give it a go. During our discussions, it >> came out that RealVector and RealMatrix had useful embryos of functional >> features >> - RealVector.map(UnivariateRealFunction f) >> - RealMatrix.walkXxx(visitor) >> these features are somewhat similar, except for the fact that >> RealVector.map never sees the index of the current cell. >> A first step might be to unify these two interfaces >> - Implement visitors for RealVector, >> - possibly add a map(UnivariateRealFunction f) to Matrix. >> As a second (big step), we could try and clean up the interfaces for >> Vectors and Matrices, defining as many Visitors as possible, instead of >> cluttering the corresponding interfaces (keeping, of course, performance >> issues in mind). >> >> What do you think? Should we give it a go? At this point, people already >> suggested that this should be done in a branch? >> >> Best regards for now, >> Sébastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
