Sam Halliday a écrit :
> 
> 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.

Perhaps having a single additional method getSparcity() or
getLoadRatio() returning the ratio of elements set to the total number
as a double  would be useful ?

> 
> 
> 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 ;-)
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to