> Is Hama related to Hadoop ? Yes, it is.
On Fri, May 22, 2009 at 8:05 PM, Luc Maisonobe <luc.maison...@free.fr> wrote: > Sam Halliday a écrit : >> 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. > > Is Hama related to Hadoop ? > >> >> 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 >>> >>> >>> >> > > > --------------------------------------------------------------------- > 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
