Arbitrary indexes

ruby-talk
1

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 is itself a method call (the "" method) as is a = 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.

···

From: Jason Nordwick [mailto:jason@adapt.com]

2

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 is itself a method call (the "" method) as is a = 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.

3

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

4

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

···

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

5

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

6

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

7

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.

I take all criticism for not supporting criticism on ruby.
Well I just think your attidue is not very useful, have you already made
some suggestions to ISO for adding features to C?
Or to ANSI for some additional features for Ada?

Ruby gives you enourmous power to extend base classes and much more, I fail
to see how this is a problem, a good toolbox, teaching people to use
conventions, documenting your toolbox, project management etc. etc. is
beyond the responsability of Ruby.

That all said, who knows if Matz likes your ideas...

Cheers
Robert

-j

···

On 9/15/06, Jason Nordwick <jason@adapt.com> wrote:

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
>

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

8

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}
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>

···

On 9/15/06, Jason Nordwick <jason@adapt.com> wrote:

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

9

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

10

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

11

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

12

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