New to Python: my impression v. Perl/Ruby

Ara.T.Howard · 22 January 2004 03:34

that sounds like a meta-physical question gavin

-a

···

On Thu, 22 Jan 2004, Gavin Sinclair wrote:

If I just want to do something 10 times, why should I involve ‘i’?

–

ATTN: please update your address books with address below!

===============================================================================

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
STP :: Solar-Terrestrial Physics Data | NCEI
NGDC :: http://www.ngdc.noaa.gov/
NESDIS :: http://www.nesdis.noaa.gov/
NOAA :: http://www.noaa.gov/
US DOC :: http://www.commerce.gov/

The difference between art and science is that science is what we
understand well enough to explain to a computer.
Art is everything else.
– Donald Knuth, “Discover”

/bin/sh -c ‘for l in ruby perl;do $l -e “print "\x3a\x2d\x29\x0a"”;done’
===============================================================================

gga · 22 January 2004 10:50

Dan Doel djd15@po.cwru.edu wrote in message

We probably shouldn’t use #each either, because you can override #each
to mean anything you want. Block creation also seems to be less expensive
than general object creation (or at least range creation), so the
performance
argument is incorrect.

That is indeed interesting! My idea that for loops were faster were
taken from some ruby online docs stating that as one of the
optimizations to do. I guess that was true of ruby1.6, perhaps. Or
the author was just talking about arrays, only.
If I turn the range into an array, the iteration itself is faster,
thou.
It seems for in and by itself is now slow in ruby1.8.1. And an even
bigger surprise is to find that a while loop performs the slowest
(almost twice as slow now!!!), when it is the one that is not
constructing anything but an integer. Hmm…
On the positive side, I guess this means there’s still quite some room
for optimizing these on a future ruby version.

def do_times(i)
n = 0

i.times do
    n = n + 1
end

end

def do_while(i)
n = 0
x = 0

while ( x <= i )
n = n + 1
x = x + 1
end
end

def do_each(i)
n = 0

i.each do
    n = n + 1
end

end

def do_for2(i)
n = 0

for k in i
    n = n + 1
end

end

def do_for(i)
n = 0

for k in (0..i)
    n = n + 1
end

end

max = 10000000
t1 = Time.new

do_times max

t2 = Time.new
puts "#times: ", t2 - t1

do_for max

t3 = Time.new
puts " for: ", t3 - t2

do_while max

t4 = Time.new
puts " while: ", t4 - t3

Construct these without timing it,

just to measure loop itself.

Without turning it into an array, for

is still slower. Maybe ruby iterates

thru ranges internally by turning them into

arrays first?

r = (0…max).to_a

t5 = Time.new

do_for2 r

t6 = Time.new

puts " for2: ", t6 - t5

do_each r

t7 = Time.new

puts " each: ", t7 - t6

######## i got
#times:
6.659
for:
6.86
while:
12.097
for2:
6.55
each:
7.44

Hmmm… I found the code for ranges in the ruby source and I sort of
understand why this would be so, but I cannot find the for or while
entry functions to trace why this could be.

Robert · 22 January 2004 10:50

“Joe Mason” joe@notcharles.ca schrieb im Newsbeitrag
news:slrnc0v1ru.pg0.joe@gate.notcharles.ca…

In article 20040121155809.22006.00000323@mb-m22.aol.com, GGarramuno
wrote:

for i in (0…i); something; end

to me has a bunch of advantages over times, step and the such. With
the above
construct you know that:
a) i has to be a number
b) i has to be positive for the loop to run
c) there IS a loop after all, as ‘for’ indicates a loop in pretty much
every
computer language.
d) it is more efficient as no blocks are created.
e) you can change the starting point (ie. not start at 0).

With i.times() I really don’t get any of the above. One can asume
that i.times
means a loop as it is perhaps a common construct in ruby.
But the truth is that i.times() also leaves room for that behavior to
not be
true. It could mean something else, too. It could be a fancy
benchmarking
object measuring the following block. Or any object with a times()
method, for
that matter.
Pre-assuming it is a loop to me is not as obvious as with a for loop.
And you always get the performance hit of opening a block, which is a
big no-no
to me when speed matters.

So, what you’re saying is, you don’t want to use Ruby’s features because
the same names could be used in other ways.

Even more: GGarramuno seems to suggest that a keyword or a name implies a
certain semantics while this connection is purely conventional. Sure,
many programming languages use “for” for looping, but this is nevertheless
a convention and thus must be learned. The meaning of “times” can be
learned the same way and the mnemonic isn’t really that bad, is it?

That’s a fair reason to not use Ruby, I suppose. Feel free not to. But
you’re not going to convince anyone else with that argument.

Definitely not.

robert

Zach_Dennis1 · 22 January 2004 21:44

GGaramuno,

but I had to read the line 2 or 3 times before I realized where times()
even was and where its block begun,

2 or 3 times? And you’re even a newbie!!! Amazing. Go look at some Perl code
and tell me if it takes you less then 2 or 3 times to translate to yourself
in your head.

Since you said you were a newbie to Ruby I’d like to state, “Don’t go
ranting off how ruby is this and ruby is that.” It just doesn’t make sense
to make those judgements because you use Python. Use both, then make a
judgement call. I did. I picked Ruby at the end. I dont’ expect you to,
but I’d expect you to use the language before judging it.

Zach

···

-----Original Message-----
From: GGarramuno [mailto:GGarramuno@aol.com]
Sent: Thursday, January 22, 2004 3:55 PM
To: ruby-talk ML
Subject: Re: New to Python: my impression v. Perl/Ruby

“John W. Kennedy” jwkenne@attglobal.net wrote in message
news:fpIPb.57035$OM2.16265939@news4.srv.hcvlny.cv.net…

tprime = (1 << n) - 1
test = 4
(n - 2).times {test = (test * test - 2) % tprime}
puts “(2**#{n})-1, #{tprime}, is prime” if test.zero?

Well, as a new user, that kind of constructs would scare me quite a
lot as an example of times() being used in real code.

Perhaps having been doing too much python has spoiled me, but I had to
read the line 2 or 3 times before I realized where times() even was
and where its block begun, unlike the previous clear examples using
do/end constructs.

Florian_Gross · 23 January 2004 03:05

GGarramuno wrote:

Hmmm… I found the code for ranges in the ruby source and I sort of
understand why this would be so, but I cannot find the for or while
entry functions to trace why this could be.

Remember that the for item in items construct really is only an alias
for items.each { |item| } and that its behavior can be changed by
overloading each. (!)

Regards,
Florian Gross

Ben_Giddings1 · 26 January 2004 15:21

Overall, I think it’s more Matz’ philosophy that you shouldn’t write
your Ruby code based on how you think the Ruby interpreter will
perform, but rather what seems most natural. Ruby is supposed to be
easy for the programmer, not for the interpreter.

Aside from that, there’s the philosophy of “don’t optimize code too
soon”. If a given loop is a problem when you’re done – then you can
figure out how to speed things up at that point. Choosing a less
intuitive loop construct because you have read it might be faster is
probably a mistake from a maintenance and readability point of view,
even if at this moment, it may be faster.

Ben

···

On Jan 22, 2004, at 05:50, GGarramuno wrote:

That is indeed interesting! My idea that for loops were faster were
taken from some ruby online docs stating that as one of the
optimizations to do. I guess that was true of ruby1.6, perhaps. Or
the author was just talking about arrays, only.
If I turn the range into an array, the iteration itself is faster,
thou.
It seems for in and by itself is now slow in ruby1.8.1. And an even
bigger surprise is to find that a while loop performs the slowest
(almost twice as slow now!!!), when it is the one that is not
constructing anything but an integer. Hmm…
On the positive side, I guess this means there’s still quite some room
for optimizing these on a future ruby version.

Rove_Monteux · 26 January 2004 15:34

Thats great stuff, Ben.

Specially the “Ruby is supposed to be easy for the programmer, not for
the interpreter.” is a great point, alone.

Nice one !

Cheers,

Rove Monteux

Ben Giddings wrote:

···

On Jan 22, 2004, at 05:50, GGarramuno wrote:

That is indeed interesting! My idea that for loops were faster were
taken from some ruby online docs stating that as one of the
optimizations to do. I guess that was true of ruby1.6, perhaps. Or
the author was just talking about arrays, only.
If I turn the range into an array, the iteration itself is faster,
thou.
It seems for in and by itself is now slow in ruby1.8.1. And an even
bigger surprise is to find that a while loop performs the slowest
(almost twice as slow now!!!), when it is the one that is not
constructing anything but an integer. Hmm…
On the positive side, I guess this means there’s still quite some room
for optimizing these on a future ruby version.

Overall, I think it’s more Matz’ philosophy that you shouldn’t write
your Ruby code based on how you think the Ruby interpreter will
perform, but rather what seems most natural.

Aside from that, there’s the philosophy of “don’t optimize code too
soon”. If a given loop is a problem when you’re done – then you can
figure out how to speed things up at that point. Choosing a less
intuitive loop construct because you have read it might be faster is
probably a mistake from a maintenance and readability point of view,
even if at this moment, it may be faster.

Ben

–
Rove Monteux
Systems Administrator

rove.monteux@fluid-rock.com

gga · 27 January 2004 09:45

Ben Giddings bg-rubytalk@infofiend.com wrote in message news:48F26B3C-5013-11D8-96DA-00039381462A@infofiend.com…

Overall, I think it’s more Matz’ philosophy that you shouldn’t write
your Ruby code based on how you think the Ruby interpreter will
perform, but rather what seems most natural. Ruby is supposed to be
easy for the programmer, not for the interpreter.

Well, most natural to me would likely be something in Spanish as it is
my native tongue, but I’m not holding my breath on ruby understanding
that

Speaking seriously, I love that philosophy (and it is also why I
prefer Ruby syntactically to python, where there is usually only one
-very strict- way of doing things).
But you are mistaken in thinking that I see times() and other integer
constructs more readable. I honestly don’t.
That’s why I prefer for/loops to all the other looping constructs as
to me they are both more natural and more readable down the line, as
was mentioned in the thread — to me it leaves less room to
interpretation and confusion. No confusion about writing the block
with brackets or not; much harder to place the loop in a single line;
much more clear to know where the loop limits are, it forces you to
use a looping variable, etc, etc. Performance is also a concern, but
it goes together with the other issues, too. It is never as simple a
decision as just choosing speed over all else. Of course, that is my
opinion and it does not have to be yours.

Yet, for an open philosophy of accepting different similar idioms, all
equivalent constructs have to perform at roughly equivalent speed.
That is also something to be admired in Perl.

If not, whether you admit it or not, you are already “encouraging” the
programmer into a way of writing code (not necessarily a bad idea,
mind you, but you might as well go all the way and put this info in
the docs and tutorials then).

Aside from that, there’s the philosophy of “don’t optimize code too
soon”.

True, but all languages have constructs that are faster than others.
And part of learning any language to me is also to know about those
constructs and make a habit out of them (and teaching those constructs
to others, too).
Thus, even in a fast language such as C++, for example, I find it best
to avoid writing i++ anywhere but when absolutely necessary, instead
choosing the cheaper ++i. Nobody would accuse me of premature
optimization for that, but it is a habit that comes in really useful
once you start dealing with iterators and the STL, for example. If
you learn that earlier in the language, you are better off than trying
to relearn it years down the line, imho.

Ruby still being a young and evolving language makes this still a
moving target, perhaps, but I’m sure that architecture decisions will
always keep favoring some constructs over others.

···

On Jan 22, 2004, at 05:50, GGarramuno wrote:

Laurent_Julliard4 · 27 January 2004 18:54

I suppose that is ‘home language’ or ‘native language’. Tongue should
be that in your mouth (I usually do the same error :=)

···

il 27 Jan 2004 01:40:56 -0800, GGarramuno@aol.com (GGarramuno) ha scritto::

Well, most natural to me would likely be something in Spanish as it is
my native tongue,

Gennady1 · 27 January 2004 18:59

gabriele renzi wrote:

il 27 Jan 2004 01:40:56 -0800, GGarramuno@aol.com (GGarramuno) ha
scritto::

Well, most natural to me would likely be something in Spanish as it is
my native tongue,

I suppose that is ‘home language’ or ‘native language’. Tongue should
be that in your mouth (I usually do the same error :=)

Actually, it is not an error. “Tongue” is quite acceptable replacement
for “language” in expression “native language”.

Gennady.

HAL_9000 · 27 January 2004 19:03