commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject [math] NaN vs. Exception Revisited (was: Re: [math] proposed ordering for task list, scope of initial release)
Date Wed, 11 Jun 2003 12:46:11 GMT


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


Mime
View raw message