[GHC] #8285: unexpected behavior with encodeFloat on large inputs

#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

#8285: unexpected behavior with encodeFloat on large inputs ------------------------------------------------+-------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by carter): This seems like its worth fixing, if theres a reasonable solution. My understanding is the the current code just punts on handling these corner cases properly -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8285#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8285: unexpected behavior with encodeFloat on large inputs ------------------------------------------------+-------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by hvr): Fwiw, `encodeFloat 1 (2^31)` behaves just like the C99 function [http://pubs.opengroup.org/onlinepubs/7999959899/functions/ldexp.html ldexp(3)] does for those arguments. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8285#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8285: unexpected behavior with encodeFloat on large inputs -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:2 hvr]:
PS: Now I see the problem
What is exactly the problem? That the second argument to `encodeFloat` is treated as a 32 bit integer? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8285#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8285: unexpected behavior with encodeFloat on large inputs -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -1,1 +1,3 @@ - benjamin scarlet discovered some unexpected behavior in encodeFloat today + {{{ + > encodeFloat 1 1023 + 8.98846567431158e307 -- ok @@ -3,3 +5,2 @@ - {{{ - <bscarlet> > map (\x -> encodeFloat 1 (shiftL 1 x)) [30,31] - [23:47:47] <lambdabot> [Infinity,0.0] + > encodeFloat 1 1024 + Infinity -- ok @@ -7,2 +8,2 @@ - [23:49:09] <arkeet> > encodeFloat 1 60 - [23:49:10] <lambdabot> 1.152921504606847e18 + > encodeFloat 1 (2^31 - 1) + Infinity -- ok @@ -10,16 +11,2 @@ - [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 - + > encodeFloat 1 (2^31) + 0.0 -- not ok @@ -27,6 +14,0 @@ - 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 New description: {{{
encodeFloat 1 1023 8.98846567431158e307 -- ok
encodeFloat 1 1024 Infinity -- ok
encodeFloat 1 (2^31 - 1) Infinity -- ok
encodeFloat 1 (2^31) 0.0 -- not ok }}}
--
Comment (by thomie):
I think this just needs an update to the `encodeFloat` docstring.
To confirms what hvr said in comment:2:
test.c:
{{{
#include
participants (1)
-
GHC