[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):

 read what I was saying earlier, we agree the current situation is not
 satisfactory (and I am working on a proposal to make it better).

 Interesting,  the first version of the IEEE standard (the 1985 standard)
 doesn't seem to mention anything about min/max
 http://www.wellposed.com/standards-documents-cache/IEEE754-1985.pdf

 point being, the challenge is to choose a definition that "works the most"
 subject to floating point being what it is.  And the current on e in ghc
 BASE is certainly confusing and odd, but that a direct consequence of
 Float/Double min/max using their ORD instance definition of compare to
 induce the min/max operations.

 Thus, we need to balance a few tricky concerns (and definitional
 consistency!) when changin min/max, because if nothing else, the current
 behavior is exactly that induced by the defintion of compare on floating
 point.

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