<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Serge,<br>
<br>
We'll get back to you about this patch after the ERTS team have
reviewed it.<br>
Thank you for the contribution!<br>
<br>
Regards,<br>
Gustav Simonsson<br>
Erlang/OTP team<br>
<br>
On 2012-03-08 19:03, Serge Aleynikov wrote:
<blockquote cite="mid:4F58F46A.5050701@aleynikov.org" type="cite">Dear
Sverker,
<br>
<br>
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:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/saleyn/otp/commit/d7a108f28fd8cd519852feb0233920af511b5eba">https://github.com/saleyn/otp/commit/d7a108f28fd8cd519852feb0233920af511b5eba</a>
<br>
<br>
git fetch git://github.com/saleyn/otp.git float_to_list_2
<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/saleyn/otp/compare/float_to_list_2">https://github.com/saleyn/otp/compare/float_to_list_2</a>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/saleyn/otp/compare/float_to_list_2.patch">https://github.com/saleyn/otp/compare/float_to_list_2.patch</a>
<br>
<br>
<br>
Executing the attachment test function:
<br>
1> test:test(1.0).
<br>
float_to_list(1.000000, []) = {0.149531,"1.000000"}
<br>
float_to_list(1.000000, [{decimals, 4}]) = {0.109001,"1.0000"}
<br>
float_to_list(1.000000) = {0.629831,"1.00000000000000000000e+00"}
<br>
ok
<br>
<br>
Regards,
<br>
<br>
Serge
<br>
<br>
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.
<br>
<br>
On 3/28/2011 11:39 AM, Sverker Eriksson wrote:
<br>
<blockquote type="cite">Thanks for your patch. As you may have
seen it did not make it into R14B02.
<br>
<br>
Comments:
<br>
<br>
1. Test fail on some platforms (32-bit solaris, freebsd and
64-bit linux)
<br>
<br>
float_to_list(1.0,[compact])
<br>
<br>
returns "1." instead of "1.0"
<br>
<br>
<br>
2. Would like the interface to be extendable to support printf's
%e and
<br>
%g formats in future. Maybe just rename 'precision' to
'decimals'.
<br>
<br>
3. Why is default 4 decimals when printf and io:format has 6 as
default.
<br>
<br>
<br>
/Sverker, Erlang/OTP
<br>
<br>
<br>
<br>
<br>
Serge Aleynikov wrote:
<br>
<blockquote type="cite">This implementation has been submitted
as the pull request:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/erlang/otp/pull/9">https://github.com/erlang/otp/pull/9</a>
<br>
<br>
This version is also optimized to run 5-10x faster than
<br>
float_to_list/1 for floats under 2^52.
<br>
<br>
Regards,
<br>
<br>
Serge
<br>
<br>
On 1/14/2011 10:33 AM, Gleb Peregud wrote:
<br>
<blockquote type="cite">Here's my patch:
<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.erlang.org/cgi-bin/ezmlm-cgi/4/43529">http://www.erlang.org/cgi-bin/ezmlm-cgi/4/43529</a>
<br>
<br>
It uses double sprintf invocations. Your solution is clearly
better (I
<br>
didn't knew it is possible to specify precision in args).
<br>
<br>
Your benchmark shows that difference is negligible. Between
integer as
<br>
a second parameter or a proplist (~0.4%). Though it might be
a bit
<br>
more "stable" in terms of running time, but still probably
not worth
<br>
considering it for performance reasons. It still may be
useful in
<br>
terms of simpler API, but I have no strong opinion on it.
<br>
<br>
So generally +1 on including Serge's patch into Erlang.
Serge, can you
<br>
put it into GitHub pull request? As described here:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/erlang/otp/wiki/submitting-patches">https://github.com/erlang/otp/wiki/submitting-patches</a>
<br>
<br>
Best,
<br>
Gleb
<br>
<br>
On Wed, Jan 12, 2011 at 18:13, Serge
Aleynikov<a class="moz-txt-link-rfc2396E" href="mailto:serge@aleynikov.org"><serge@aleynikov.org></a>
<br>
wrote:
<br>
<blockquote type="cite">I did a micro-benchmark on a
slightly modified version of the BIF that
<br>
accepts an integer as its options. The results shown below
display a
<br>
very
<br>
insignificant difference between a call with no options
and a call
<br>
with an
<br>
integer precision passed as the second argument:
<br>
<br>
1> test:test().
<br>
float_to_list(123.4, []) = {0.619512,"123.4000"}
<br>
float_to_list(123.4, [{precision, 4}]) =
{0.624895,"123.4000"}
<br>
float_to_list(123.4, 4) = {0.622896,"123.4000"}
<br>
<br>
The majority of time is actually spent in the printf(3)
function, which
<br>
takes longer to execute when given the "%.*f" argument
compared to
<br>
"%g" as
<br>
in float_to_list/1 case.
<br>
<br>
Did your patch rely on printf?
<br>
<br>
<br>
On 1/12/2011 9:23 AM, Gleb Peregud wrote:
<br>
<blockquote type="cite">
<br>
Some time ago I've submitted similar but simpler patch.
It was a
<br>
float_to_list/2 with a second parameter being an integer
specifying
<br>
precision. For me it was important to generate A LOT of
floats as
<br>
strings as fast as possible with specified precision.
Serge's version
<br>
has an overhead of inspecting proplist of the second
parameter. So I
<br>
was wondering about introducing two versions of this
function: with a
<br>
proplist as a second parameter and with a number as a
second
<br>
parameter. Alternatively proplist version can be
factored out into
<br>
float_to_list_opts/2.
<br>
<br>
Just my 0.2 cents
<br>
<br>
On Wed, Jan 12, 2011 at 15:10, Serge
Aleynikov<a class="moz-txt-link-rfc2396E" href="mailto:serge@aleynikov.org"><serge@aleynikov.org></a>
<br>
wrote:
<br>
<blockquote type="cite">
<br>
The reason I called it precision was to be consistent
with the naming
<br>
convention of the printf function. Below is the
extract from "man 3
<br>
printf", which refers to the digits after the decimal
point as
<br>
"precision":
<br>
<br>
f, F The double argument is rounded and converted to
decimal
<br>
notation in the style [-]ddd.ddd, where the number of
<br>
digits after the decimal-point character is equal to
the
<br>
precision specification. If the precision is missing,
<br>
it is taken as 6; if the precision is explicitly zero,
<br>
no decimal-point character appears. If a decimal point
<br>
appears, at least one digit appears before it.
<br>
<br>
I don't have a very strong preference for calling it
precision or
<br>
scale,
<br>
but
<br>
I do have a strong preference for including this patch
in the
<br>
distribution,
<br>
because the default behavior of float_to_list/1
hard-coded in C is
<br>
deficient.
<br>
<br>
<br>
On 1/12/2011 4:58 AM, nox wrote:
<br>
<blockquote type="cite">
<br>
Il should be called "scale", shouldn't it?
<br>
<br>
Le 12 janv. 2011 à 10:26, Pierpaolo
Bernardi<a class="moz-txt-link-rfc2396E" href="mailto:olopierpa@gmail.com"><olopierpa@gmail.com></a> a
<br>
écrit
<br>
:
<br>
<br>
<blockquote type="cite">On Wed, Jan 12, 2011 at
06:44, Serge Aleynikov<a class="moz-txt-link-rfc2396E" href="mailto:serge@aleynikov.org"><serge@aleynikov.org></a>
<br>
wrote:
<br>
<blockquote type="cite">
<br>
Attached please find a patch that adds a new
float_to_list/2
<br>
BIF. The
<br>
patch
<br>
was created off of the master branch of
<br>
<a class="moz-txt-link-freetext" href="https://github.com/erlang/otp">https://github.com/erlang/otp</a>.
<br>
<br>
This BIF solves a problem of float_to_list/1
that doesn't allow
<br>
specifying
<br>
the number of digits after the decimal point
when formatting
<br>
floats.
<br>
<br>
float_to_list(Float, Options) -> string()
<br>
<br>
Float = float()
<br>
Options = [Option]
<br>
Option = {precision, Precision::integer()} |
compact
<br>
<br>
Text representation of a float formatted using
given options
<br>
<br>
Returns a string which corresponds to the text
<br>
representation of Float using fixed decimal
point formatting.
<br>
When precision option is specified
<br>
the returned value will contain at most
Precision number of
<br>
digits past the decimal point. When compact
option is provided
<br>
the trailing zeros at the end of the list are
truncated.
<br>
</blockquote>
<br>
I think the option is misnamed.
<br>
<br>
In the usual terminology, 'precision' is the total
number of
<br>
significative digits, not only the ones past the
decimal point.
<br>
<br>
Cheers
<br>
P.
<br>
<br>
________________________________________________________________
<br>
erlang-questions (at) erlang.org mailing list.
<br>
See <a class="moz-txt-link-freetext" href="http://www.erlang.org/faq.html">http://www.erlang.org/faq.html</a>
<br>
To unsubscribe;
<a class="moz-txt-link-freetext" href="mailto:erlang-questions-unsubscribe@erlang.org">mailto:erlang-questions-unsubscribe@erlang.org</a>
<br>
<br>
</blockquote>
</blockquote>
<br>
________________________________________________________________
<br>
erlang-questions (at) erlang.org mailing list.
<br>
See <a class="moz-txt-link-freetext" href="http://www.erlang.org/faq.html">http://www.erlang.org/faq.html</a>
<br>
To unsubscribe;
<a class="moz-txt-link-freetext" href="mailto:erlang-questions-unsubscribe@erlang.org">mailto:erlang-questions-unsubscribe@erlang.org</a>
<br>
<br>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
________________________________________________________________
<br>
erlang-patches (at) erlang.org mailing list.
<br>
See <a class="moz-txt-link-freetext" href="http://www.erlang.org/faq.html">http://www.erlang.org/faq.html</a>
<br>
To unsubscribe; <a class="moz-txt-link-freetext" href="mailto:erlang-patches-unsubscribe@erlang.org">mailto:erlang-patches-unsubscribe@erlang.org</a>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
erlang-patches mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-patches@erlang.org">erlang-patches@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-patches">http://erlang.org/mailman/listinfo/erlang-patches</a>
</pre>
</blockquote>
<br>
</body>
</html>