commons-dev mailing list archives

Mark R. Diggory wrote:
> The real issue in the case of returning NaN vs. an Exception is the
> following question:
>
> Is there "any other case" where the same methods could return a NaN or
> an Exception? And if so, is there any reason you would want to tell the
> user that there is "a difference in state" when you can't return an
> expected value from the method.
>
> Another hypothetical NaN issue arises if the input to the calculation
> contains a NaN. I think in such a case the whole computation would get
> locked in a NaN state.
>
> For example: all the following standard Java methods and operators
> return NaN
>
> System.out.println(6.567 + Double.NaN);
> System.out.println(6.567 / Double.NaN);
> System.out.println(6.567 * Double.NaN);
> System.out.println(6.567 % Double.NaN);
> System.out.println(6.567 - Double.NaN);
>
> System.out.println(Double.NaN + 6.567);
> System.out.println(Double.NaN / 6.567);
> System.out.println(Double.NaN * 6.567);
> System.out.println(Double.NaN % 6.567);
> System.out.println(Double.NaN - 6.567);
>
> System.out.println(Math.pow(Double.NaN,6.567));
> System.out.println(Math.sin(Double.NaN));
> System.out.println(Math.sqrt(Double.NaN));
> System.out.println(Math.ceil(Double.NaN));
>
> If its the case that all these return NaN (especially the last 4), it
> would be wise to do so only because it is consistent with the behavior
> already present in java.
I agree. We should be consistent with the behaviour of the Math methods.
This needs to be documented carefully.
>
> But, in a rolling calculation, once sum and sumsq turn into NaN's, I
> think your stuck with the calculation always returning NaN. So you need
> to deal with and document how the statistic will handle such a case.
Here again, I agree, and I agree we need to document the behavior.
>
> -Mark
>
>
>
> Phil Steitz wrote:
>
>> O'brien, Tim wrote:
>>
>>> On Tue, 2003-05-13 at 23:13, Phil Steitz wrote:
>>> <snip/>
>>>
>>>> On second thought, I agree with you. You are correct that if we
>>>> really want to throw something for "insufficient data" situations,
>>>> we should require n >= 1 for the mean and either force n >= 2 for
>>>> variance, std dev or modify these to return 0 if n < 2. May not be
>>>> worth the trouble.
>>>
>>>
>>>
>>>
>>> I think NaN is a good answer for unanswerable questions like "What is
>>> the mean of an empty set?" or "What is the length of a point?" Nothing
>>> prevents you from asking the question, and throwing an exception just
>>> seems unnecessary.
>>>
>>> Modifying variance and standard deviation to return 0 when n = 1 makes
>>> sense.
>>
>>
>>
>> What about n = 0?
>>
>>>
>>> Tim
>>>
>>>
>>>> Phil
>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org