Select and select

[David_Alan_Black1 (David Alan Black)]

Hello –

I’d like to suggest (again, but the first time it was buried in
another thread that the new dual nature of “select” is kind of
awkward, and I’m wondering whether it’s been finalized.

I’ve always thought of select as a condition-based filter. I guess
one could argue that indexes are a condition… but it feels to me
like “select” is getting overloaded in a way that isn’t necessary.

In one case, I found myself writing:

select(*[i+n,i-n].select{|x| x > 0})

where the dual nature of select really comes through in (to me) a
strange way. I know it could be rewritten; I’m just not clear wher
the advantage of (or necessity for) using the same name for two things
comes from. Wouldn’t allowing #at to take multiple arguments be
cleaner?

David

···

–
David Alan Black | Register for RubyConf 2002!
home: dblack@candle.superlink.net | November 1-3
work: blackdav@shu.edu | Seattle, WA, USA
Web: http://pirate.shu.edu/~blackdav | http://www.rubyconf.com

[Yukihiro_Matsumoto2 (Yukihiro Matsumoto)]

Hi,

···

In message “select and select” on 02/09/19, dblack@candle.superlink.net dblack@candle.superlink.net writes:

I’d like to suggest (again, but the first time it was buried in
another thread that the new dual nature of “select” is kind of
awkward, and I’m wondering whether it’s been finalized.

Not yet, until 1.8.0 comes out. (don’t ask me when it will be.)
But considering the loooong thread we had without conclusion, it is
very hard to get a perfect name for the method. But I’m still open.

						matz.

[Gavin_Sinclair]

[We all know the context!]

Wouldn’t allowing #at to take multiple arguments be cleaner?

David

By now, the problem of overloading #at have been made clear: arr.at(a) returns
an Object, not an Array. Also, I think the primary purpose of #at is to not
be overloaded: i.e. it does what it does without any overhead.

‘pick’ is being touted. I do not like it. I like ‘grab’, but I doubt others
will To me, ‘pick’ sounds exactly like ‘select’: you ‘pick’ values based on
some criteria. OTOH, ‘grab’ sounds like a very straightforward operation,
which ‘indices’ is.

Gavin

···

----- Original Message -----
From: dblack@candle.superlink.net

[David_Alan_Black1 (David Alan Black)]

Hi –

Hi,

I’d like to suggest (again, but the first time it was buried in
another thread that the new dual nature of “select” is kind of
awkward, and I’m wondering whether it’s been finalized.

Not yet, until 1.8.0 comes out. (don’t ask me when it will be.)
But considering the loooong thread we had without conclusion, it is
very hard to get a perfect name for the method. But I’m still open.

Maybe it would seem a better fit if the two were combined?

class Array
alias :oldselect :select
def select(*inds,&b)
s = if inds.empty? then self else inds.map {|i| at(i)} end
s = s.oldselect(&b) if b
s
end
end

arr = %w{ a b c d e }

arr.select {|s| s == “c”} # [“c”]
arr.select(0,2,4) # [“a”, “c”, “e”]
arr.select(0,2,4) { |s| s == “c” } # [“c”]

I think I would still like this better:

arr.at(0,2,4).select { |s| s == “c” }

David

···

On Thu, 19 Sep 2002, Yukihiro Matsumoto wrote:

In message “select and select” > on 02/09/19, dblack@candle.superlink.net dblack@candle.superlink.net writes:

–
David Alan Black | Register for RubyConf 2002!
home: dblack@candle.superlink.net | November 1-3
work: blackdav@shu.edu | Seattle, WA, USA
Web: http://pirate.shu.edu/~blackdav | http://www.rubyconf.com

[William_Djaja_Tjokro (William Djaja Tjokroaminata)]

Hi,

I like the name suggested by Nikodemus Siivola: “items”, and I’m
“voting” for it.

Regards,

Bill

···

===========================================================================
Yukihiro Matsumoto matz@ruby-lang.org wrote:

Hi,

In message “select and select” > on 02/09/19, dblack@candle.superlink.net dblack@candle.superlink.net writes:

I’d like to suggest (again, but the first time it was buried in
another thread that the new dual nature of “select” is kind of
awkward, and I’m wondering whether it’s been finalized.

Not yet, until 1.8.0 comes out. (don’t ask me when it will be.)
But considering the loooong thread we had without conclusion, it is
very hard to get a perfect name for the method. But I’m still open.

  					matz.

[Tom_Gilbert]

‘sample’?

Tom.

···

• Gavin Sinclair (gsinclair@soyabean.com.au) wrote:

By now, the problem of overloading #at have been made clear: arr.at(a) returns
an Object, not an Array. Also, I think the primary purpose of #at is to not
be overloaded: i.e. it does what it does without any overhead.

‘pick’ is being touted. I do not like it. I like ‘grab’, but I doubt others
will To me, ‘pick’ sounds exactly like ‘select’: you ‘pick’ values based on
some criteria. OTOH, ‘grab’ sounds like a very straightforward operation,
which ‘indices’ is.

–
.^. .-------------------------------------------------------.
/V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk |
/( )\ | Open Source/UNIX consultant | tom@linuxbrit.co.uk |
^^-^^ `-------------------------------------------------------’

[David_Alan_Black1 (David Alan Black)]

Hi –

From: dblack@candle.superlink.net

[We all know the context!]

Wouldn’t allowing #at to take multiple arguments be cleaner?

David

By now, the problem of overloading #at have been made clear:
arr.at(a) returns an Object, not an Array. Also, I think the
primary purpose of #at is to not be overloaded: i.e. it does what
it does without any overhead.

Yes, I think that’s the consensus. It’s sort of too bad to have
implementation internals governing the available names, but still, the
business of arr.at(num) returning one Object is pretty much a
deal-breaker.

‘pick’ is being touted. I do not like it. I like ‘grab’, but I
doubt others will To me, ‘pick’ sounds exactly like ‘select’: you
‘pick’ values based on some criteria. OTOH, ‘grab’ sounds like a
very straightforward operation, which ‘indices’ is.

Let me eulogize the late, lamented multi-arg #at What I liked
about it was that it flowed nicely into the arguments:

obj.at(2,5,6)
=> the values of this object that are at the indices 2,5,6

whereas all these verbs – in addition to being very close to select
– feel to me like they have a semantic brick missing:

obj.pick(2,5,6)
=> pick from this object 2,5,6
=> no, i mean pick from this object the things at 2,5,6

That’s why I liked #at; it felt like the best fit for what was
happening.

The other one that occurs to me in this regard, believe it or not, is
#sub, as in pronouncing a[3] “a sub 3”. But I imagine that’s much too
vexed and overload-fraught to work.

David

···

On Tue, 24 Sep 2002, Gavin Sinclair wrote:

----- Original Message -----

–
David Alan Black | Register for RubyConf 2002!
home: dblack@candle.superlink.net | November 1-3
work: blackdav@shu.edu | Seattle, WA, USA
Web: http://pirate.shu.edu/~blackdav | http://www.rubyconf.com

[Nikodemus_Siivola]

Hmm. grab makes me think: why not extend the semantics of grep?

a = [“foo”, “bar”, “foobar”, “barfoo”]
a.grep(1,3) # => [“bar”, “barfoo”]
a.grep(/foo/) # => [“foo”, “foobar”, “barfoo”]

h = { :a => “foo”, :b => “bar”, :c => “foobar”, :d => “barfoo” }
h.grep(:a,:c) # => [“foo”, “foobar”]
h.grep(/bar/) # => [“bar”, “foobar”, “barfoo”]

– Nikodemus

···

On Tue, 24 Sep 2002, Gavin Sinclair wrote:

I like ‘grab’, but I doubt others

[Yukihiro_Matsumoto2 (Yukihiro Matsumoto)]

Hi,

Maybe it would seem a better fit if the two were combined?

arr.select {|s| s == “c”} # [“c”]
arr.select(0,2,4) # [“a”, “c”, “e”]
arr.select(0,2,4) { |s| s == “c” } # [“c”]

Hmm, from this combination,

arr.select {|s| s == “c”}

can be considered as

arr.select() {|s| s == “c”}

i.e.

arr.select(*) {|s| s == “c”} # ???

Of course, current behavior has this too, but would combination
emphasize wierdness?

I think I would still like this better:

arr.at(0,2,4).select { |s| s == “c” }

I admit this is better in some aspect.

Does “at” takes multiple placement make you feel natural?
And is this natural for Hashes?

						matz.

···

In message “Re: select and select” on 02/09/20, dblack@candle.superlink.net dblack@candle.superlink.net writes:

[Tom_Sawyer]

“elements” would probably be “proper”. but “items” works well too. i’ll
throw in my +1. its more intuitive.

···

On Thu, 2002-09-19 at 13:41, William Djaja Tjokroaminata wrote:

Hi,

I like the name suggested by Nikodemus Siivola: “items”, and I’m
“voting” for it.

Regards,

Bill

Yukihiro Matsumoto matz@ruby-lang.org wrote:

Hi,

In message “select and select” > > on 02/09/19, dblack@candle.superlink.net dblack@candle.superlink.net writes:

I’d like to suggest (again, but the first time it was buried in
another thread that the new dual nature of “select” is kind of
awkward, and I’m wondering whether it’s been finalized.

Not yet, until 1.8.0 comes out. (don’t ask me when it will be.)
But considering the loooong thread we had without conclusion, it is
very hard to get a perfect name for the method. But I’m still open.

  					matz.

–
tom sawyer, aka transami
transami@transami.net

[ts1 (ts)]

Hmm. grab makes me think: why not extend the semantics of grep?

a = ["foo", "bar", "foobar", "barfoo"]
a.grep(1,3) # => ["bar", "barfoo"]

pigeon% ruby -e 'p [1,3,3].grep(3)'
[3, 3]
pigeon%

#grep use ===

Guy Decoux

[Bulat_Ziganshin]

Hello dblack,

Tuesday, September 24, 2002, 5:10:30 PM, you wrote:

Wouldn’t allowing #at to take multiple arguments be cleaner?

how about []? it seem natural:

a=[10,11,12]
a[1] # 11
a[[0,1]] # [10,11]
a[] #

and, i think, will be faster in the case of large indexing arrays:

a = (0…1000).to_a
index = (500…600).to_a
a[index]
a.pickup(*index)

and third - this will support and extend tradition of doing
meta-indexing through overloading of

···

–
Best regards,
Bulat mailto:bulatz@integ.ru

[HAL_9000]

It seems less natural for hashes.
I think I would prefer a method called ‘indices’ for
both Arrays and Hashes.

Oh, wait. That is what we had before.

Hal

···

----- Original Message -----
From: “Yukihiro Matsumoto” matz@ruby-lang.org
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, September 19, 2002 10:35 AM
Subject: Re: select and select

I think I would still like this better:

arr.at(0,2,4).select { |s| s == “c” }

I admit this is better in some aspect.

Does “at” takes multiple placement make you feel natural?
And is this natural for Hashes?

[David_Alan_Black1 (David Alan Black)]

Hi –

Hi,

Maybe it would seem a better fit if the two were combined?

arr.select {|s| s == “c”} # [“c”]
arr.select(0,2,4) # [“a”, “c”, “e”]
arr.select(0,2,4) { |s| s == “c” } # [“c”]

Hmm, from this combination,

arr.select {|s| s == “c”}

can be considered as

arr.select() {|s| s == “c”}

i.e.

arr.select(*) {|s| s == “c”} # ???

Of course, current behavior has this too, but would combination
emphasize wierdness?

Good question. I guess the arguments to select defaults to *(0…size),
which might be kind of weird. Or one could say that the arguments to
select are constraints on the selection, and that in the absence of
such constraints, everything is selected.

I think I would still like this better:

arr.at(0,2,4).select { |s| s == “c” }

I admit this is better in some aspect.

Does “at” takes multiple placement make you feel natural?
And is this natural for Hashes?

For Arrays I do like at(x,y,z). It seems natural to me. For Hashes,
I don’t think I usually refer to a value as being “at” a key… but it
sounds sort of right.

David

···

On Fri, 20 Sep 2002, Yukihiro Matsumoto wrote:

In message “Re: select and select” > on 02/09/20, dblack@candle.superlink.net dblack@candle.superlink.net writes:

–
David Alan Black | Register for RubyConf 2002!
home: dblack@candle.superlink.net | November 1-3
work: blackdav@shu.edu | Seattle, WA, USA
Web: http://pirate.shu.edu/~blackdav | http://www.rubyconf.com

[Joel_VanderWerf1 (Joel VanderWerf)]

Tom Sawyer wrote:

“elements” would probably be “proper”. but “items” works well too. i’ll
throw in my +1. its more intuitive.

Hm, “items”, “elements”, and “entries” all seem to fit in the same box
in my brain, but “entries” already has a meaning in Enumerable#entries.

Would it make sense to have

[0,1,2,3,4].entries #==> [0,1,2,3,4]

and at the same time

[0,1,2,3,4].items(1,3) #==> [1,3]

or would this be confusing?

What would the value of

[0,1,2,3,4].items

be? All, or nothing?

For me, the confusion is using two words that I don’t distinguish in
meaning for two slightly different, but related operations.

Would it be less confusing to extend the behavior of #entries, instead,
like this:

[0,1,2,3,4].entries(1,3) #==> [1,3]

or would this lead to the same problems as with overloading #select?

[Yukihiro_Matsumoto2 (Yukihiro Matsumoto)]

Hi,

···

In message “Re: select and select” on 02/09/25, “Bulat Ziganshin” bulatz@integ.ru writes:

Tuesday, September 24, 2002, 5:10:30 PM, you wrote:

Wouldn’t allowing #at to take multiple arguments be cleaner?

how about []? it seem natural:

Unfortunately, Hash key can be an array.

						matz.

[Julian_Fitzell]

dblack@candle.superlink.net wrote:

Hi –

Hi,

Maybe it would seem a better fit if the two were combined?

arr.select {|s| s == “c”} # [“c”]
arr.select(0,2,4) # [“a”, “c”, “e”]
arr.select(0,2,4) { |s| s == “c” } # [“c”]

Hmm, from this combination,

arr.select {|s| s == “c”}

can be considered as

arr.select() {|s| s == “c”}

i.e.

arr.select(*) {|s| s == “c”} # ???

Of course, current behavior has this too, but would combination
emphasize wierdness?

Good question. I guess the arguments to select defaults to *(0…size),
which might be kind of weird. Or one could say that the arguments to
select are constraints on the selection, and that in the absence of
such constraints, everything is selected.

I think I would still like this better:

arr.at(0,2,4).select { |s| s == “c” }

I admit this is better in some aspect.

Does “at” takes multiple placement make you feel natural?
And is this natural for Hashes?

For Arrays I do like at(x,y,z). It seems natural to me. For Hashes,
I don’t think I usually refer to a value as being “at” a key… but it
sounds sort of right.

Just to throw in my two cents… Using at() definitely feels better to
me.

Julian

···

On Fri, 20 Sep 2002, Yukihiro Matsumoto wrote:

In message “Re: select and select” >> on 02/09/20, dblack@candle.superlink.net dblack@candle.superlink.net writes:

–
julian@beta4.com
Beta4 Productions (http://www.beta4.com)

[William_Djaja_Tjokro (William Djaja Tjokroaminata)]

Hi,

I do not like that the Array “at” method is overloaded. I think currently
one advice in Ruby is to prefer “arr.at(i)” to “arr[i]” because in
“arr[i]” the intrepreter needs to check the type of i. If Array “at” is
overloaded like below, probably the corresponding C function will be
modified from

static VALUE rb_ary_at (VALUE ary, VALUE pos)

to

static VALUE rb_ary_at (VALUE self, VALUE args)

which means more overhead, as every time the Array “args” has to be
created, or to

static VALUE rb_ary_at (int argc, VALUE *argv, VALUE self)
{
    VALUE args;
    rb_scan_args (argc, argv, "0*", &args);
    ....

with the same effect.

Regards,

Bill

···

============================================================================
dblack@candle.superlink.net wrote:

I think I would still like this better:

arr.at(0,2,4).select { |s| s == “c” }

I admit this is better in some aspect.

Does “at” takes multiple placement make you feel natural?
And is this natural for Hashes?

For Arrays I do like at(x,y,z). It seems natural to me. For Hashes,
I don’t think I usually refer to a value as being “at” a key… but it
sounds sort of right.

[Nikodemus_Siivola]

How about?

some_array.items(3,6,7)
some_hash.items(:foo, “bar”, )

– Nikodemus

···

On Fri, 20 Sep 2002, Hal E. Fulton wrote:

It seems less natural for hashes.
I think I would prefer a method called ‘indices’ for
both Arrays and Hashes.

[HAL_9000]

Actually, I like this a lot.

I think this is my new favorite solution
to this non-problem.

Hal

···

----- Original Message -----
From: “Joel VanderWerf” vjoel@PATH.Berkeley.EDU
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, September 19, 2002 3:07 PM
Subject: Re: select and select

Would it be less confusing to extend the behavior of #entries, instead,
like this:

[0,1,2,3,4].entries(1,3) #==> [1,3]

or would this lead to the same problems as with overloading #select?