On 11/23/11 2:05 AM, Luc Maisonobe wrote: > Le 23/11/2011 09:16, Mikkel Meyer Andersen a écrit : >> 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 :-). > I would very much like to have a simplified API.
+1 > > I also would vevery very much like to see 3.0 released, so if we are > gonna doing some API change here, we should really go forward and do it > fast. I'll start another thread about this. +1 Phil > > Luc > >> 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 >> > > --------------------------------------------------------------------- > 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
