On 9/9/11 1:54 PM, Gilles Sadowski wrote:
> 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.
The user input (or default) is algorithm-dependent. I am not sure
we need to echo that back in the exception. The fact that an
exception is thrown indicates that in the context of the algorithm,
a failure of positive definiteness (or semi-definiteness) was
encountered. See comments to follow on what should be reported back
or put into the exception context.
>> 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).
Good place to start. I thought I had seen other direct invocations,
but I guess they have now been removed.
>
>> 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 am not sure it is necessary to add anything to the exception
context in these cases because I don't know honestly what a caller
is going to do with the information. Basically, I agree with Ted's
comments on this - characterize the failure in language appropriate
to the algorithm at a level that makes sense in the context of the
caller.
>> 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)?
I think Ted's suggestions are reasonable.
Ted - a patch illustrating this - even with just literal messages
for both Cholesky and RectangularCholesky - would be greatly
appreciated.
I also now agree with Ted that my previous suggestion that we split
semi- from strict as a separate exception is not necessary, as long
as we clearly specify in the javadoc (as the methods that trigger
this in linear and random now do) whether strict or semi positive
definiteness is the precondition. An argument could be made that a
boolean for strict/semi would make more sense as an attribute of the
exception than either of the currently defined fields, which I think
should be dropped.
Phil
>
>
> Thanks,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
