#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