thanks for reporting that you found these behaviors confusing, because
(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
#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]: they are! 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