Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004696OCaml~DO NOT USE (was: OCaml general)public2009-01-16 18:492012-10-14 09:58
Assigned To 
StatusclosedResolutionnot fixable 
PlatformOSOS Version
Product Version3.10.0 
Target VersionFixed in Version 
Summary0004696: 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.)
TagsNo tags attached.
Attached Files

- Relationships
related to 0005781resolved min and max do not conform to IEEE 754 recommendations 

-  Notes
dbuenzli (reporter)
2009-01-29 15:05

AFAIK IEEE 754-1985 doesn't specify a behaviour for min/max functions.

The recent IEEE 754-2008 [1] 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.



[1] [^]
dawidtoton (reporter)
2009-01-30 15:12

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".
xleroy (administrator)
2009-03-28 18:12

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.

- Issue History
Date Modified Username Field Change
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
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-03-03 17:55 doligez Category -OCaml general => -(deprecated) general
2017-03-03 18:01 doligez Category -(deprecated) general => ~deprecated (was: OCaml general)
2017-03-06 17:04 doligez Category ~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker