#9530: min / max do not always return a NaN when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: invalid | 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): I don't have a copy of the standard, but http://en.wikipedia.org/wiki/IEEE_754_revision says {{{ min(x,NaN) = min(NaN,x) = x max(x,NaN) = max(NaN,x) = x }}} which is not satisfied here {{{ Prelude> max 3 nan 3.0 Prelude> max nan 3 NaN }}} http://msdn.microsoft.com/en- gb/library/windows/desktop/jj218760(v=vs.85).aspx agrees: {{{ The IEEE-754R specification for floating point min and max operations states that if one of the inputs to min or max is a quiet QNaN value, the result of the operation is the other parameter. }}} It goes on to add a further wrinkle: {{{ A revision of the IEEE-754R specification adopted a different behavior for min and max when one input is a "signaling" SNaN value versus a QNaN value: }}} So far as I can tell, Haskell does not know anything about signalling NaNs, so this is probably not applicable. I'll change the title of the ticket to make the issue clear. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9530#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler