[erlang-questions] pre-EEP: accurate float printing (replacement for io_lib_format:fwrite_g/1)

Bob Ippolito bob@REDACTED
Tue Dec 11 09:43:05 CET 2007


~g with no precision specification (io_lib_format:fwrite_g/1) is a
perfect target and it hits every use the shell has, ~f and ~e I don't
care about. Having yet another float format would be completely stupid
and confusing to anyone that doesn't know the back story for why
supposed backward compatibility required the need for another format.
Other languages have undergone this type of change with no ill effects
that I've heard of (e.g. TCL did this in 2003 [1]).

The only possible compatibility problems I can imagine would be:
1. Tests that expect particular string outputs (generally a bad idea
with floats anyway, and those sorts of tests really should be using
~.17g or float_to_list)
2. Somehow code that expects ~g with no explicit precision to return a
string within some certain number of characters. However, if they
expect a certain number of characters I'd expect that they'd specify
that in the format.

The benefits are huge though, we'll have a human-readable float format
that actually accurately represents the number. I've been burned MANY
times by looking at shell output and seeing several floats that print
the same but are actually quite different.

[1] http://www.tcl.tk/cgi-bin/tct/tip/132.html

On 12/11/07, Raimo Niskanen <raimo+erlang-questions@REDACTED> wrote:
> I suggest you make the EEP for a new io_lib floating point print
> format. The problem here is to find a good letter since ~e, ~f
> and ~g are already used. Perhaps it can be done through some
> unused precision specifier... Changing an existing feature can always
> cause all kinds of unexpected problems. Then suggest that the shell
> should use the new format.
>
> These sound like nice backwards compatible changes that have a
> good chance of being accepted.
>
>
>
> On Mon, Dec 10, 2007 at 01:40:26PM -0800, Bob Ippolito wrote:
> > If we submit a patch to io_lib_format:fwrite_g/1 to use an accurate
> > floating point decimal representation, would it be accepted? If not,
> > is there a less intrusive way that we could override this?
> >
> > I find it VERY annoying to have the shell print "~.5g", since that
> > often doesn't have enough precision to see what I need to see in the
> > floats we work with. I also generally prefer to see "0.1" instead of
> > "0.10000".
> >
> > We have a suitable implementation here, which is the same algorithm
> > that several other programming languages use and there's a paper that
> > proves its correctness:
> > http://mochiweb.googlecode.com/svn/trunk/src/mochinum.erl
> >
> > It could probably be made a little faster if necessary by using a
> > pre-calculated set of results for int_pow that covers the range that
> > the algorithm needs, e.g.:
> >
> > int_pow(10, 0) -> 1;
> > int_pow(10, 1) -> 10;
> > ...
> > int_pow(10, 324) -> ...
> >
> > -bob
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-questions
>
> --
>
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
>



More information about the erlang-questions mailing list