commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Halliday <>
Subject Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Date Thu, 21 May 2009 15:35:12 GMT

Luc, it absolutely would help the compiler... but the point is that the
return types might not remain as they currently are in future releases. For
example, if you multiply a dense matrix and a diagonal matrix... does it
make sense to return a dense matrix? No. :-)

Incidentally, in MTJ we have a mechanism to allow the client to decide on
the storage type for return types. It's a bit clunky, and I'd prefer a
factory approach. I'd like to open up the debate on a mechanism in
commons-math for doing this post-2.0.

Luc Maisonobe wrote:
>> - changing the return type to be actual classes was only supposed to be
>> for
>> copy() for 2.0. Doing this on multiply, add, etc is a big mistake...
>> there
>> is no guarantee that is the best thing to do and it is likely this will
>> change in the future. This stands for all implementations. Great thought
>> needs to go into each method, not just by reading the current
>> implementation.
> It may help the compiler using directly the optimized versions in
> statements like:
>   m1.add(m2.multiply(m3.subtract(m4))

View this message in context:
Sent from the Commons - Dev mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message