[GHC] #4413: (^^) is not correct for Double and Float

[GHC]

#4413: (^^) is not correct for Double and Float
-------------------------------------+-------------------------------------
        Reporter:                    |            Owner:  tcsavage
  daniel.is.fischer                  |           Status:  new
            Type:  bug               |        Milestone:  7.6.2
        Priority:  low               |          Version:  7.1
       Component:  libraries/base    |         Keywords:  Double, Float,
      Resolution:                    |  exponentiation
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  Incorrect result  |       Difficulty:  Unknown
  at runtime                         |       Blocked By:
       Test Case:                    |  Related Tickets:
        Blocking:                    |
-------------------------------------+-------------------------------------
Changes (by ekmett):

 * cc: ekmett@…, hvr (added)
 * difficulty:   => Unknown


Comment:

 When I first saw this, I was in favor of it, but then I chewed on it some
 more.

 The issue is unfortunately more subtle.

 While Daniel's proposal is sound for 2 and 0.5 which have exact
 representations in IEEE 754 floating point for both the original number
 and the reciprocal, this proposal yields worse numeric precision for any
 floating point number where the inverse isn't exactly representable.

 Consider 3.

 {{{
 >>> recip 3^600
 5.336385165377033e-287
 >>> recip (3^600)
 5.336385165377108e-287
 }}}

 Now, lets compare these to answers that are more accurate, using my
 `rounded` library:

 {{{
 >>> :m + Numeric.Rounded
 >>> :set -XDataKinds
 >>> recip (3^600) :: Rounded TowardZero 512
 5.3363851653771076591089513443334745430695010187597757569958309540684063019552892464056775485633511783044398629355030763271677070438623409480523609685251156e-287
 >>> recip 3^600 :: Rounded TowardZero 512
 5.3363851653771076591089513443334745430695010187597757569958309540684063019552892464056775485633511783044398629355030763271677070438623409480523609685247316e-287
 }}}

 The inexact version caused us 3 decimal places worth of accuracy. Those 10
 bits of lost significand dwarf the error in the subnormal case.

 If we're stuck choosing, the existing implementation shoots an arrow that
 consistently winds up closer to the mark except in cases of underflow.

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