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).
- rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix, Vector}.
Implement above interfaces.
- 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.
- is it too late to define a Norm enum and take that as a parameter, rather
than explicit methods for each Norm type?
Other than that, looks good and I can't see any obvious conflicts that would
void an MTJ merge! Most of the changes will be internal anyway, depending
primarily on the path forward for BLAS/LAPACK use.
Sam Halliday wrote:
>
> can I be involved in an API review to minimise any future problems? This
> might involve some API changes from today's snapshot (although, no extra
> features or anything heavy like that).
>
--
View this message in context:
http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23575831.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
