[erlang-questions] [patch] new float_to_list/2
Serge Aleynikov
serge@REDACTED
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<serge@REDACTED> 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<serge@REDACTED>
>>> 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<olopierpa@REDACTED> a
>>>>> écrit
>>>>> :
>>>>>
>>>>>> On Wed, Jan 12, 2011 at 06:44, Serge Aleynikov<serge@REDACTED>
>>>>>> 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-unsubscribe@REDACTED
>>>>>>
>>>>
>>>> ________________________________________________________________
>>>> erlang-questions (at) erlang.org mailing list.
>>>> See http://www.erlang.org/faq.html
>>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>>>
>>>>
>>
More information about the erlang-patches
mailing list