commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] Exceptions for matrix operations
Date Tue, 10 May 2011 18:33:35 GMT




On May 10, 2011, at 8:18 AM, "Sebastien Brisard" <sebastien.brisard@m4x.org> wrote:

>> [...]
>> The question is thus: Is it OK to provide pointless methods?
>> I also wonder whether it is reasonable to _generate_ state variables just
>> so that the accessors can return them.
>> Usually, when a exception is constructed, it is _passed_ data that provide
>> the context of the failure (i.e. the vectors or the indices that show the
>> problem).
>> In this case, if the test (that triggered the exception) was not performed
>> using vectors, it looks quite strange to be able to retrieve vectors...
>> 
>> 
>> Gilles
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> 
> OK, Gilles, sorry, I do not want to offend anyone, nor do I think I'm the best
> judge of all solutions proposed so far. I agree that constructing vectors just
> for the sake of having one exception inherit from another is far-fetched. I'm
> actually impressed by the depth of the discussions! You all DO think a lot
> about the overall design of this library (well, I guess you have too, but
> still).
> 
> So if I understand correctly, we are back to one base classe which does pretty
> much nothing, and two derived exceptions
> 1. one raised when coefficients of the matrix are accessible, and a(i,j) !=
> a(j,i) (within a specified tolerance),
> 2. one raised when coefficients of the matrix are not accessible, and x'.A.y
> != y'.A.x
> 
> So we still need a little bit of terminology there... For your information,
> I've decided to call (for lack of a better name) LargeRealMatrix the interface
> corresponding to matrices defined only by their matrix-vector product y = A.x.
> These objects are the basic brick of the iterative solvers I'm implementing.


I would call this a LinearOperator or LinearTransformation.

> 
> If we agree that a LargeRealMatrix is only defined by this product, then a
> symmetric, large matrix must be defined as x'.A.y = y'.A.x. (This is actually
> the mathematical definition of an adjoint operator). Then, it would be logical
> to call the corresponding exception NotASymmetricLargeMatrix, would it not?


I would see something like NotAdjointOperatorException or as natural here.   Given the abstract
operator context above, there is no reason for this to extend NonSymmetricMatrixException.


> 
> Alternatives might be LinearMap, LinearOperator, since we actually define the
> matrix A as a function x\mapsto y = A.x, here.
> 
> So, it's pretty much your call. You tell me, and I'll update my sources before
> comitting them. You can then decide wether it's worth including in
> commons-math.
> 
> Best regards for now,
> S├ębastien
> 
> ---------------------------------------------------------------------
> 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