> >> [...]
> >> 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...
> >>
> >>
> > 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).
Certainly, no offense taken!
Your usecase did provide an interesting viewpoint.
> > 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.
+1
[With a slight preference for a name containing "Operator" if the
exception's name will contain it too (cf. below).]
> >
> > 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.
Maybe "NonAdjointOperatorException" (like "NonSymmetricMatrixException")?
> Given the abstract operator context above, there is no reason for this to extend NonSymmetricMatrixException.
+1
> >
> > 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.
Regards,
Gilles

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