[
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.
