commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: (MATH-608) Remove methods from RealMatrix Interface
Date Sun, 03 Jul 2011 02:41:39 GMT
It really is hard to avoid runtime checks in this kind of code.   You can do some things in
types but it is really hard to get the structure right. 

Requiring a symmetric or positive definite matrix is a lot like requiring a positive real
value as a parameter. We *could* define a special type for that but a runtime check is nicer.


Sent from my iPhone

On Jul 2, 2011, at 12:58, Sébastien Brisard <sebastien.brisard@m4x.org> wrote:

> But if you have a method taking as an input a matrix which MUST be both symmetric and
banded, you are bound to define a new interface.
> Am I wrong?
> Maybe the alternative you are thinking of is testing "instanceof SymmetricMatrix" and
"instanceof BandedMatrix" in the implementation of the method, instead of specifying the required
matrix in the declaration of the method?
> 
> Le 02/07/11 21:18, Greg Sterijevski a écrit :
>> Not a stupid concern in my book. However there is a synchronization
>> mechanism in place. We are taking part in it right now. Whether the new
>> matrix implements both SymmetricMatrix and BandedMatrix or is a new tagging
>> interface (SymmetricBanded) would determined in the list, after a bit of
>> back and forth.
>> 
>> 2011/7/2 Sébastien Brisard<sebastien.brisard@m4x.org>
>> 
>>> Marker interface seems to be a very elegant solution. I am just wondering
>>> about a potential issue. Let us assume we defined two interfaces, say
>>> SymmetricMatrix, and BandedMatrix. User A writes a matrix class which
>>> implements both interfaces. Meanwhile, user B implements an algorithm which
>>> requires a symmetric, banded matrix. Presummably, user B will define a new
>>> marker interface, which extends both SymmetricMatrix and BandedMatrix. So we
>>> have on the one hand
>>> 
>>> class UserAMatrix implements SymmetricMatrix, BandedMatrix;
>>> 
>>> and
>>> 
>>> UserBAlgorithm.operate(**BandedSymmetricMatrix).
>>> 
>>> One day, user A hears of the work of user B. The matrix he has implemented
>>> has just the required features (symmetric *and* banded). But it does not
>>> implement BandedSymmetricMatrix, so he cannot apply UserBAlgorithm.operate
>>> to an instance of UserAMatrix. There is always the possibility of creating a
>>> new class which extends UserAMatrix and implements BandedSymmetricMatrix,
>>> but that would obfuscate the hierarchy tree. Is this a problem? Is that a
>>> stupid remark?
>>> 
>>> Sebastien
>>> 
>>> 
>>> 
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<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
> 

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


Mime
View raw message