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

Serge Aleynikov <>
Mon Jan 17 04:28:34 CET 2011


This implementation has been submitted as the pull request:

https://github.com/erlang/otp/pull/9

This version is also optimized to run 5-10x faster than float_to_list/1 
for floats under 2^52.

Regards,

Serge

On 1/14/2011 10:33 AM, Gleb Peregud wrote:
> Here's my patch:
>
> http://www.erlang.org/cgi-bin/ezmlm-cgi/4/43529
>
> 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:
>
> https://github.com/erlang/otp/wiki/submitting-patches
>
> Best,
> Gleb
>
> 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-patches mailing list