Re: Add lists:init/1 - got tired of implementing it

On Thu, May 2, 2013 at 2:00 AM, Hans Svensson <[email protected]> wrote:
> You should consider compiling the code before measuring, there is a
> difference in speed...
> Also, if you'd done that you would have spotted the error in your recursive
> implementation...

Indeed!

> test_sc.erl:66: Warning: this clause cannot match because a previous clause
> at line 65 always matches
>
> Your recursive implementation throws away the whole list immediately, which
> is fast but wrong...

One must make certain sacrifices for speed ;)

> Fixing the recursive implementation and re-running with escript (after
> changing the sizes of the tests into something smaller) I got
> reverse_reverse:small_list: 251
> reverse_reverse:big_list: 34
> recurse:small_list: 6752
> recurse:big_list: 7295
> sublist:small_list: 295
> sublist:big_list: 69

I nearly blew up my laptop running the correct version.

> Which shows the severe performance penalty involved for not compiling the
> code... Compiling it yields (with your original test sizes):
> reverse_reverse:small_list: 347
> reverse_reverse:big_list: 3133
> recurse:small_list: 411
> recurse:big_list: 4036
> sublist:small_list: 635
> sublist:big_list: 6175

Thanks for pointing this out!

There's a -mode(compile) attribute you can add to escript files that
will compile them. In addition to getting a more representative
result, it gives you compiler warnings.

It's interesting to me how optimized the recursive algorithm is when compiled!

> However, the typical lists on which I'd use init/drop_last, would have
> length < 20

But you *could* use sublist in a pinch :)

And if the semantics were awkward, you *could* write a small function
or macro to name it appropriately.

I know I'm repeating myself, but I think there ought to be a high
standard for adding to core modules -- I just don't see it here.

Thanks very much for pointing out the compilation problem with erlang-bench!

Garrett

> On 2013-04-30 15:32, Garrett Smith wrote:
>>
>> I would use lists:sublist(L, 1, length(L) - 1) for this. I wouldn't
>> have given it a second thought.
>>
>> Presumably there's a concern about performance -- why else would we
>> need yet-another-function?
>>
>> Here's a simple benchmark program that people can experiment with (or
>> improve):
>>
>> https://github.com/gar1t/erlang-bench/blob/master/drop-last.escript
>>
>> It includes the original implementation, Fred's, and what I would use
>> (sublist).
>>
>> Personally, I don't see a problem that warrants a new function in the
>> lists module.
>>
>> On Tue, Apr 30, 2013 at 5:05 AM, Siri Hansen <[email protected]> wrote:
>>>
>>> We haven't yet made any decision regarding this patch, but we have had
>>> some
>>> discussions in the team and we are not totally convinced about the
>>> general
>>> need for this function. Thus we would appreciate some input from the
>>> list.
>>>
>>> So - disregarding the name and the implementation for a second - is this
>>> functionality a good addition to the lists module? Is it often needed?
>>>
>>> If so, would it be even better to do a more general version which removes
>>> the N last elements from the list?
>>>
>>> Hans, could you also possibly describe some of your use cases?
>>>
>>> Regards
>>> siri@otp
>>>
>>>
>>> 2013/4/29 Fredrik <[email protected]>
>>>>
>>>> On 04/25/2013 05:12 PM, Hans Svensson wrote:
>>>>>
>>>>> git fetch git://github.com/hanssv/otp.git add_init_to_lists
>>>>
>>>> Fetched, it is currently located in the 'pu' branch.
>>>> A review process has started.
>>>> Thanks,
>>>>
>>>> --
>>>>
>>>> BR Fredrik Gustafsson
>>>> Erlang OTP Team
>>>>
>>>>
>>>> _______________________________________________
>>>> erlang-patches mailing list
>>>> [email protected]
>>>> http://erlang.org/mailman/listinfo/erlang-patches
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-patches mailing list
>>> [email protected]
>>> http://erlang.org/mailman/listinfo/erlang-patches
>>>
>
_______________________________________________
erlang-patches mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-patches