<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 05/02/2013 03:27 PM, Hans Svensson wrote:
<blockquote cite="mid:518269DD.701@gmail.com" type="cite">On
2013-05-02 15:07, Garrett Smith wrote:
<br>
<blockquote type="cite">On Thu, May 2, 2013 at 2:00 AM, Hans
Svensson <a class="moz-txt-link-rfc2396E" href="mailto:hanssv@gmail.com"><hanssv@gmail.com></a> wrote:
<br>
<blockquote type="cite">You should consider compiling the code
before measuring, there is a
<br>
difference in speed...
<br>
Also, if you'd done that you would have spotted the error in
your recursive
<br>
implementation...
<br>
</blockquote>
Indeed!
<br>
<br>
<blockquote type="cite">test_sc.erl:66: Warning: this clause
cannot match because a previous clause
<br>
at line 65 always matches
<br>
<br>
Your recursive implementation throws away the whole list
immediately, which
<br>
is fast but wrong...
<br>
</blockquote>
One must make certain sacrifices for speed ;)
<br>
<br>
<blockquote type="cite">Fixing the recursive implementation and
re-running with escript (after
<br>
changing the sizes of the tests into something smaller) I got
<br>
reverse_reverse:small_list: 251
<br>
reverse_reverse:big_list: 34
<br>
recurse:small_list: 6752
<br>
recurse:big_list: 7295
<br>
sublist:small_list: 295
<br>
sublist:big_list: 69
<br>
</blockquote>
I nearly blew up my laptop running the correct version.
<br>
<br>
<blockquote type="cite">Which shows the severe performance
penalty involved for not compiling the
<br>
code... Compiling it yields (with your original test sizes):
<br>
reverse_reverse:small_list: 347
<br>
reverse_reverse:big_list: 3133
<br>
recurse:small_list: 411
<br>
recurse:big_list: 4036
<br>
sublist:small_list: 635
<br>
sublist:big_list: 6175
<br>
</blockquote>
Thanks for pointing this out!
<br>
<br>
There's a -mode(compile) attribute you can add to escript files
that
<br>
will compile them. In addition to getting a more representative
<br>
result, it gives you compiler warnings.
<br>
<br>
It's interesting to me how optimized the recursive algorithm is
when compiled!
<br>
<br>
<blockquote type="cite">However, the typical lists on which I'd
use init/drop_last, would have
<br>
length < 20
<br>
</blockquote>
But you *could* use sublist in a pinch :)
<br>
</blockquote>
I could, but I'd have to look into the documentation to see, is it
sublist(L, 1, length(L) -1), sublist(1, L, length(L)-1), or
sublist(L, 0, length(L)-1). Instead I'd write
reverse(tl(reverse(L))) for sure.
<br>
<blockquote type="cite">And if the semantics were awkward, you
*could* write a small function
<br>
or macro to name it appropriately.
<br>
<br>
I know I'm repeating myself, but I think there ought to be a
high
<br>
standard for adding to core modules -- I just don't see it here.
<br>
</blockquote>
I also think there is a symmetry argument to make, we have hd and
tl, but we miss the companion to last!?
<br>
<blockquote type="cite">
<br>
Thanks very much for pointing out the compilation problem with
erlang-bench!
<br>
</blockquote>
No problem, the results were so far from mine that I'd thought
there had to be something fishy going on...
<br>
<br>
/Hans
<br>
<blockquote type="cite">Garrett
<br>
<br>
<blockquote type="cite">On 2013-04-30 15:32, Garrett Smith
wrote:
<br>
<blockquote type="cite">I would use lists:sublist(L, 1,
length(L) - 1) for this. I wouldn't
<br>
have given it a second thought.
<br>
<br>
Presumably there's a concern about performance -- why else
would we
<br>
need yet-another-function?
<br>
<br>
Here's a simple benchmark program that people can experiment
with (or
<br>
improve):
<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/gar1t/erlang-bench/blob/master/drop-last.escript">https://github.com/gar1t/erlang-bench/blob/master/drop-last.escript</a>
<br>
<br>
It includes the original implementation, Fred's, and what I
would use
<br>
(sublist).
<br>
<br>
Personally, I don't see a problem that warrants a new
function in the
<br>
lists module.
<br>
<br>
On Tue, Apr 30, 2013 at 5:05 AM, Siri Hansen
<a class="moz-txt-link-rfc2396E" href="mailto:erlangsiri@gmail.com"><erlangsiri@gmail.com></a> wrote:
<br>
<blockquote type="cite">We haven't yet made any decision
regarding this patch, but we have had
<br>
some
<br>
discussions in the team and we are not totally convinced
about the
<br>
general
<br>
need for this function. Thus we would appreciate some
input from the
<br>
list.
<br>
<br>
So - disregarding the name and the implementation for a
second - is this
<br>
functionality a good addition to the lists module? Is it
often needed?
<br>
<br>
If so, would it be even better to do a more general
version which removes
<br>
the N last elements from the list?
<br>
<br>
Hans, could you also possibly describe some of your use
cases?
<br>
<br>
Regards
<br>
siri@otp
<br>
<br>
<br>
2013/4/29 Fredrik <a class="moz-txt-link-rfc2396E" href="mailto:fredrik@erlang.org"><fredrik@erlang.org></a>
<br>
<blockquote type="cite">On 04/25/2013 05:12 PM, Hans
Svensson wrote:
<br>
<blockquote type="cite">git fetch
git://github.com/hanssv/otp.git add_init_to_lists
<br>
</blockquote>
Fetched, it is currently located in the 'pu' branch.
<br>
A review process has started.
<br>
Thanks,
<br>
<br>
--
<br>
<br>
BR Fredrik Gustafsson
<br>
Erlang OTP Team
<br>
<br>
<br>
_______________________________________________
<br>
erlang-patches mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:erlang-patches@erlang.org">erlang-patches@erlang.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-patches">http://erlang.org/mailman/listinfo/erlang-patches</a>
<br>
</blockquote>
<br>
<br>
_______________________________________________
<br>
erlang-patches mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:erlang-patches@erlang.org">erlang-patches@erlang.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-patches">http://erlang.org/mailman/listinfo/erlang-patches</a>
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
_______________________________________________
<br>
erlang-patches mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:erlang-patches@erlang.org">erlang-patches@erlang.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-patches">http://erlang.org/mailman/listinfo/erlang-patches</a>
<br>
</blockquote>
Hello Hans,<br>
I've got some feedback on your patch after review:<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue',
Helvetica, Arial, sans-serif; font-size: 13px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: 18px; orphans: 2; text-align: -webkit-auto;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; background-color: rgb(249, 249,
249); display: inline !important; float: none; ">We have decided
to reject this patch as we don't see a general need for the new
function.</span><br>
<br>
Thanks for showing interest in contributing!<br>
<pre class="moz-signature" cols="72">--
BR Fredrik Gustafsson
Erlang OTP Team</pre>
</body>
</html>