You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem seems to be the use ofrealToFrac (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.
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).
Activity
nh2 commentedon May 19, 2019
This is due to what's explained on:
As mentioned in the latter issue by Simon Marlow 9 years ago:
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
realToFracto convert between floating point types (Double -> CDouble).Of course it's somewhat unreasonable to blame
double-conversionfor this. The fact that Haskell does not provide a function to reasonably convertDouble -> CDoubleis insane (I posted here).Kleidukos commentedon Sep 25, 2023
Can still reproduce with GHC 9.6