On Fri, Sep 9, 2011 at 1:54 PM, Gilles Sadowski <
gil...@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.
