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

[GHC]

#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 carter):

 @jrp, in this case the IEEE standard doesn't make sense to comply with, if
 you read that julia lang ticket about the min/max behavior, theres an
 inline email by one of the IEEE spec authors about the motivation for the
 nan evading behavior.

 though I do agree from a strict IEEE compliant behavior standpoint, it is
 nonconforming, this is a very clear example (perhaps the ONLY example)
 where min/max are better off being implemented in a different way. Haskell
 has no need for using Nan to pun representing missing data. (see that
 julia lang thread for a longer discussion on the matter)

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9530#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler