commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: [Math] "NonPositiveDefiniteMatrixException" message and meaning
Date Fri, 09 Sep 2011 23:14:33 GMT
On Fri, Sep 9, 2011 at 1:54 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:

> > > The exceptions thrown should not be sub-classes of
> NumberIsTooSmallException
> > > because it is a matrix that is the problem and matrices are not numbers
> and
> > > do not have a total order.
>
> Of course, but as you've pointed out that it is difficult to relate the
> failure (which *is* an inequality test) to the input matrix, I thought that
> it was consistent to report the failure as precisely as possible.
>

Well, it was precision at the cost of all intelligibility.


> > I agree.  I don't think a single message is going to work.
>
> Well, it can, by giving less details. IIUC this is what you propose below,
> by removing member fields.
>

Plausible.


> > Ted's
> > analysis is correct - what we are dealing with here is a property of
> > the whole matrix and certainly not a "too small number."
>
> I agree of course.
> I just don't see clearly yet how to report a detailed message.
> We should not forget that the threshold is also a user input, so it could
> be
> construed that this part of the failure story ("a too small number did not
> pass the test") should be reported back. The issue is how to integrate it
> to
> the "top-level" precondition failure.
>

How about these conditions:

- factorization succeeds.  No exception thrown.

- rank deficient, positive semi-definite result.
 Throws NonPositiveDefiniteMatrixException to the consternation of the
pedantic user.  Message says "Input matrix was rank deficient to a tolerance
of {threshold}".  Some versions of Cholesky decomposition may elect to
return a result in this case instead of throwing.

- non positive semi-definite result.
 Throws NonPositiveDefiniteMatrixException.  User is satisfied because this
really does describe the situation.  Message says "Input is not positive
semi-definite".  No reference to the threshold is really necessary here.


> > How we
> > determine that the property fails may be different for different
> > decomposition methods
>
> Currently, only "CholeskyDecompositionImpl" and
> "RectangularCholeskyDecompositionImpl" trigger this exception. So it should
> be possible to figure out how to customize the message at those two places.
>

I think that what I described above works for both.


> > or other use cases (like how it works as an
> > operator, see discussion here [1]).
>
> So, do you agree to add messages to the "ExceptionContext" at the point
> where the exception is raised? As I understand it, this would mean a quite
> simple "NonPositiveDefiniteMatrixException" (no fields; just a simple
> message with no placeholder), and use "addMessage" at the point of usage
> with a report about the failed test (namely how the threshold is used).
>

As a user, I don't think I would care about more details until I decide that
the implementation is broken.  At that point, I will be looking at the
source anyway.

>
> > ... I also think we should be more precise in the
> > exception itself whether it is strict or semi, probably by defining
> > a different exception for positive semi-definite failure.  IIRC, we
> > now use the same exception for both kinds of failure.
>

This is the pedantic user issue.  It really doesn't matter if the
nomenclature here  is *exactly* correct as long as the user understands
instantly what the problem is.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message