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

[GHC]

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

 Replying to [comment:2 carter]:
 > thanks for reporting that you found these behaviors  confusing, because
 they are!
 > (though they are totally kosher with respect to the IEEE Floating point
 semantics, as well as the Ord instance for floating point numbers, so
 technically not a bug, but rather a distasteful behavior).
 >
 > thus while it IS an unexpected behavior, its not a bug ( try doing
 `[1.07 :: Float .. 9.9]`in ghci to see something truly bonkers that ),
 >
 > Its worth noting that the ieee standard specifies an even worse behavior
 for min and max, that when only one arg is NAN, return the *other* (not
 NAN) argument! (though the historical motivation is a bit suspect.)
 >
 > In fact, i've been working on writing up a proposal to change the
 semantics of min and max on floating point values!
 > (should happen some time after ICFP is over this week). I spoke with a
 number of the Julia lang folks about this issue (which was raised with
 them after I discussed min/max with a member of their community), and I'll
 likely propose to change the floating point min / max to have the same
 semantics as their change https://github.com/JuliaLang/julia/issues/7866
 >
 > their change is:
 > 1) when either argument of min/max is NAN, return NAN
 > 2) Except:
 >   a) for min, when either argument is -\infinity, return  - \infinity
 >   b) for max, when either argument is +\infinity, return +\infinity
 >
 > that said, i'm letting the design / thinking about the implications bake
 before writing up a proposal that change (though it seems like the most
 reasonable possible definition given the constraints of Float and Double),
 because getting the semantics as right as possible matters, and id like to
 be confident in changing how math works for haskell before committing to
 the change.
 >
 > I do think that this change in definition will get unanimous support,
 but i'm trying to also understand *WHAT* else can be fixed up in the same
 proposal that should be included along with that change.

 I think it probably makes sense to have multiple sets of operations
 available:

 1. IEEE compliant stuff, whether sane or not.

 2. Stuff that's fast in hardware, whether sane or not.

 3. Stuff that's sane.

 Your \pm\infty thing only makes a sort of sense for some NaN situations, I
 believe. I can buy `max (1/0) (0/0) = Infinity`, for example, but it's
 hard for me to make sense of `max (1/0) (sqrt (-1))` being anything but
 NaN.

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