commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Date Sun, 17 May 2009 16:07:00 GMT
Phil Steitz a écrit :
> Luc Maisonobe wrote:
>> Sam Halliday a écrit :
>>> I've had a quick look at the 2.0 API and the only changes I'd like to
>>> request
>>> are:-
>>> - create interfaces RealSparse{Matrix, Vector} to indicate a sparse
>>> storage
>>> implementation. Can be empty (for now).
>> I suppose these interfaces would extend Real{Matrix, Vector} ?
>>> - rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix,
>>> Vector}.
>>> Implement above interfaces.
>> I have no opinion on that. What do others think ?
> +1 for "dethroning" ;)
> With the new interfaces, we could also drop the "Sparse" from the name -
> i.e, "OpenMapRealMatrix"
> I am wondering now whether similar marking and "dethroning" should
> happen on the dense side - i.e DenseReal{Matrix, Vector},
> BlockRealMatrix (currently DenseRealMatrix), ArrayRealMatrix (currently
> RealMatrixImpl)?

+1. This is simple for DenseRealMatrix since it has been created after
1.2, but RealMatrixImpl may induce more problems to users. Should we
copy an deprecate ?

>>> - implementations should subclass the return type of some methods in the
>>> Real{Matrix, Vector} API. e.g. RealVectorImpl.copy() returns a
>>> RealVector,
>>> but could declare that it returns a RealVectorImpl. This will avoid
>>> needless
>>> user casts. In future APIs, this could be a powerful way to define the
>>> return type of matrix-matrix computation when the storage classes are
>>> known... e.g. declaring that you return a DiagonalMatrix.     
>> I didn't know changing the return type to a subtype was allowed when
>> implementing an interface! This is for sure a good thing to do and could
>> probably be used in many other places too.
> +1 in general, but need to realize that when implemented, this changes
> locks us in.  In the specific cases mentioned above, this is a
> no-brainer, but there are others (mostly in the decomp classes) where it
> is not so obvious.
>>> - is it too late to define a Norm enum and take that as a parameter,
>>> rather
>>> than explicit methods for each Norm type?
>> There are many places where we use the same pattern outside of linear
>> algebra. I'm reluctant to change this because if we extend the enum
>> later, we may forget to add a new case in all implementations (somewhere
>> in a switch statement), so we should add an exception for defensive
>> programming. A method name enforced in an interface prevent such errors,
>> you cannot compile your implementation if you forget a method.
> Agree with Luc on this, but more from a Java style than maintenance
> standpoint.  We have tried in general to stay away from "behavior flags"
> in method signatures up to now.
> Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message