Le 09/05/11 17:31, Phil Steitz a écrit :
On 5/9/11 4:27 AM, Gilles Sadowski wrote:
Hi.
I'm currently trying to integrate my implementation of iterative linear
solvers in the commons-math architecture.
Thanks for contributing.
Among other things, I want to reuse
as many existing exceptions as possible. I've come accross the following
points
1. naming the parameters in the constructor of NonSquareMatrixException
"wrong" and "expected" is somewhat misleading. They should really be called
something like "rowDimension", "columnDimension". If you agree on this, I can
easily submit a patch.
Do you want to just change the formal parameters' names?
The rationale for the current naming is by reference to the base class
where, by convention, the first parameter is the "wrong" one.
Also, note that the Javadoc provide the other piece of info (i.e. your
point):
---
* @param wrong Row dimension.
* @param expected Column dimension.
---
Hence I would leave it as is.
I agree with Sebastien here. It makes no sense to call one of the
dimensions "wrong" and the other "expected." The problem is that
they are different. The message correctly reports them as row and
column dimensions. The formal parameter names should be changed.
2. NonSymmetricMatrixException. Looking at the constructor for this exception,
it is assumed that the only way to check for symmetry of matrix A is by
comparing A[i, j] and A[j, i]. Another commonly encountered case is the
comparison of the vectors A.x and x'.A, where ' stands for the transpose. In
this case, it is not really possible (or even desirable) to locate the exact
coefficient of matrix A which led to failure. What's the best way to handle
this?
2.1 Create a new type of exception? I think it is a messy solution
I think that this is the right way.
I guess that, being more general, the new exception would be a base class of
the current one.
However, I don't know what new names should be given to these 2 exceptions.
Is there some standard, concise, way to refer to how the test (A x != xT A)
is performed?
2.2 Add new constructors to the existing exception ? But then, the getters
getRow() and getColumn() would not always be meaningful.
Indeed, and that's not a desirable feature of a class.
3. Same remark goes to NonPositiveDefiniteMatrixException. We *should* be able
to raise such an exception when a calculation leads to x'.A.x< 0. Again, it
is neither possible, nor desirable to locate the coefficient which is
inconsistent.
The same solution as for (2.) should be applied here too.
I do not really see a satisfactory solution for points 2 and 3. Any ideas?
I agree that it is messy, but unfortunately while the mathematical
concept is the same in each case above, the exception is in fact
different, partly because of the tolerances involved. The
exceptions based on matrix operation invariants (e.g. xTA = Ax for A
symmetric) will have to have tolerances expressed as norms and the
values of these parameters are important and meaningful only for the
instances witnessed in this way.
In fact, such an exception would be raised if the program stumbles upon
to vectors x and y such as x'Ay differs from y'Ax. So, the existing
NonSymmetricMatrixException would be a particular case of a more general
(BasicNonSymetricMatrixException ?), with x = ei and y = ej. In this
case, the meaning of the tolerance would be the same for both exceptions.
So, messy as it is, I agree with
Gilles that the best solution is to have both forms of witnessed
exceptions derive from a common base. So, for example,
NonSymmetricMatrixException has something like
MatrixSymmetryException and SymmetricOperationException as subclasses.
So maybe instead of creating two new exceptions, maybe one would be enough?
BasicNonSymmetricMatrixException
+--NonSymmetricMatrixException
Imagine for a moment we go for this solution. Then it would be nice (for
debugging purposes), to be able to retrieve x and y from
BasicNonSymmetricMatrixException. These vectors would however presumably
be huge, so it's out of the question to print them in the error message.
They should just be available, which requires to create new getters.
The only reasonable alternative here would be to go back to loading
the witness information into the message, eliminate the state
variables, define a new message and add a constructor that takes a
vector and norm tolerance as argument and keep it all in
NonSymmetricMatrixException. I would be fine with that; but I am
sure others would disagree with it.
Phil
That were my 2 cents.
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
By the way, can I ask a question : what are getContext/setContext used for ?
Best regards,
Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
