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

Serge Aleynikov serge@REDACTED
Thu Mar 8 19:03:22 CET 2012


Dear Sverker,

Sorry for a belated response.  The following commit addresses three 
issues you indicated.  Attached is also a small performance test program 
which illustrates that the new float_to_list/2 is about 6x faster than 
float_to_list/1:

https://github.com/saleyn/otp/commit/d7a108f28fd8cd519852feb0233920af511b5eba

git fetch git://github.com/saleyn/otp.git float_to_list_2

https://github.com/saleyn/otp/compare/float_to_list_2
https://github.com/saleyn/otp/compare/float_to_list_2.patch


Executing the attachment test function:
1> test:test(1.0).
float_to_list(1.000000, [])               = {0.149531,"1.000000"}
float_to_list(1.000000, [{decimals, 4}]) = {0.109001,"1.0000"}
float_to_list(1.000000) = {0.629831,"1.00000000000000000000e+00"}
ok

Regards,

Serge

P.S. I don't have access to solaris and freebsd at the moment, but the 
code works on 32/64-bit linux, and is identical for those two platforms.

On 3/28/2011 11:39 AM, Sverker Eriksson wrote:
> Thanks for your patch. As you may have seen it did not make it into R14B02.
>
> Comments:
>
> 1. Test fail on some platforms (32-bit solaris, freebsd and 64-bit linux)
>
> float_to_list(1.0,[compact])
>
> returns "1." instead of "1.0"
>
>
> 2. Would like the interface to be extendable to support printf's %e and
> %g formats in future. Maybe just rename 'precision' to 'decimals'.
>
> 3. Why is default 4 decimals when printf and io:format has 6 as default.
>
>
> /Sverker, Erlang/OTP
>
>
>
>
> Serge Aleynikov wrote:
>> 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
>>>>>>
>>>>>>
>>>>
>>
>> ________________________________________________________________
>> erlang-patches (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-patches-unsubscribe@REDACTED
>>
>
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.erl
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20120308/be7b72cb/attachment.ksh>


More information about the erlang-patches mailing list