[GHC] #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB
#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 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: -------------------------------------+------------------------------------- The attached is an implementation of the floating point accuracy test described in ''The Baleful Influence of Benchmarks'' section of http://www.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF {{{ Results for Float: r = 4098.0 produces 12.0 and 12.0 sig. bits r = 4098.25 fails: root 0.99989897 isn't at least 1 <<<< r = 4097.004 produces 12.0 and 11.999298 sig. bits : Worst accuracy is 11.999298 sig. bits : Results for Double: r = 4098.0 produces Infinity and Infinity sig. bits r = 4098.25 produces Infinity and 53.0 sig. bits r = 4097.00390625 produces Infinity and 53.451178091541244 sig. bits r = 1.6777218e7 produces Infinity and Infinity sig. bits r = 1.677721825e7 produces Infinity and 75.0 sig. bits r = 1.6777219e7 produces Infinity and 71.0 sig. bits r = 9.4906267e7 produces 26.499999994288153 and 26.499999986733027 sig. bits r = 9.490626725e7 fails: root 0.999999995635551 isn't at least 1 <<< r = 2.684354505e8 produces 28.0 and 27.999999919383132 sig. bits r = 2.684354515e8 produces 28.0 and 27.99999993013205 sig. bits r = 2.68435458e8 produces 28.0 and 28.0 sig. bits r = 2.6843545825e8 produces 28.0 and 28.00000000268723 sig. bits r = 2.6843545700000006e8 produces 28.0 and 27.999999989251084 sig. bits r = 4.294967298e9 produces 32.0 and 32.0 sig. bits r = 4.29496729825e9 produces 32.0 and 32.00000000016795 sig. bits Worst accuracy is 26.499999986733027 sig. bits }}} This seems to be comparable to a clang version, but seems to be fairly poor in comparison to some other machines, back in the day (1997). '''The attached could, possibly be turned into a testsuite test, by removing the QuickCheck tests that are included.''' Observations: * There are a couple of failures (could be the implementation of sqrt or log). * signum seems incorrect (signum Nan = -1.0) * The prelude should have a copysign function * min fails to produce the other argument if one argument is NaN * The CFloat and CDouble variants seem to produce the same result as the native Float and Double versions * The Haskell coding style could be improved to remove some boilerplate, make the code more idiomatic * There may be a better way of entering the test values of r to ensure that they are accurate -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9534 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 carter): thanks! This is pretty great, I think some of the issues have been resolved in GHC head (wrt signum being wrong), but I'll take a look at trying to understand the rest. What GHC version and OS and flags did you use to run the program? (so i can try to reproduce this later?) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9534#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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): I ran this with 7.8.3, on OS X, no flags. (Well I tried with -fllvm too, but it gave identical results, presumably because much of this is just picking up a C library.) PS: I'm glad to see that Prof Kahn is still going strong with floating point arithmetic, the sender of the email to which you referred me. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9534#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 carter): still haven't worked through this fully, BUT min/max for float/double in ghc haskell are certainly defined differently from the the 2008 IEEE floating point standard (nb: the definition of min/max in the ieee standard was only added to the 2008 version and merely codified certain unusual idioms/patterns from the C language useage of min/max on Nans). In contrast, GHC Haskell's compare is defined wrt a quiet (not signalling) comparison on input arguments (which mean that when min max have a nan in either arg, we just take the second arg currently.). Of course, this is a bit unsatisfactory if only because it makes min/max not commutative operations in the presence of NaN. (though in some respects I view the current IEEE definition that just codifies the C version as more problematical still!) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9534#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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
#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 carter): 1. IEEE 2008 defines a total order 2. yes we can provide different min/max for floating things, BUT those arent the min/max that come with Ord, its trivial to define a floating only version min or max that has the alternative behaviors, whats less trivial is fixing the specified semantics of the haskell side. I've spoken with the various folks who would actually need to vote on a proposal via the libraries list, and because theres no canonicity of any of the choices, there'll be enough disagreement that the status quo will stay as is. I'd love to get the nan poisoning variant to be the new default, but we'd need a good canonicity story for making that so. if we just did minPoison and minMissing, no one will use them (who wouldn't be rolling their own anyways), and we'd have to newtype float/double to give alt min/max ord definitions. its a mess, and we need a clear canonicity argument to change up the behavior though. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9534#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 carter): I think the simplest answer would be to change how we define compare to use the IEEE total order it'd still be *weird* on NANs, but it'd be commutative again. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9534#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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): I, for one, would be happy with that solution. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9534#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC