#9530: min / max do not always return the other argument when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: | Blocked By: 9276 Blocking: | Related Tickets: 9276 Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): Thanks. I'll have a more detailed look. I can't, however, see any good reason for having min / max asymmetrical in their arguments, whether the result is to be NaN or the other argument. The standard seems to agree. It says (at 5.3.1) that '''''minNum(x, y) is''' the canonicalized number x if x<y, y if y<x, '''the canonicalized number if one operand is a number and the other a quiet NaN.''' Otherwise it is either x or y, canonicalized (this means results might differ among implementations). When either x or y is a signalingNaN, then the result is according to 6.2. 6.2: ''... For an operation with quiet NaN inputs, other than maximum and minimum operations, if a floating-point result is to be delivered the result shall be a quiet NaN which should be one of the input NaNs. ...'' (I am ignoring signalling NaNs here as they don't seem to be relevant to Haskell.) As things stand, Haskell sometimes returns NaN and sometimes the other argument, depending on the order in which the arguments are presented. I can't see how this can be right, What am I missing? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9530#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler