[math] NaN vs. Exception Revisited (was: Re: [math] proposed ordering for task list, scope of initial release)

["Mark R. Diggory" <md...@latte.harvard.edu>]

Brent Worden wrote:
>>-----Original Message-----
>>From: Phil Steitz [mailto:phil@steitz.com]
>>
>>>>There are several approaches to design a concept for exceptions,
>>>>all of which have pros and cons. I personally would suggest to
>>>>avoid returning NaNs and throwing RuntimeExceptions whereever
>>>>possible and use a package specific hierarchy of declared exceptions
>>>>instead.
>>>>
>>>>J.Pietschmann
>>>
>>>
>>>I would agree whole-heartedly.
>>>
>>
>>That's where I started, but then Tim and others convinced me that it was
>>actually better/more convenient for users for us to behave more like
>>java.Math and java's own arithmetic functions -- which use NaN all over
>>the place.
> 
> 
> Here's a saying I've used in the past when debating colleagues: "Just
> because someone else does something, that doesn't make it right." :)
> 
> Also, from a usage standpoint, if we use checked exceptions
> 
>>everywhere, this is a bit inconvenient for users.  We need to find the
>>right balance.
>>
>>I am one the fence on this whole issue.  I am interested in hearing more
>>about what others may have in mind.
> 
> 
> The big problem I have with returning NaN is the caller has little knowledge
> why NaN is being returned.  If an exception is thrown, preferably a
> specialized exception like ConvergenceException, the caller knows precisely
> the reason for failure and can take appropriate recovery action.


I think your usage of Convergence Exception is appropriate in your case. 
  In your case your waiting for the method to return, if it fails to 
converge, you need to know why, there may be different reasons, and its 
an "exceptional case" which probibly terminates the whole process in the 
long run.

But, I also supported the usage of NaN's when the result of a simple 
calculation falls outside the domain of "proper results" for that 
method. This means that log(0.0) would return a NaN, simple descriptive 
stats would return NaN's when the inputs were of the wrong domain.

for example, if geomean() returned a NaN in the following eq. the whole 
eq's return value is NaN.

MathUtils.factorial( Math.floor( Math.log( 
StatUtils.geomean(someobj.getArray()) )))


BUT, even again, Now that we revisit this issue, we may be wrong (and 
your viewpoint correct) in this respect when it comes to ease of use. If 
we have a generic "InvalidInputValueException", then only one exception 
need be caught in the process of evaluating numerious functions in a 
process. If all throw "InvalidInputValueException", its easily 
discernable where the problem arose in the calculation.

try{
	MathUtils.factorial( Math.floor( Math.log( 	
		StatUtils.geomean(someobj.getArray()) )))

}catch(InvalidInputValueException iive){
	iive.printStackTrace(...);
}

Its a question of, is a function returning NaN an exceptional case or is 
it an acceptable case? And, this had/has turned into a very debatable topic.

-Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [math] NaN vs. Exception Revisited

["Mark R. Diggory" <md...@latte.harvard.edu>]

Tim O'Brien wrote:

>>I think your usage of Convergence Exception is appropriate in your case. 
>>In your case your waiting for the method to return, if it fails to 
>>converge, you need to know why, there may be different reasons, and its 
>>an "exceptional case" which probibly terminates the whole process in the 
>>long run.
>>    
>>
>
>+1, a ConvergenceException makes sense.
>
>  
>
>>try{
>>	MathUtils.factorial( Math.floor( Math.log( 	
>>		StatUtils.geomean(someobj.getArray()) )))
>>
>>}catch(InvalidInputValueException iive){
>>	iive.printStackTrace(...);
>>}
>>    
>>
>
>-1, not only is that a very bad idea in terms of usage constraints, it
>tends to buck a well established trend.   Complex "algorithms" should
>through checked exception, something like finding an Average of a set of
>values should return NaN.
>
>  
>
Just testing the conceptual waters, if we still feel as strongly about 
it, very well...



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [math] NaN vs. Exception Revisited (was: Re: [math] proposed ordering for task list, scope of initial release)

[Tim O'Brien <to...@discursive.com>]

> I think your usage of Convergence Exception is appropriate in your case. 
> In your case your waiting for the method to return, if it fails to 
> converge, you need to know why, there may be different reasons, and its 
> an "exceptional case" which probibly terminates the whole process in the 
> long run.

+1, a ConvergenceException makes sense.

> try{
> 	MathUtils.factorial( Math.floor( Math.log( 	
> 		StatUtils.geomean(someobj.getArray()) )))
> 
> }catch(InvalidInputValueException iive){
> 	iive.printStackTrace(...);
> }

-1, not only is that a very bad idea in terms of usage constraints, it
tends to buck a well established trend.   Complex "algorithms" should
through checked exception, something like finding an Average of a set of
values should return NaN.



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org