#9564: Floating point subnormals overrounded on output -------------------------------------+------------------------------------- Reporter: jrp | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): These extra digits past the decimal point suggest a degree of precision that doesn't exist in a Float: for instance 1.4013e-45 is the same Float as 1.4014e-45. In fact all the numbers 1.0e-45 through 2.0e-45 (and a bit farther in each direction) round to the same Float, so why not output the simplest one, 1.0e-45? This is the same logic by which we display the Float 1/10 as 0.1 and not, say, 0.10000000149 even though the latter is closer to the true value. printf's %g is not a format you can round-trip through: by default it always prints 6 digits (in this case the last digit would be 0 and is dropped). So it's not a good analogue of `show`. (Also, %g is printing a double, not a float, but it has the same behavior with 2^-1074^, the smallest positive double.) Python has similar behavior to GHC: it doesn't have single-precision floating point AFAIK, but for doubles, it displays 2^-1074^ as 5e-324, just like GHC displays 5.0e-324. Arguably we could drop the ".0" part, but I don't think that's worth changing. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9564#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler