commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] Exceptions for matrix operations
Date Mon, 09 May 2011 11:27:58 GMT

> 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
     * @param wrong Row dimension.
     * @param expected Column dimension.

Hence I would leave it as is.

> 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?

That were my 2 cents.

Best regards,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message