commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] Consistent use of ExceptionContext [was "using the ExceptionContext facility"]
Date Mon, 29 Aug 2011 16:17:39 GMT
On 8/28/11 11:56 PM, S├ębastien Brisard wrote:
> Hello everyone,
> Looking at the present hierarchy of exceptions, I've had some further
> thoughts, actually supporting the use of context rather than property
> getters. Sticking with the same example, we have two exceptions
> - NonPositiveDefiniteMatrixException: already implemented
> - NonPositiveDefiniteLinearOperatorException: work in progress.
> These two exceptions refer to the same mathematical concept, and the
> former should probably extend the latter (just like AbstractRealMatrix
> extends RealLinearOperator). However, these two exceptions are thrown
> under quite different circumstances, with widely different parameters:
> - If I understood correctly, NonPositiveDefiniteMatrixException is
> thrown for example when a non-positive diagonal element is met,
> - NonPositiveDefiniteLinearOperator is to be thrown when a *vector* x
> is met, such as x'.a.x <= 0 (the entries of the operator as a matrix
> are not accessible).
> As you can see, the parameters of these exceptions will be different.
> We could have a getOffendingOperator() method, but probably not a
> getOffendingVector() method (since NonPositiveDefiniteMatrixException
> has no offending vector in its state).
>
> Does that make sense?

I see your point.  Despite my conservative instincts [1], I think it
may actually be best to make both the current properties of the
matrix version and the new properties of operator version optional
members of the exception context.  There is nothing guaranteeing
that the matrix version will always have a single diagonal element
"witness."  Current activations (which use this for strict, semi and
normal positive-definiteness) always have a diagonal element and
threshold defined, but there may be other activations where a norm
or other test may be used to signal positive definiteness failure. 
I now think that the row, column and threshold property of
NonPositiveDefiniteException should be moved to the exception
context and the row and col should be collapsed into one (since it
is always a diagonal element that witnesses the failure and what is
reported is always the same).  Regarding the operator version, we
have two choices: keep the hierarchy corresponding to the math
concept, or put the witness in the exception context.  My first
reaction was to drop the hierarchy (with justification that the
numerical failures were different), but that only makes sense if
there will *always* be a witness in the operator case.  I am not
sure about that, so I would say err on the side of flexibility and
move the witness to the context.

[1] I am probably too conservative on this because of bad
experiences that I have had in the past with "data bags" of object
properties used to avoid having to actually design things.  While we
are in no danger of doing this, imagine the wonderful idea that we
stop talking about exceptions altogether and via the miracle of the
exception context, we just have one exception.  We define a NAME key
and shove everything else into key/value pairs.  That is a
caricature and I don't really mean it seriously, but you get the
point. 

Phil


>
> Best regards,
> S├ębastien
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message