#9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: IEEE754 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Incorrect | than a day) result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): There is clearly no answer that is right for all uses: either the QNaN poisons the result (which is what you might expect, as it does so in all other arithmetic operations) or it doesn't (as in the IEE754r version). What seems to me to be clearly wrong is for the answer to depend on the order in which the arguments are presented. The underlying problem is that we are assuming that floating point numbers are orderable but they aren't when NaNs are included, so a definition of min / max in terms of the order relation is invalid. I think that the only answer is to have two separate min / max specialisations for floating point numbers and let the user decide which they need for their application. Whether one of these is the default or they are two newly named functions is a pragmatic decision that depends on how much existing code would be broken, although I cannot imagine that there would be much code that relied on the order of the arguments. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9534#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler