Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Date: Tue, 10 May 2011 12:58:27 +0200
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [math] Exceptions for matrix operations
Message-ID: <20110510105827.GR2279@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: <20110509072447.0CD8614000644@svoboda.polytechnique.org>
 <20110509112758.GA16459@dusk.harfang.homelinux.org>
 <4DC808EC.2080906@gmail.com>
 <4DC83809.6070508@m4x.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4DC83809.6070508@m4x.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-DCC-scarlet.be-Metrics: eir 20002; Body=1 Fuz1=1 Fuz2=1
X-Virus-Checked: Checked by ClamAV on apache.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.

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