Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test failure when compiled with -O0 #26

Open
nh2 opened this issue May 19, 2019 · 2 comments
Open

Test failure when compiled with -O0 #26

nh2 opened this issue May 19, 2019 · 2 comments

Comments

@nh2
Copy link
Member

nh2 commented May 19, 2019

If I compile with -O0, I get the following test failure:

*** Failed! Falsifiable (after 1 test):
0.0
0.0
(used seed -8074436915145524066)
  t_shortest: [Failed]
*** Failed! Falsifiable (after 1 test):
0.0
0.0
(used seed 5824167789149766384)
Regressions:
  toShortest_overflow: [OK]

         Properties  Test Cases  Total      
 Passed  0           1           1          
 Failed  2           0           2          
 Total   2           1           3          

The test code in question is https://github.com/bos/double-conversion/blob/e4b7956d51fbb79ada95412519bd2a6a680def23/tests/Properties.hs#L9-L13

where a = 0.0, b = 0.0.

The problem seems to be the use of realToFrac (0.0 / 0.0). Note that 0.0/0.0 is NaN.

  • With -O, realToFrac NaN returns NaN
  • With -O0, realToFrac NaN returns -Infinity

You would expect realToFrac :: Double -> Double to always be id, but apparently that is not the case in GHC right now. It is so only if compile with optimisations.

@nh2
Copy link
Member Author

nh2 commented May 19, 2019

This is due to what's explained on:

As mentioned in the latter issue by Simon Marlow 9 years ago:

`realToFrac cannot convert accurately between floating-point types

I think this means that the code in https://github.com/bos/double-conversion/blob/e4b7956d51fbb79ada95412519bd2a6a680def23/Data/Double/Conversion/ByteString.hs#L68-L72 is wrong, as it uses realToFrac to convert between floating point types (Double -> CDouble).

Of course it's somewhat unreasonable to blame double-conversion for this. The fact that Haskell does not provide a function to reasonably convert Double -> CDouble is insane (I posted here).

@Kleidukos
Copy link
Member

Can still reproduce with GHC 9.6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants