Hi, given the following array:
array = ["qwe", "qwerty"]
How to get the shortest element ("qwe") from the array?
I whink I must inspect all the elements within the array and manually
select the shortest string, do I miss some cool feature of Array class
or Enumerable module?
Thanks a lot.
--
Iñaki Baz Castillo
<ibc@aliax.net>
array.min{|a,b| a.size <=> b.size }
--
Posted via http://www.ruby-forum.com/.
Hi,
in Ruby 1.9 this should work:
arr.sort_by(&:length)[0]
or more portable/readable (1.8 compatible):
arr.sort_by{|s| s.length }[0]
Am 03.03.2011 15:47, schrieb Iñaki Baz Castillo:
Hi, given the following array:
array = ["qwe", "qwerty"]
How to get the shortest element ("qwe") from the array?
I whink I must inspect all the elements within the array and manually
select the shortest string, do I miss some cool feature of Array class
or Enumerable module?Thanks a lot.
Hi,
You could use
array.min {|x,y| x.size <=> y.size}
to force a min to use sizes rather then their natural order
Mac
On Thu, Mar 3, 2011 at 2:47 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
Hi, given the following array:
array = ["qwe", "qwerty"]
How to get the shortest element ("qwe") from the array?
I whink I must inspect all the elements within the array and manually
select the shortest string, do I miss some cool feature of Array class
or Enumerable module?Thanks a lot.
--
Iñaki Baz Castillo
<ibc@aliax.net>
Thanks to all 
2011/3/3 Paul McKibbin <pmckibbin@gmail.com>:
Hi,
You could use
array.min {|x,y| x.size <=> y.size}
to force a min to use sizes rather then their natural order
--
Iñaki Baz Castillo
<ibc@aliax.net>
You can actually simplify this even more. Take a look at Enumerable#min_by:
http://rdoc.info/stdlib/core/1.8.7/Enumerable:min_by
-Jeremy
On 3/3/2011 09:01, Adam Hegge wrote:
array.min{|a,b| a.size <=> b.size }
in Ruby 1.9 this should work:
arr.sort_by(&:length)[0]
Inefficient as it creates a new array. Better do
irb(main):001:0> ["qwe", "qwerty"].min_by(&:length)
=> "qwe"
or more portable/readable (1.8 compatible):
arr.sort_by{|s| s.length }[0]
Inefficient as well (see above).
Cheers
robert
On 03.03.2011 16:02, Thorsten Hater wrote:
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
Very true
array.min_by{|a| a.size} would also do the trick.
Paul
On Thu, Mar 3, 2011 at 3:11 PM, Jeremy Bopp <jeremy@bopp.net> wrote:
On 3/3/2011 09:01, Adam Hegge wrote:
> array.min{|a,b| a.size <=> b.size }You can actually simplify this even more. Take a look at
Enumerable#min_by:http://rdoc.info/stdlib/core/1.8.7/Enumerable:min_by
-Jeremy
They're also O( n lg n ) where the correct solution, using min, is O(n)
On Thu, Mar 3, 2011 at 11:35 AM, Robert Klemme <shortcutter@googlemail.com>wrote:
On 03.03.2011 16:02, Thorsten Hater wrote:
in Ruby 1.9 this should work:
arr.sort_by(&:length)[0]
Inefficient as it creates a new array. Better do
irb(main):001:0> ["qwe", "qwerty"].min_by(&:length)
=> "qwe"or more portable/readable (1.8 compatible):
arr.sort_by{|s| s.length }[0]
Inefficient as well (see above).
Cheers
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
How do you know that it's O(n * log n)? A reasonable implementation
of min_by would look like this:
def min_by(enum, &c)
min = nil
val = nil
enum.each do |e|
e_val = c[e]
if val.nil? || e_val < val
min = e
val = e_val
end
end
min
end
As far as I can see this is O(n).
Also, big O isn't everything. Usually object allocation is very
expensive (compared to other operations) because of the GC
housekeeping overhead.
Cheers
robert
On Thu, Mar 3, 2011 at 7:18 PM, Josh Cheek <josh.cheek@gmail.com> wrote:
On Thu, Mar 3, 2011 at 11:35 AM, Robert Klemme > <shortcutter@googlemail.com>wrote:
On 03.03.2011 16:02, Thorsten Hater wrote:
in Ruby 1.9 this should work:
arr.sort_by(&:length)[0]
Inefficient as it creates a new array. Better do
irb(main):001:0> ["qwe", "qwerty"].min_by(&:length)
=> "qwe"or more portable/readable (1.8 compatible):
arr.sort_by{|s| s.length }[0]
Inefficient as well (see above).
They're also O( n lg n ) where the correct solution, using min, is O(n)
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
>
>>
>>> in Ruby 1.9 this should work:
>>>
>>> arr.sort_by(&:length)[0]
>>>
>>
>> Inefficient as it creates a new array. Better do
>>
>> irb(main):001:0> ["qwe", "qwerty"].min_by(&:length)
>> => "qwe"
>>
>>
>> or more portable/readable (1.8 compatible):
>>>
>>> arr.sort_by{|s| s.length }[0]
>>>
>>
>> Inefficient as well (see above).> They're also O( n lg n ) where the correct solution, using min, is O(n)
How do you know that it's O(n * log n)? A reasonable implementation
of min_by would look like this:def min_by(enum, &c)
min = nil
val = nilenum.each do |e|
e_val = c[e]if val.nil? || e_val < val
min = e
val = e_val
end
endmin
endAs far as I can see this is O(n).
Right. This was my point: using min is O(n), using sort is O(n lg n)
Also, big O isn't everything. Usually object allocation is very
expensive (compared to other operations) because of the GC
housekeeping overhead.
I don't contest this. I was pointing out that in addition to creating more
objects, as you previously mentioned, using sort also has a worse time
complexity.
On Fri, Mar 4, 2011 at 4:11 AM, Robert Klemme <shortcutter@googlemail.com>wrote:
On Thu, Mar 3, 2011 at 7:18 PM, Josh Cheek <josh.cheek@gmail.com> wrote:
> On Thu, Mar 3, 2011 at 11:35 AM, Robert Klemme > > <shortcutter@googlemail.com>wrote:
>> On 03.03.2011 16:02, Thorsten Hater wrote:
>
>>
>>> in Ruby 1.9 this should work:
>>>
>>> arr.sort_by(&:length)[0]
>>>
>>
>> Inefficient as it creates a new array. Better do
>>
>> irb(main):001:0> ["qwe", "qwerty"].min_by(&:length)
>> => "qwe"
>>
>>
>> or more portable/readable (1.8 compatible):
>>>
>>> arr.sort_by{|s| s.length }[0]
>>>
>>
>> Inefficient as well (see above).> They're also O( n lg n ) where the correct solution, using min, is O(n)
Right. This was my point: using min is O(n), using sort is O(n lg n)
OK, now I get what you mean. You were referring to the sorts. That
wasn't clear to me.
Also, big O isn't everything. Usually object allocation is very
expensive (compared to other operations) because of the GC
housekeeping overhead.I don't contest this. I was pointing out that in addition to creating more
objects, as you previously mentioned, using sort also has a worse time
complexity.
Yep, sorry for the noise.
Cheers
robert
On Fri, Mar 4, 2011 at 11:36 AM, Josh Cheek <josh.cheek@gmail.com> wrote:
On Fri, Mar 4, 2011 at 4:11 AM, Robert Klemme <shortcutter@googlemail.com>wrote:
On Thu, Mar 3, 2011 at 7:18 PM, Josh Cheek <josh.cheek@gmail.com> wrote:
> On Thu, Mar 3, 2011 at 11:35 AM, Robert Klemme >> > <shortcutter@googlemail.com>wrote:
>> On 03.03.2011 16:02, Thorsten Hater wrote:
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/