[erlang-questions] : Bug? Pretty-printing floating point values
Thu Nov 22 09:05:52 CET 2007
I guess float_to_list/1 produces 20 digits because previously the
external term format for floats was that kind of printout -
20 decimal digits with exponent. Nowdays it is the IEEE format.
And I guess it was chosen so you kind of could guarantee to be able to
recreated exactly the right number after a roundtrip to external format.
Therefore significantly more than 16 digits was needed.
I do not know if 20 digits can be proved to be always enough, though...
On Wed, Nov 21, 2007 at 05:59:19PM +0100, Per Hedeland wrote:
> "Christian S" <chsu79@REDACTED> wrote:
> >Doesn't look like the number of significant digits when read are stored.
> Undoubtedly true, but not necessarily relevant.
> >I wouldn't call it a bug. It is how floating point numbers work.
> >They're very exact with fractions that are a sum of limited numbers of
> >negative powers of two though.
> A reasonable question could be why float_to_list/1 generates 20 digits
> when a 64-bit float (a.k.a. C double), which is what is used internally,
> only can hold 15-16 worth of them - I don't know off-hand what a 128-bit
> float would have, but presumably significantly more than 20, so it's not
> that either. I guess way back in the dark ages, someone thought that 20
> was a nice and even number (I hope it wasn't me:-). The 6.30000 form is
> of course just the ~p/~w formatting.
> --Per Hedeland
> Eshell V5.5.5 (abort with ^G)
> 1> F=6.30000000000000000000000000000.
> 2> float_to_list(F).
> 3> io:format("~p~n",[F]).
> 4> io:format("~.16g~n",[F]).
> 5> io:format("~.17g~n",[F]).
> erlang-questions mailing list
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
More information about the erlang-questions