Asp Forum - Re: arbitrary indexes

Gavin Kistner

9/14/2006 2:22:00 PM

From: Jason Nordwick [mailto:jason@adapt.com]
> Oh course. That's (now) blindingly obvious. I don't think there is much I
> can do to prevent all the value_at calls. I can't really lay out my arrays
> differently to get better continuity, and I seem to be using value_at
> almost every line where there is a decent amount of computation. Overall,
> arbitrary indexing seems far more useful than range based indexing using
> the [start,len] notation. After all, there is already start../...stop
> notation. Too bad I guess.

It sounds to me like you're saying "Man, my program is slow because of all the #values_at method calls that I'm doing. I wish that I could use [1,3,5] to do what I want, because indexing like that would be faster."

What you may not realize is that a[x] is itself a method call (the "[]" method) as is a[x] = 1 (the "[]=" method). So, there wouldn't be any inherent speed gain in changing arrays to do what you want them too.

If you already realized this, sorry for the noise.

10 Answers

Jason Nordwick

9/14/2006 2:38:00 PM

I don't believe I said anything of the sort.

Of course I don't believe that going from value_at to [] would make my code faster, just that it would make it more compact. We started using Ruby for some moderately heavy numerics, and I haven't been able to be as concise (or productive) as I wish (or thought from what others told me).

This doesn't necessarily reflect poorly on Ruby in its entirely, just I think we found a problem domain in the dead spot of the language.

-j

Gavin Kistner wrote:
> From: Jason Nordwick [mailto:jason@adapt.com]
>> Oh course. That's (now) blindingly obvious. I don't think there is much I
>> can do to prevent all the value_at calls. I can't really lay out my arrays
>> differently to get better continuity, and I seem to be using value_at
>> almost every line where there is a decent amount of computation. Overall,
>> arbitrary indexing seems far more useful than range based indexing using
>> the [start,len] notation. After all, there is already start../...stop
>> notation. Too bad I guess.
>
> It sounds to me like you're saying "Man, my program is slow because of all the #values_at method calls that I'm doing. I wish that I could use [1,3,5] to do what I want, because indexing like that would be faster."
>
> What you may not realize is that a[x] is itself a method call (the "[]" method) as is a[x] = 1 (the "[]=" method). So, there wouldn't be any inherent speed gain in changing arrays to do what you want them too.
>
> If you already realized this, sorry for the noise.
>

MonkeeSage

9/15/2006 8:43:00 AM

Jason Nordwick wrote:
> Of course I don't believe that going from value_at to [] would make
> my code faster, just that it would make it more compact. We started
> using Ruby for some moderately heavy numerics, and I haven't been
> able to be as concise (or productive) as I wish (or thought from what
> others told me).

So define your own implementation! That's one of the things that makes
working in ruby so productive.

class Array
def [](*args)
if args.size == 1
at(*args)
else
values_at(*args)
end
end
end

a = [1,2,3,4,5,6,7,8,9]
p a[2] # => 3
p a[2,4,6] #=> [3, 5, 7]

Regards,
Jordan

Farrel Lifson

9/15/2006 9:05:00 AM

On 15/09/06, MonkeeSage <MonkeeSage@gmail.com> wrote:
> Jason Nordwick wrote:
> > Of course I don't believe that going from value_at to [] would make
> > my code faster, just that it would make it more compact. We started
> > using Ruby for some moderately heavy numerics, and I haven't been
> > able to be as concise (or productive) as I wish (or thought from what
> > others told me).
>
> So define your own implementation! That's one of the things that makes
> working in ruby so productive.
>
> class Array
> def [](*args)
> if args.size == 1
> at(*args)
> else
> values_at(*args)
> end
> end
> end
>
> a = [1,2,3,4,5,6,7,8,9]
> p a[2] # => 3
> p a[2,4,6] #=> [3, 5, 7]
>
> Regards,
> Jordan
>
>
>

Be careful though as you've broken some functionality as Array#[] can
take two arguments to return the y elements starting at index x.
[1,2,3,4,5,6,7][2,3] = [3,4,5]
Your modification would make
[1,2,3,4,5,6,7][2,3] = [3,4]

Farrel

MonkeeSage

9/15/2006 9:37:00 AM

Farrel Lifson wrote:
> Be careful though as you've broken some functionality as Array#[] can
> take two arguments to return the y elements starting at index x.
> [1,2,3,4,5,6,7][2,3] = [3,4,5]
> Your modification would make
> [1,2,3,4,5,6,7][2,3] = [3,4]

Yup, caveat emptor. Jason indicated that he was aware of the default
functionality though, so I assume he would be mindful of that gotcha.

Also, I see that my code above wouldn't work for one of his desired
uses:

a=[0,11,22,33,44,55]
b=[1,3]
a[b] # => [11, 33]

For that to be supported as well, the implementation would have to be
something like:

class Array
def [](*args)
if args.size == 1
if args.at(0).instance_of?(Array)
values_at(*args.at(0))
else
at(*args)
end
else
values_at(*args)
end
end
end

Regards,
Jordan

Jason Nordwick

9/15/2006 3:12:00 PM

In my original message, I asked for people not to answer "change the behavior of [] yourself" beause changing the base semantics of indexing is likely to play havoc with the other developers (we have about 5 writing with the same code) or possibly another package we import (this type of collision has already happened once to us on a relatively small project, and we had to turn off an couple inlined C method because of it).

"Change the base behavior of this builtin" and "write it in C" have become the chief dodges of the Ruby community to any substantive criticism. I now have a file I load that includes base extensions to the language that should probably be supplied by the system, and that files seems to just keep growing. Ruby is become less productive of a langauge because of it because I spend more time either searching for these functions like "values_at", writing extentions to [] or such, and then debugging them when the interactions with other parts of the system fail.

-j

MonkeeSage wrote:
> Jason Nordwick wrote:
>> Of course I don't believe that going from value_at to [] would make
>> my code faster, just that it would make it more compact. We started
>> using Ruby for some moderately heavy numerics, and I haven't been
>> able to be as concise (or productive) as I wish (or thought from what
>> others told me).
>
> So define your own implementation! That's one of the things that makes
> working in ruby so productive.
>
> class Array
> def [](*args)
> if args.size == 1
> at(*args)
> else
> values_at(*args)
> end
> end
> end
>
> a = [1,2,3,4,5,6,7,8,9]
> p a[2] # => 3
> p a[2,4,6] #=> [3, 5, 7]
>
> Regards,
> Jordan
>
>

Jason Nordwick

9/15/2006 3:15:00 PM

given that Array[int,int] is already taken syntax, Array[Array] is perfectly acceptable syntax for arbitrary list indexing, even if the immediate form might look a little ugly: a[[1,3,4,5,7]].

-j

MonkeeSage wrote:
> Farrel Lifson wrote:
>> Be careful though as you've broken some functionality as Array#[] can
>> take two arguments to return the y elements starting at index x.
>> [1,2,3,4,5,6,7][2,3] = [3,4,5]
>> Your modification would make
>> [1,2,3,4,5,6,7][2,3] = [3,4]
>
> Yup, caveat emptor. Jason indicated that he was aware of the default
> functionality though, so I assume he would be mindful of that gotcha.
>
> Also, I see that my code above wouldn't work for one of his desired
> uses:
>
> a=[0,11,22,33,44,55]
> b=[1,3]
> a[b] # => [11, 33]
>
> For that to be supported as well, the implementation would have to be
> something like:
>
> class Array
> def [](*args)
> if args.size == 1
> if args.at(0).instance_of?(Array)
> values_at(*args.at(0))
> else
> at(*args)
> end
> else
> values_at(*args)
> end
> end
> end
>
> Regards,
> Jordan
>
>

Rick DeNatale

9/15/2006 7:53:00 PM

On 9/15/06, Jason Nordwick <jason@adapt.com> wrote:
> In my original message, I asked for people not to answer "change the
> behavior of [] yourself" beause changing the base semantics of indexing
> is likely to play havoc with the other developers (we have about 5 writing > with the same code) or possibly another package we import (this type of
> collision has already happened once to us on a relatively small project, and > we had to turn off an couple inlined C method because of it).
>
> "Change the base behavior of this builtin" and "write it in C" have
> become the chief dodges of the Ruby community to any substantive
> criticism.

Just because Ruby allows you to change base classes, doesn't mean that
you should. In most cases, you are right, you shouldn't.

However, what's the alternative in other languages?

And "write it in C" is only opinion held by a few, most performance
problems are amenable to finding better algorithms.

And where's the "substantive criticism" in your question. As I
understand it you wanted "to find a simpler way than i.map{|x|v[x]}
which seem like an aweful lot of syntax."

So v.values_at(i) was suggested. Seems like a lot less syntax to me.
BUt your 'criticism' became it wasn't compact enough. Well if you
want to you can use method_alias so you can say something like:

v.va i

more compact at the price of clarity, and although you're adding to
Array in order to do this, it's probably fairly safe in this case.

On the other hand, it's probably just better to use the standard
values_at method for the sake of you and your team, might as well
LEARN ruby while you're using it.

> I now have a file I load that includes base extensions to the language that > should probably be supplied by the system, and that files seems to just
> keep growing. Ruby is become less productive of a langauge because of it
> because I spend more time either searching for these functions like
> "values_at", writing extentions to [] or such, and then debugging them
> when the interactions with other parts of the system fail.

This reminds me of the old joke about the guy who goes to the doctor
and says "It hurts when I do this, Doc!", and the doctor says "Don't
do that."

A mature development team would go back through those extensions and
remove/rework them as they learned, the same thing should be said of
our own code, it's called refactoring. My mother would call it
keeping the house clean.

I'd turn this around and ask if maybe you're preventing yourself from
becoming a productive Ruby programmer by resisting learning the
language. Languages per se aren't productive, it's the combination of
programmer and language.

If Ruby isn't the language for you, then just use something else.
Since the goal of Ruby is to make programmers happy, if some
programmers are happier using another language, that should be fine.

But if you're looking for a language which predicts your every whim, I
suspect that you are going to have to design, implement, and debug it
yourself. <G>

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denh...

MonkeeSage

9/15/2006 8:19:00 PM

Jason Nordwick wrote:
> In my original message, I asked for people not to answer
> "change the behavior of [] yourself"

Right, and then you said started complaining that the default behavior
should be what you want instead of what it is:

"Overall, arbitrary indexing seems far more useful than range based
indexing using the [start,len] notation. After all, there is already
start../...stop notation. Too bad I guess."

And that you just couldn't be as productive otherwise:

"We started using Ruby for some moderately heavy numerics, and I
haven't been able to be as concise (or productive) as I wish (or
thought from what others told me)."

In fact you said that it was a "problem domain".

So I thought you had changed your mind about overridding the default
behavior. It instead seems that you were just asking for the
impossible: to change the default behavior without changing the default
behavior. So I guess the criticism wasn't very substantive after all.

Regards,
Jordan

MonkeeSage

9/15/2006 8:29:00 PM

Jason Nordwick wrote:
> given that Array[int,int] is already taken syntax, Array[Array] is
> perfectly acceptable syntax for arbitrary list indexing, even if
> the immediate form might look a little ugly: a[[1,3,4,5,7]].

The second implementation I posted allows for that. But you should
realize that an array and an argument list are not quite the same
thing, since arrays can be arguments in the argument list. How would
ruby know (on any given method) whether you meant method(array, int)
[an array as an argument in the list] or method(array) [array as the
argument list]. You can always implement the functionality yourself
when you have a specific criterion on which to differentiate between
the two (as I did in the second implementation above, viz., one
argument which is an instance of array -- but that is only a convention
I've supplied; not something that ruby could know automatically).

Regards,
Jordan

MonkeeSage

9/15/2006 11:45:00 PM

MonkeeSage wrote:
> The second implementation I posted allows for that.

You could also do it like this, and preserve the default functionality
but add the arbitrary indexing via passing an array:

class Array
alias :_sqr_accsr :[]
def [](*args)
if args.size == 1 and
args.at(0).instance_of?(Array)
values_at(*args.at(0))
else
_sqr_accsr(*args)
end
end
end

a = [1,2,3,4,5,6,7,8,9]
p a[2] # => 3
p a[2,4] # => [3, 4, 5, 6]
p a[[2,4,6]] # => [3, 5, 7]

The point is: _use_ the language to your advantage, don't fight against
it.

Regards,
Jordan

comp.lang.ruby

Re: arbitrary indexes

Gavin Kistner

Jason Nordwick

MonkeeSage

Farrel Lifson

MonkeeSage

Jason Nordwick

Jason Nordwick

Rick DeNatale

MonkeeSage

MonkeeSage

MonkeeSage

x Login to ForumsZone