! haphazard

ruby-talk
1

is ! haphazardly implemented for a reason?

yes: array.sort!

no: array.sort_by!

2

Tell us what you mean by 'haphazardly' ?

I guess I just don't understand your question.

Dan

3

The first two times I read it, I thought he was referring to a
"!haphazardly" method, which was one I hadn't heard of yet.

I think what he was trying to ask was: Is there some reason why
certain methods, like Array#sort, have both a "bang" version (i.e.
Array#sort!) and a non-bang version (i.e. Array#sort), while other
very similar methods (like Array#sort_by) only offer one of those
choices? Why the inconsistency?

···

On Sun, 27 Mar 2005 10:47:15 +0900, Daniel Amelang <daniel.amelang@gmail.com> wrote:

Tell us what you mean by 'haphazardly' ?

I guess I just don't understand your question.

4

Tell us what you mean by 'haphazardly' ?

I guess I just don't understand your question.

The first two times I read it, I thought he was referring to a
"!haphazardly" method, which was one I hadn't heard of yet.

I think what he was trying to ask was: Is there some reason why
certain methods, like Array#sort, have both a "bang" version (i.e.
Array#sort!) and a non-bang version (i.e. Array#sort), while other
very similar methods (like Array#sort_by) only offer one of those
choices? Why the inconsistency?

That's correct, thank you.

5

Gotcha. Well, I can tell you firsthand about the controversies of the
'bang' methods (like 'sort!', etc). Since they really aren't a
necessity (you can get along with just the non-bang versions) and ruby
has only relatively recently acquired sort_by, I bet they just didn't
get around to writing the bang version of sort_by.

FYI, bang methods have been found to be only slightly more efficient
than their non-bang versions ('sort' and 'sort!' being pretty much the
same, efficiency-wise) In case it helps, we discussed bang methods
quite extensively last week:

http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/134200
http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/134262

I've recently fallen back to only using the non-bang version of
methods and the only thing I've missed is the expressiveness of my
code (e.g. c'mon you 'reject!', 'squeeze!' the 'next!' 'sub!', you
'succ!'er)

It's late.

Dan

6

I've recently fallen back to only using the non-bang version of
methods and the only thing I've missed is the expressiveness of my
code (e.g. c'mon you 'reject!', 'squeeze!' the 'next!' 'sub!', you
'succ!'er)
It's late.

reminds me of the funny headlines from El Reg when they tease Yahoo
for their promiscuous use of the exclamation symbol

7

Thank you for the information.

It doesn't seem that you can chain them either, which is too bad.

I'm just surprised by this-- that's a pretty glaring inconsistency. It should be in everything or nothing.

Daniel Amelang wrote:

···

Gotcha. Well, I can tell you firsthand about the controversies of the
'bang' methods (like 'sort!', etc). Since they really aren't a
necessity (you can get along with just the non-bang versions) and ruby
has only relatively recently acquired sort_by, I bet they just didn't
get around to writing the bang version of sort_by.

FYI, bang methods have been found to be only slightly more efficient
than their non-bang versions ('sort' and 'sort!' being pretty much the
same, efficiency-wise) In case it helps, we discussed bang methods
quite extensively last week:

http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/134200
http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/134262

I've recently fallen back to only using the non-bang version of
methods and the only thing I've missed is the expressiveness of my
code (e.g. c'mon you 'reject!', 'squeeze!' the 'next!' 'sub!', you
'succ!'er)

It's late.

Dan

8

Daniel Amelang wrote:

Gotcha. Well, I can tell you firsthand about the controversies of the
'bang' methods (like 'sort!', etc). Since they really aren't a
necessity (you can get along with just the non-bang versions) and ruby
has only relatively recently acquired sort_by, I bet they just didn't
get around to writing the bang version of sort_by.

sort! sorts an array in place, while sort always makes a copy from the original array. This distinction wouldn't be sensible for sort_by, because it's actually a Schwartzian Transform, that always creates temporary arrays:

class Array
  def sort_by
    map { |x| [ x, yield(x) ] }.sort { |a,b|
      a.last <=> b.last
    }.map { |p| p.first }
  end
end

The transform makes a lot of sense if the yielded computations is very expensive, because O(n) < O(n*log(n)). It's good to know about the trade off between creating temporary arrays and the computation of the sort keys, if one has to choose between sort(!) and sort_by.

···

--
Florian Frank

9

Florian Frank wrote:

Daniel Amelang wrote:

Gotcha. Well, I can tell you firsthand about the controversies of the
'bang' methods (like 'sort!', etc). Since they really aren't a
necessity (you can get along with just the non-bang versions) and ruby
has only relatively recently acquired sort_by, I bet they just didn't
get around to writing the bang version of sort_by.

sort! sorts an array in place, while sort always makes a copy from the original array. This distinction wouldn't be sensible for sort_by, because it's actually a Schwartzian Transform, that always creates temporary arrays:

class Array
def sort_by
   map { |x| [ x, yield(x) ] }.sort { |a,b|
     a.last <=> b.last
   }.map { |p| p.first }
end
end

The transform makes a lot of sense if the yielded computations is very expensive, because O(n) < O(n*log(n)). It's good to know about the trade off between creating temporary arrays and the computation of the sort keys, if one has to choose between sort(!) and sort_by.

this is very interesting, thank you.

but for myself and perhaps many other users it comes down to how intuitive the language is. from this perspective: if sort! works, sort_by! should also.

one of the things that drew me to ruby recently was this philosophy, but there have been some off-putting inconsistencies.

10

bertrandmuscle@yahoo.com wrote:

Thank you for the information.

It doesn't seem that you can chain them either, which is too bad.

I'm just surprised by this-- that's a pretty glaring inconsistency. It should be in everything or nothing.

"Everything or nothing" is a good first-order rule.

But as you start to examine things more deeply, sometimes you find
reasons that some should be left out.

I'm sorry I don't have an example -- I agree it's unconvincing for
me to make such an assertion without backing it up.

Hal

11

There are two very important things to remember...

Ruby is perfectly intuitive to Matz.

If you stick around, Matz will program your brain.

(Also,

A foolish consistency is the hobgoblin of little minds.)

PGP.sig (186 Bytes)

···

On 27 Mar 2005, at 15:34, bertrandmuscle@yahoo.com wrote:

but for myself and perhaps many other users it comes down to how intuitive the language is. from this perspective: if sort! works, sort_by! should also.

one of the things that drew me to ruby recently was this philosophy, but there have been some off-putting inconsistencies.

--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

12

Hi --

Florian Frank wrote:

Daniel Amelang wrote:

Gotcha. Well, I can tell you firsthand about the controversies of the
'bang' methods (like 'sort!', etc). Since they really aren't a
necessity (you can get along with just the non-bang versions) and ruby
has only relatively recently acquired sort_by, I bet they just didn't
get around to writing the bang version of sort_by.

sort! sorts an array in place, while sort always makes a copy from the original array. This distinction wouldn't be sensible for sort_by, because it's actually a Schwartzian Transform, that always creates temporary arrays:

class Array
def sort_by
   map { |x| [ x, yield(x) ] }.sort { |a,b|
     a.last <=> b.last
   }.map { |p| p.first }
end
end

The transform makes a lot of sense if the yielded computations is very expensive, because O(n) < O(n*log(n)). It's good to know about the trade off between creating temporary arrays and the computation of the sort keys, if one has to choose between sort(!) and sort_by.

this is very interesting, thank you.

but for myself and perhaps many other users it comes down to how intuitive the language is. from this perspective: if sort! works, sort_by! should also.

You can always define your own:

   class Array
     def sort_by!(&b)
       replace(sort_by &b)
     end
   end

with the usual caveats about reopening core classes.

one of the things that drew me to ruby recently was this philosophy, but there have been some off-putting inconsistencies.

Don't be put off. There are forums for bringing these things to the
attention of Matz and discussing them with him and others, and for
requesting changes to the language if you conclude that that's
appropriate.

David

···

On Mon, 28 Mar 2005 bertrandmuscle@yahoo.com wrote:

--
David A. Black
dblack@wobblini.net

13

There is no substitute for understanding what the algorithm is doing
and the efficiency implications... it is not about intuition or
consistency. It might be about documentation.

sort_by has efficiency tradeoffs and advantages compared to sort, and
as previously explained it doesn't make sense to have a sort_by! As
another example, MergeSort is a stable sort and QuickSort is an
unstable sort... would it make sense to have an unstable
implementation of MergeSort and a stable implementation of QuickSort
for intuitive and consistency purposes?

Cheers,
Navin.

···

bertrandmuscle@yahoo.com <bertrandmuscle@yahoo.com> wrote:

this is very interesting, thank you.

but for myself and perhaps many other users it comes down to how
intuitive the language is. from this perspective: if sort! works,
sort_by! should also.

one of the things that drew me to ruby recently was this philosophy, but
there have been some off-putting inconsistencies.

14

David A. Black wrote:

You can always define your own:

  class Array
    def sort_by!(&b)
      replace(sort_by &b)
    end
  end

No, first you have to test whether or not sort_by actually changed the order of items in the Array, if not then you must return nil. :wink:

···

--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/&gt;

15

but for myself and perhaps many other users it comes down to how intuitive the language is. from this perspective: if sort! works, sort_by! should also.

one of the things that drew me to ruby recently was this philosophy, but there have been some off-putting inconsistencies.

There is no substitute for understanding what the algorithm is doing
and the efficiency implications... it is not about intuition or
consistency. It might be about documentation.

I don't agree with this statement. This would be true, perhaps, if the !bang method was some kind of loaded module and not part of the core language. The essence of the language itself should be consistent beyond anything else.

16

Hi --

···

On Mon, 28 Mar 2005, Glenn Parker wrote:

David A. Black wrote:

You can always define your own:

  class Array
    def sort_by!(&b)
      replace(sort_by &b)
    end
  end

No, first you have to test whether or not sort_by actually changed the order of items in the Array, if not then you must return nil. :wink:

Hey, it's my ! method; it can do whatever I want :slight_smile:

David

--
David A. Black
dblack@wobblini.net

17

There are two very important things to remember...

Ruby is perfectly intuitive to Matz.

If you stick around, Matz will program your brain.

···

On 29 Mar 2005, at 13:29, bertrandmuscle@yahoo.com wrote:

but for myself and perhaps many other users it comes down to how intuitive the language is. from this perspective: if sort! works, sort_by! should also.

one of the things that drew me to ruby recently was this philosophy, but there have been some off-putting inconsistencies.

There is no substitute for understanding what the algorithm is doing
and the efficiency implications... it is not about intuition or
consistency. It might be about documentation.

I don't agree with this statement. This would be true, perhaps, if the !bang method was some kind of loaded module and not part of the core language. The essence of the language itself should be consistent beyond anything else.

--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

18

bertrandmuscle@yahoo.com wrote:

I don't agree with this statement. This would be true, perhaps, if the !bang method was some kind of loaded module and not part of the core language. The essence of the language itself should be consistent beyond
anything else.

The "!" is a purely rhetorical convention, like Hungarian notation (ick). I think the core library uses "!" in a consistent manner, but nothing about the essence of the language requires a matching "!" version for every method.

···

--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/&gt;