commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebastien Brisard" <sebastien.bris...@m4x.org>
Subject Re: [math] Exceptions for matrix operations
Date Tue, 10 May 2011 12:17:20 GMT


2011/5/10 Gilles Sadowski <gilles@harfang.homelinux.org>
>
> On Mon, May 09, 2011 at 08:52:57PM +0200, Sébastien Brisard wrote:
> > 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.
>
> -0
>
> > >>>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.
>
> That those getters will be defined in "BasicNonSymmetricMatrixException"
> but won't be initialized in "NonSymmetricMatrixException", is another
> reason for having two distinct exceptions deriving from a common base
class.

I don't agree there: these getters are still meaningful in
"NonSymmetricMatrixException". For the sake of the argument, let's call them
getFirstOffendingVector and getSecondOffendingVector. If
NonSymmetricMatrixException is raised by
|a[i,j] - a[j,i]| > tol,
then
  - getFirstOffendingVector could return (construct) ei = [0, ..., 1, ..., 0]
(i-th component is the only non-zero value)
  - similarly, getSecondOffendingVector could return (construct) ej.
On top of that, NonSymmetricMatrixException would still implement getRow(),
getColumn(), while the base class BasicSymmetricMatrixException would only
implement getFirstOffendingVector and getSecondOffendingVector.

In this case, getRow() and getColumn() make the more general methods
getFirstOffendingVector and getSecondOffendingVector pretty much pointless,
but *not meaningless*.

>
> > >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.
>
> Indeed.
> This option eliminates the possibility to selectively access the vectors.
> As Sébastien indicated, it is not reasonable to include them in the error
> message. [As I have advocated at length, this example independently shows
> that error handling cannot be "message-centric", and that stateful
exception
> classes are important because they provide flexibility to the application
> programmer.]
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

Sébastien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message