Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4A168704.1030607@free.fr>
Date: Fri, 22 May 2009 13:05:40 +0200
From: Luc Maisonobe <Luc.Maisonobe@free.fr>
User-Agent: Thunderbird 2.0.0.21 (X11/20090409)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: commons-math, matrix-toolkits-java and consolidation
References: <23537813.post@talk.nabble.com>
 <eb4706e0905211914i7cd52334o3f25ad641a293e5b@mail.gmail.com>
 <23668079.post@talk.nabble.com>
In-Reply-To: <23668079.post@talk.nabble.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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.halliday@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> -- 
>> Best Regards, Edward J. Yoon @ NHN, corp.
>> edwardyoon@apache.org
>> http://blog.udanax.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org