[GHC] #8285: unexpected behavior with encodeFloat on large inputs
GHC
ghc-devs at haskell.org
Fri Sep 13 07:11:08 CEST 2013
#8285: unexpected behavior with encodeFloat on large inputs
--------------------------+------------------------------------------------
Reporter: carter | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 7.8.1
Component: | Version: 7.7
Compiler | Operating System: Unknown/Multiple
Keywords: | Type of failure: Incorrect result at runtime
Architecture: | Test Case:
Unknown/Multiple | Blocking:
Difficulty: |
Unknown |
Blocked By: |
Related Tickets: |
--------------------------+------------------------------------------------
benjamin scarlet discovered some unexpected behavior in encodeFloat today
{{{
<bscarlet> > map (\x -> encodeFloat 1 (shiftL 1 x)) [30,31]
[23:47:47] <lambdabot> [Infinity,0.0]
[23:49:09] <arkeet> > encodeFloat 1 60
[23:49:10] <lambdabot> 1.152921504606847e18
[23:49:09] <arkeet> > encodeFloat 1 60
[23:49:10] <lambdabot> 1.152921504606847e18
[23:49:18] <arkeet> er.
[23:50:21] <bscarlet> down in the sane range I suspect it's just fine.
[23:50:43] <bscarlet> > encodeFloat 1 1000
[23:50:44] <lambdabot> 1.0715086071862673e301
[23:50:52] <bscarlet> > encodeFloat 1 10000
[23:50:53] <lambdabot> Infinity
[23:50:58] <bscarlet> That's sane.
[23:51:03] <arkeet> > encodeFloat 1 (2^31)
[23:51:04] <lambdabot> 0.0
[23:51:13] <bscarlet> That's what I think is weird.
[23:51:19] <carter> bscarlet floats are weird
[23:51:23] <arkeet> > encodeFloat 1 (2^31-1)
[23:51:24] <lambdabot> Infinity
}}}
Benjamin did a wee bit of investigation, and the
problem seems to lie in https://github.com/ghc/packages-integer-
gmp/blob/master/cbits/float.c#L177
in integer-gmp, where it deliberately doesn't handle the edge cases
(probably worth investigating) if integer-simple has similar behavior or
not
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8285>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list