From: Robert Klemme <shortcutter@...>
Date: 2008-07-04T00:00:27+09:00
Subject: Re: thoughts on a more generic Array#partition function

2008/7/3 Rudi Cilibrasi <cilibrar@gmail.com>:
> On Thu, Jul 3, 2008 at 5:13 AM, Robert Klemme
> <shortcutter@googlemail.com> wrote:
>> 2008/7/3 Rick DeNatale <rick.denatale@gmail.com>:
>>> On Thu, Jul 3, 2008 at 12:53 AM, Peņa, Botp <botp@delmonte-phil.com> wrote:
>>>> From: Rudi Cilibrasi [mailto:cilibrar@gmail.com]
>>> Not exactly the same, values doesn't guarantee the desired ordering by key.
>>
>> That's easily fixed:
>>
>> arbitrary_hash.sort_by {|k,| k}.map {|k,v| v}
>>
>> Having said that the #group_by implementation seems the more general
>> solution (because of less requirements, i.e. keys do not need to
>> provide <=>).
>
> I have come to agree with your analysis.  I think this one-line
> expression you made is very good:  As far as source-code brevity,
> clarity, and correctness this expression you invented gets high marks
> because there are no dangling outer variable etc and that is great.

Oh, thank you!

> But my small problem now is the extra code-block calls during runtime.
>  I guess there is one more code-block call per element in the
> expression as written compared to npartition.  So it is now down to a
>
> 1) small efficiency difference (probably npartition is slightly faster
> but untested)

I'd be guessing that #group_by is faster - because it's implemented in
C.  But you should benchmark for a definitive answer.  I have been
surprise more often than not - following big O calculus can be quite
misleading at times. :-)

Cheers

robert

-- 
use.inject do |as, often| as.you_can - without end