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, email: devunsubscribe@commons.apache.org
>> For additional commands, email: devhelp@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 farfetched. 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 matrixvector 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
> commonsmath.
>
> Best regards for now,
> Sébastien
>
> 
> To unsubscribe, email: devunsubscribe@commons.apache.org
> For additional commands, email: devhelp@commons.apache.org
>

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
