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: http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23655328.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
