On May 10, 2011, at 8:18 AM, "Sebastien Brisard" 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