> Is Hama related to Hadoop ?
Yes, it is.
On Fri, May 22, 2009 at 8:05 PM, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:
> Sam Halliday a écrit :
>> Edward, Hama looks fantastic! I fully agree, 'distributed' isn't agreeable
>> with commonsmath. 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
>> commonsmath and Hama. It would be winwin if Hama were able to use
>> commonsmath's linear interfaces. commonsmath will hopefully be moving to
>> use a netlibjava 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 email
>> archive and make the intros.
>>
>>
>> Edward J. Yoon2 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 'commonmath' 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 matrixtoolkitsjava
>>>>
>>>> http://code.google.com/p/matrixtoolkitsjava/
>>>>
>>>> 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 commonsmath 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 matrixtoolkitsjava
>>>> were
>>>> available as part of commonsmath. There is already too much diversity
>>>> and
>>>> unmaintained 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 wellknown 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 commonsmath didn't build on their good work.
>>>>
>>>> I believe commonsmath should move to a netlibjava backend (allowing the
>>>> use of machine optimised BLAS/LAPACK).
>>>>
>>>> http://code.google.com/p/netlibjava/
>>>>
>>>> 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
>>>> commonsmath 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/commonsmath%2Cmatrixtoolkitsjavaandconsolidationtp23537813p23537813.html
>>>> Sent from the Commons  Dev mailing list archive at Nabble.com.
>>>>
>>>>
>>>> 
>>>> To unsubscribe, email: devunsubscribe@commons.apache.org
>>>> For additional commands, email: devhelp@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> 
>>> Best Regards, Edward J. Yoon @ NHN, corp.
>>> edwardyoon@apache.org
>>> http://blog.udanax.org
>>>
>>> 
>>> To unsubscribe, email: devunsubscribe@commons.apache.org
>>> For additional commands, email: devhelp@commons.apache.org
>>>
>>>
>>>
>>
>
>
> 
> To unsubscribe, email: devunsubscribe@commons.apache.org
> For additional commands, email: devhelp@commons.apache.org
>
>

Best Regards, Edward J. Yoon @ NHN, corp.
edwardyoon@apache.org
http://blog.udanax.org

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
