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 (athena.apache.org: domain of
 SRS0=Tu6y=X7=m4x.org=sebastien.brisard@bounces.m4x.org designates
 129.104.30.34 as permitted sender)
Message-ID: <4DC83809.6070508@m4x.org>
Date: Mon, 09 May 2011 20:52:57 +0200
From: =?UTF-8?B?U8OpYmFzdGllbiBCcmlzYXJk?= <sebastien.brisard@m4x.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr;
 rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] Exceptions for matrix operations
References: <20110509072447.0CD8614000644@svoboda.polytechnique.org>
 <20110509112758.GA16459@dusk.harfang.homelinux.org>
 <4DC808EC.2080906@gmail.com>
In-Reply-To: <4DC808EC.2080906@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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-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
>
By the way, can I ask a question : what are getContext/setContext used for ?
Best regards,
Sebastien


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