I like the idea about the "top level math project":) Is it possible or interesting to host a sub-project for DSL to commons-math?(such as an enhanced Object-supported matlab-compatible script)
2009/5/23 Edward J. Yoon <edwardy...@apache.org> > Hmm. It's a really great idea. > > I think It could be a top level math project of apache. > > On Fri, May 22, 2009 at 7:37 PM, Sam Halliday <sam.halli...@gmail.com> > wrote: > > > > Edward, Hama looks fantastic! I fully agree, 'distributed' isn't > agreeable > > with commons-math. However, there might be parts of it that are relevant > to > > Hama. > > > > We should absolutely ensure that the "ducks are aligned" between > > commons-math and Hama. It would be win-win if Hama were able to use > > commons-math's linear interfaces. commons-math will hopefully be moving > to > > use a netlib-java style backend (not user facing), we should ensure that > > ScaLAPACK is handled in the same way. > > > > I have some ideas of people who might be interested... I've encountered > them > > as maintainer of MTJ, but never worked with them. I'll dig through my > e-mail > > archive and make the intros. > > > > > > Edward J. Yoon-2 wrote: > >> > >> That's really cool. > >> > >> BTW, Can I ask about the plan of data distribution strategies of your > >> 'distributed' package in the future? IMO, it seems, it doesn't sit > >> well with 'common-math' project. > >> > >> If if there is a developer who wants to implement 'distributed', pls > >> let us know, too. I'm working for the Hama > >> (http://incubator.apache.org/hama) with ScaLAPACK members. > >> > >> On Thu, May 14, 2009 at 7:18 PM, Sam Halliday <sam.halli...@gmail.com> > >> wrote: > >>> > >>> Dear all, > >>> > >>> I am a maintainer of the matrix-toolkits-java > >>> > >>> http://code.google.com/p/matrix-toolkits-java/ > >>> > >>> which is a comprehensive collection of matrix data structures, linear > >>> solvers, least squares methods, eigenvalue and singular value > >>> decompositions. > >>> > >>> This note is in regard to the commons-math library. It is clear that > our > >>> projects dovetail, especially when I look at "linear" in version 2.0 of > >>> the > >>> API. It would be good if we could either complement or consolidate > >>> efforts, > >>> rather than reproduce. > >>> > >>> It would be excellent if all the functionality of matrix-toolkits-java > >>> were > >>> available as part of commons-math. There is already too much diversity > >>> and > >>> un-maintained maths code out there for Java! > >>> > >>> As a start, I'd like to discourage the use of a solid implementation > for > >>> SparseReal{Vector, Matrix}... please prefer an interface approach, > >>> allowing > >>> implementations based on the Templates project:- > >>> > >>> http://www.netlib.org/templates > >>> > >>> The reason is that the storage implementation should be related to the > >>> type > >>> of data being stored. For example, there are many well-known kinds of > >>> sparse > >>> matrix that are well suited to particular kinds of calculations... > >>> consider > >>> multiplying sparse matrices that you know to be diagonal! > >>> > >>> In general, the netlib.org folk (BLAS/LAPACK) have spent a *lot* of > time > >>> thinking about linear algebra and have set up unrivalled standard APIs > >>> which > >>> have been implemented right down to the architecture level. It would be > a > >>> major mistake if commons-math didn't build on their good work. > >>> > >>> I believe commons-math should move to a netlib-java backend (allowing > the > >>> use of machine optimised BLAS/LAPACK). > >>> > >>> http://code.google.com/p/netlib-java/ > >>> > >>> The largest problems facing MTJ are support for Sparse BLAS/LAPACK and > >>> scalability to parallel architectures which use Parallel BLAS/LAPACK. > The > >>> former should be possible with some work within the current API, but I > >>> fear > >>> major API changes would be needed for the latter. I do not want the > >>> commons-math API to walk into this trap without having first considered > >>> future architectures! MTJ has a distributed package, but I am not sure > if > >>> this is something that is completely future proof either. > >>> > >>> What say ye'? > >>> > >>> -- > >>> Sam > >>> > >>> -- > >>> View this message in context: > >>> > http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23537813.html > >>> Sent from the Commons - Dev mailing list archive at Nabble.com. > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >>> > >> > >> > >> > >> -- > >> Best Regards, Edward J. Yoon @ NHN, corp. > >> edwardy...@apache.org > >> http://blog.udanax.org > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > >> > > > > -- > > View this message in context: > http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23668079.html > > Sent from the Commons - Dev mailing list archive at Nabble.com. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > -- > Best Regards, Edward J. Yoon @ NHN, corp. > edwardy...@apache.org > http://blog.udanax.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
