> >> [...] > >> 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 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).
Certainly, no offense taken! Your use-case 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 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. +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 > > commons-math. Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
