[erlang-questions] [patch] new float_to_list/2

Gleb Peregud <>
Fri Jan 14 16:33:46 CET 2011

Here's my patch:


It uses double sprintf invocations. Your solution is clearly better (I
didn't knew it is possible to specify precision in args).

Your benchmark shows that difference is negligible. Between integer as
a second parameter or a proplist (~0.4%). Though it might be a bit
more "stable" in terms of running time, but still probably not worth
considering it for performance reasons. It still may be useful in
terms of simpler API, but I have no strong opinion on it.

So generally +1 on including Serge's patch into Erlang. Serge, can you
put it into GitHub pull request? As described here:



On Wed, Jan 12, 2011 at 18:13, Serge Aleynikov <> wrote:
> I did a micro-benchmark on a slightly modified version of the BIF that
> accepts an integer as its options.  The results shown below display a very
> insignificant difference between a call with no options and a call with an
> integer precision passed as the second argument:
> 1> test:test().
> float_to_list(123.4, [])               = {0.619512,"123.4000"}
> float_to_list(123.4, [{precision, 4}]) = {0.624895,"123.4000"}
> float_to_list(123.4, 4)                = {0.622896,"123.4000"}
> The majority of time is actually spent in the printf(3) function, which
> takes longer to execute when given the "%.*f" argument compared to "%g" as
> in float_to_list/1 case.
> Did your patch rely on printf?
> On 1/12/2011 9:23 AM, Gleb Peregud wrote:
>> Some time ago I've submitted similar but simpler patch. It was a
>> float_to_list/2 with a second parameter being an integer specifying
>> precision. For me it was important to generate A LOT of floats as
>> strings as fast as possible with specified precision. Serge's version
>> has an overhead of inspecting proplist of the second parameter. So I
>> was wondering about introducing two versions of this function: with a
>> proplist as a second parameter and with a number as a second
>> parameter. Alternatively proplist version can be factored out into
>> float_to_list_opts/2.
>> Just my 0.2 cents
>> On Wed, Jan 12, 2011 at 15:10, Serge Aleynikov<>
>>  wrote:
>>> The reason I called it precision was to be consistent with the naming
>>> convention of the printf function.  Below is the extract from "man 3
>>> printf", which refers to the digits after the decimal point as
>>> "precision":
>>>       f, F   The  double  argument is rounded and converted to decimal
>>>              notation in the style [-]ddd.ddd, where the number of
>>>              digits after the decimal-point character is equal to the
>>>              precision specification.  If the precision is missing,
>>>              it  is taken as 6; if the precision is explicitly zero,
>>>              no decimal-point character appears.  If a decimal point
>>>              appears, at least one digit appears before it.
>>> I don't have a very strong preference for calling it precision or scale,
>>> but
>>> I do have a strong preference for including this patch in the
>>> distribution,
>>> because the default behavior of float_to_list/1 hard-coded in C is
>>> deficient.
>>> On 1/12/2011 4:58 AM, nox wrote:
>>>> Il should be called "scale", shouldn't it?
>>>> Le 12 janv. 2011 à 10:26, Pierpaolo Bernardi<>    a
>>>> écrit
>>>> :
>>>>> On Wed, Jan 12, 2011 at 06:44, Serge Aleynikov<>
>>>>>  wrote:
>>>>>> Attached please find a patch that adds a new float_to_list/2 BIF.  The
>>>>>> patch
>>>>>> was created off of the master branch of https://github.com/erlang/otp.
>>>>>> This BIF solves a problem of float_to_list/1 that doesn't allow
>>>>>> specifying
>>>>>> the number of digits after the decimal point when formatting floats.
>>>>>>        float_to_list(Float, Options) ->    string()
>>>>>>        Float = float()
>>>>>>        Options = [Option]
>>>>>>        Option = {precision, Precision::integer()} | compact
>>>>>>        Text representation of a float formatted using given options
>>>>>>        Returns a string which corresponds to the text
>>>>>>        representation of Float using fixed decimal point formatting.
>>>>>>        When precision option is specified
>>>>>>        the returned value will contain at most Precision number of
>>>>>>        digits past the decimal point.  When compact option is provided
>>>>>>        the trailing zeros at the end of the list are truncated.
>>>>> I think the option is misnamed.
>>>>> In the usual terminology, 'precision' is the total number of
>>>>> significative digits, not only the ones past the decimal point.
>>>>> Cheers
>>>>> P.
>>>>> ________________________________________________________________
>>>>> erlang-questions (at) erlang.org mailing list.
>>>>> See http://www.erlang.org/faq.html
>>>>> To unsubscribe; mailto:
>>> ________________________________________________________________
>>> erlang-questions (at) erlang.org mailing list.
>>> See http://www.erlang.org/faq.html
>>> To unsubscribe; mailto:

More information about the erlang-questions mailing list