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

Tue Mar 13 15:00:30 CET 2012

Hi Serge,

We'll get back to you about this patch after the ERTS team have reviewed it.
Thank you for the contribution!

Regards,
Gustav Simonsson
Erlang/OTP team

On 2012-03-08 19:03, Serge Aleynikov wrote:
> 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
>>>
>>
>>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20120313/eed22cde/attachment.htm>