Luc Maisonobe wrote:
>
>> - 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} ?
>
Exactly. In future, it might be wise to use the "subclass return trick" here
too, but leaving it blank for now gives the best options for future
releases.
Luc Maisonobe wrote:
>
> 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.
>
Cool, eh? :-) In Joshua Bloch's book, he recommends being as general as
possible in the parameters and as specific as possible in the return type.
The only problem with being specific in the return type is that you are
stuck with it. For that reason, it's probably best not to do this everywhere
just yet. It's one of those little API details that can be open for change
in the future whilst also being fully backwards compatible ;-)
Luc Maisonobe wrote:
>
>> - 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...
>
OK, that makes sense.
One of the first tasks for MTJ integration can be the inclusion of the many
sparse storage types (and associated numerical optimisations). That's why
I'm keen to have the current sparse implementation be specific about its
"shape" in its name. Otherwise it'll be the odd one out ;-)
--
View this message in context:
http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23576105.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
