commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


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


Mime
View raw message