commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [math] Ok Neo, this should really bake your noodle... (ork-Statistics)
Date Thu, 22 May 2003 16:17:51 GMT

On Thursday, May 22, 2003, at 06:01 AM, Phil Steitz wrote:

> O'brien, Tim wrote:
>> On Wed, 2003-05-21 at 20:25, Mark R. Diggory wrote:
>>> Phil Steitz wrote:
>>>> One thing that is starting to cause me some pain is this
>>>> whole issue of what to return (or throw) when a statistic
>>>> is meaningless.  My inclination is to throw something
>>>> rather than just returning Double.NAN or 0, but I am
>>>> ambivalent. I just think that we need to settle on some
>>>> policies and be consistent. I am interested in what others
>>>> think about this.
>>> My sentimate is to look to the behavior of the Math/StrictMath classes.
>>>  These classes return NaN's when a function is meaningless.
>> one is a practical concern and one is personal taste, and another one is
>> influenced by the existing JDK.
>> 1. I'm not interested in libraries that demand a try/catch for
>> operations such as finding the mean of a set of values.  I trust the
>> developer enough to document and adhere to a contract which can return
>> Double.NaN instead of using the exception mechanism to signal the
>> absence of an answer. 2. What is the mean of an empty set?  I think that 
>> question has a clear
>> answer - the mean of an empty set is not a number.  It isn't zero, and
>> it isn't EmptySetException.  We should throw exceptions for exceptional
>> conditions such as trying to read an element from array index -23, or
>> attempting to put a square peg into a round hole.
>> 3. the JDK Math and StrictMath all make liberal use of NaN when an
>> answer is meaningless, indefinite, unanswerable, etc.  IEEE 754 contains
>> +/- INFINITY and NaN for the exact situations we are encountering. 
>> Trying to find the square root of a -4, or trying to find the maximum
>> number contained in an empty array.
> OK.  You guys have convinced me.  We just need to carefully document "Nan 
> semantics" in interface specifications.  thx

i do agree with tim on this - but i'd like to add a general observation.

error handling when dealing with boundary conditions in particular can 
raise long term code maintenance issues. it can be difficult to work out 
what boundary condition violations are associated with the interface and 
which with the particular implementation. it's easy to add boundary 
conditions into the interface contract which are really part of the 
particular implementation. an unforeseen class of implementations might 
have very different characteristics when it comes to which values are 
valid. it can be difficult or impossible to accommodate these 
implementations if the interface's boundary conditions are specified too 

IMHO a more robust approach is:

1. to give only general strategies in the interface. so for example, the 
interface might specify that a Double.NaN (or a IllegalArgumentException 
or whatever) would be returned (or thrown, whatever) when the implementing 
algorithm's boundary conditions were not forfilled rather than specifying 
the actually boundary conditions.

2. if exceptions are thrown, prefer a small number of general exceptions 
with general statements of policy. implementations should usually throw 
more specific subclasses and specify the subclasses they actually throw 
and the exact circumstances in which they throw them. this will allow 
unforeseen classes of implementation to be accommodated without having to 
break the original exception handling contracts.

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message