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 (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: edward@udanax.org
In-Reply-To: <4A168704.1030607@free.fr>
References: <23537813.post@talk.nabble.com>
	 <eb4706e0905211914i7cd52334o3f25ad641a293e5b@mail.gmail.com>
	 <23668079.post@talk.nabble.com> <4A168704.1030607@free.fr>
Date: Sat, 23 May 2009 02:13:30 +0900
Message-ID: <eb4706e0905221013x42372f4fib9845ae6c004d1d2@mail.gmail.com>
Subject: Re: commons-math, matrix-toolkits-java and consolidation
From: "Edward J. Yoon" <edwardyoon@apache.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> Is Hama related to Hadoop ?

Yes, it is.

On Fri, May 22, 2009 at 8:05 PM, Luc Maisonobe <Luc.Maisonobe@free.fr> wrot=
e:
> Sam Halliday a =C3=A9crit :
>> Edward, Hama looks fantastic! I fully agree, 'distributed' isn't agreeab=
le
>> 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
>>>>
>>>> =C2=A0http://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 o=
ur
>>>> projects dovetail, especially when I look at "linear" in version 2.0 o=
f
>>>> 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 f=
or
>>>> SparseReal{Vector, Matrix}... please prefer an interface approach,
>>>> allowing
>>>> implementations based on the Templates project:-
>>>>
>>>> =C2=A0http://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 ti=
me
>>>> thinking about linear algebra and have set up unrivalled standard APIs
>>>> which
>>>> have been implemented right down to the architecture level. It would b=
e 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).
>>>>
>>>> =C2=A0http://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 considere=
d
>>>> 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-consoli=
dation-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
>
>


--=20
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