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 ?
> - 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.
> - 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.
>
> 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.
Fine.
Luc
>
>
> 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).
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
