#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