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 phil.steitz@gmail.com
 designates 209.85.160.43 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=Gwos8cpKwdT0DIdlO4g/IJlkaSgFcA02kx/8cN2AkgQv1dVc0Mgx4HGZEI/F5ZKg0V
         Rwx4WeehGZ36zhDT2nGKVphIEz4mvwX+UzGw31MnGs6wmF42mPR/B3U3sk5P9gCaBiMM
         ikldBi7nR4z5zkd/9GyZKu7b4tFC3RgIhfh3s=
Message-ID: <4DC808EC.2080906@gmail.com>
Date: Mon, 09 May 2011 08:31:56 -0700
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 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>
In-Reply-To: <20110509112758.GA16459@dusk.harfang.homelinux.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

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