[GHC] #9530: min / max do not always return the other argument when one of the arguments is NaN

GHC ghc-devs at haskell.org
Sun Aug 31 23:46:28 UTC 2014


#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


More information about the ghc-tickets mailing list