commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LANG-381) NumberUtils.min(floatArray) returns wrong value if floatArray[0] happens to be Float.NaN
Date Thu, 06 Dec 2007 07:33:43 GMT

    [ https://issues.apache.org/jira/browse/LANG-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548950
] 

Henri Yandell commented on LANG-381:
------------------------------------

So, from http://en.wikipedia.org/wiki/IEEE_754r we get:

*********************
min and max

The min and max operations are defined but leave some leeway for the case where the inputs
are equal in value but differ in representation. In particular:

    * min(+0,-0) or min(-0,+0) must produce something with a value of zero but may always
return the first argument.

In order to support operations such as windowing in which a NaN input should be quietly replaced
with one of the end points, min and max are defined to select a number, x, in preference to
a quiet NaN:

    * min(x,NaN) = min(NaN,x) = x
    * max(x,NaN) = max(NaN,x) = x

In the current draft, these functions are called minnum and maxnum to indicate their preference
for a number over a NaN.
*********************

Regardless of the various options, we need to make sure our pairs of min functions are equivalent;
the (double, double, double) and the (double[]) variants.

Our options for 'correct' seem to be:

1) JDK functionality; current IEEE. NaN is always the answer to min and max if an argument.
2) IEEE-754r. NaN is only the answer to min and max functions if there is no non NaN element.
3) Keep JDK functionality as is and add minnum/maxnum variants for IEEE-754r.

I'm surprised by the IEEE-754r change, it feels to me that I would prefer to have a clear
sign that something went wrong and not have the other number be the minimum and no awareness
of the problem having happened. I'm tending towards 1) or 3).

> NumberUtils.min(floatArray) returns wrong value if floatArray[0] happens to be Float.NaN
> ----------------------------------------------------------------------------------------
>
>                 Key: LANG-381
>                 URL: https://issues.apache.org/jira/browse/LANG-381
>             Project: Commons Lang
>          Issue Type: Bug
>    Affects Versions: 2.3
>            Reporter: Thomas Vandahl
>             Fix For: 2.4
>
>
> The min() method of NumberUtils returns the wrong result if  the first value of the array
happens to be Float.NaN. The following code snippet shows the behaviour:
>         float a[] = new float[] {(float) 1.2, Float.NaN, (float) 3.7, (float) 27.0, (float)
42.0, Float.NaN};
>         float b[] = new float[] {Float.NaN, (float) 1.2, Float.NaN, (float) 3.7, (float)
27.0, (float) 42.0, Float.NaN};
>         
>         float min = NumberUtils.min(a);
>         System.out.println("min(a): " + min); // output: 1.2
>         min = NumberUtils.min(b);
>         System.out.println("min(b): " + min); // output: NaN
> This problem may exist for double-arrays as well. 
> Proposal: Use Float.compare(float, float) or NumberUtils.compare(float, float) to achieve
a consistent result.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message