|Anonymous | Login | Signup for a new account||2014-07-29 16:54 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004696||OCaml||OCaml general||public||2009-01-16 18:49||2012-10-14 09:58|
|Target Version||Fixed in Version|
|Summary||0004696: min & max yield incorrect results with NaN|
|Description||# min nan 1.;;|
- : float = 1.
# min 1. nan;;
- : float = nan
# max nan 1.;;
- : float = 1.
# max 1. nan;;
All results should be NaN.
(Or at least docs should specify what is the intended behavior.)
|Tags||No tags attached.|
AFAIK IEEE 754-1985 doesn't specify a behaviour for min/max functions.
The recent IEEE 754-2008  introduces minNum and maxNum (see 5.3.1). However when presented with a number and a quiet NaN these functions unconditionnaly return the number. So that would be the opposite of what the reporter proposes.
 http://ieeexplore.ieee.org/servlet/opac?punumber=4610933 [^]
The documentation of Pervasives says simply:
"any operation with nan as argument returns nan as result"
I thought there is a bug in max & min, because their result depends on order of arguments. For me it is natural to assume that (max a b)=(max b a) if the documentation doesn't say otherwise.
However I understand that it is more important to have fast max & min operations than to handle NaNs in a specific way. So I reported this too hastily as a bug, this might be better seen as "documentation request".
You expected min x NaN = NaN, but as D. Buenzli mentioned, other folks recommend min x NaN = x. In Caml, there is one additional difficulty, namely that min and max apply to composite data structures as well. So, what should be
min (x, NaN) (NaN, y), for example? I don't think a "best" behavior exists in this case, so the current implementation is as good (and as bad) as any other.
|2009-01-16 18:49||toton||New Issue|
|2009-01-29 15:05||dbuenzli||Note Added: 0004826|
|2009-01-30 15:12||dawidtoton||Note Added: 0004827|
|2009-03-28 18:12||xleroy||Note Added: 0004883|
|2009-03-28 18:12||xleroy||Status||new => closed|
|2009-03-28 18:12||xleroy||Resolution||open => not fixable|
|2012-10-14 09:58||xleroy||Relationship added||related to 0005781|
|Copyright © 2000 - 2011 MantisBT Group|