On Fri, Sep 09, 2011 at 11:26:02AM -0700, Phil Steitz wrote:
> On 9/9/11 9:27 AM, Ted Dunning wrote:
> > I don't think that is correct.
> >
> > It is not the case that there was some element in the input that was too
> > small. For instance, this matrix is positive definite:
> >
> > 3 -3 1
> > 2 4 2
> > 1 1 30
> >
> > While this one is not
> >
> > 3 -3 1
> > 2 3 2
> > 1 1 30
> >
> > The value of the diagonal that triggers the error message will be some
> > negative number that does not appear in the original matrix.
> >
> > For a non-pivoting Cholesky, I think that the message should be more like
> > "Input was not positive definite".
> >
> > For a pivoting rank-revealing Cholesky, I think that the result should by
> > "Input was not semi-positive definite" or "Input was positive semi-definite
> > but had rank {}" depending on the three way test.
> >
> > 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.
> 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.
> 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 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.
This might be again a situation where the "ExceptionContext" can be used
(i.e. add a customized message that reports what test fails).
> 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).
> I think the best thing to do is
> to drop the member fields from the exception (because their meaning
> is ambiguous, as more or less agreed in [1]) and allow the different
> activations of the exception to customize the message (as in Ted's
> second example above) or to include no message (appropriate in Ted's
> first example). 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.
Could you please review the usage of "NonPositiveDefiniteMatrixException"
in the two classes indicated above, and let me know what messages are
required (in each of three cases)?
Thanks,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
