Ruby is a nice and expressive language. Now my favourite Ruby site is
http://whytheluckystiff.net/articles/2003/08/04/rubyOneEightOh
I have a query about Ruby
Regards,
Srijit
srijit@yahoo.com schrieb im Newsbeitrag
news:221d8dbe.0308062037.2a5558f2@posting.google.com…
Ruby is a nice and expressive language. Now my favourite Ruby site is
http://whytheluckystiff.net/articles/2003/08/04/rubyOneEightOhI have a query about Ruby
- Like Python can I increase the maximum depth of Ruby Interpreter
Stack? This will help to calculate factorial(1000) recursively.
Without increasing the recursion limit, it will not possible to
calculate factorial(1000) recursively with Ruby 1.8 (Win 98). It is
possible to do the same with Python.
Hmmm… Calculating factorial recursively is really inefficient and after
all, Ruby is not a functional language although it has some features of
them
def fact1(n)
n == 1 ? 1 : n*fact1(n-1)
end
def fact2(n)
f = 1
for i in 1…n
f *= i
end
f
end
require ‘benchmark’
include Benchmark
N=700
bm do |x|
x.report(“recursive”) do
for n in 1…N
fact1 n
end
end
x.report(“iterative”) do
for n in 1…N
fact2 n
end
end
end
08:01:55 [ruby]: ruby fact.rb
user system total real
recursive 4.891000 0.015000 4.906000 ( 4.922000)
iterative 2.906000 0.000000 2.906000 ( 2.906000)
08:02:13 [ruby]:
Cheers
robert
srijit@yahoo.com schrieb im Newsbeitrag
news:221d8dbe.0308062037.2a5558f2@posting.google.com…Ruby is a nice and expressive language. Now my favourite Ruby site is
http://whytheluckystiff.net/articles/2003/08/04/rubyOneEightOhI have a query about Ruby
- Like Python can I increase the maximum depth of Ruby Interpreter
Stack? This will help to calculate factorial(1000) recursively.
Without increasing the recursion limit, it will not possible to
calculate factorial(1000) recursively with Ruby 1.8 (Win 98). It is
possible to do the same with Python.Hmmm… Calculating factorial recursively is really inefficient and
after
all, Ruby is not a functional language although it has some features of
themdef fact1(n)
n == 1 ? 1 : n*fact1(n-1)
enddef fact2(n)
f = 1for i in 1…n
f *= i
endf
Quite true. Plus, all the modern compilers for functional languages
use tail recursion optimization to convert the recursively expressed
code into a loop. So even with a functional language it isn’t
necessary to provide a stack depth proportional to the order of
recursion.
On Thursday, August 7, 2003, at 01:05 AM, Robert Klemme wrote:
end
require ‘benchmark’
include BenchmarkN=700
bm do |x|
x.report(“recursive”) do
for n in 1…N
fact1 n
end
endx.report(“iterative”) do
for n in 1…N
fact2 n
end
end
end08:01:55 [ruby]: ruby fact.rb
user system total real
recursive 4.891000 0.015000 4.906000 ( 4.922000)
iterative 2.906000 0.000000 2.906000 ( 2.906000)
08:02:13 [ruby]:Cheers
robert
srijit@yahoo.com schrieb im Newsbeitrag
news:221d8dbe.0308062037.2a5558f2@posting.google.com…Ruby is a nice and expressive language. Now my favourite Ruby site is
http://whytheluckystiff.net/articles/2003/08/04/rubyOneEightOhI have a query about Ruby
- Like Python can I increase the maximum depth of Ruby Interpreter
Stack? This will help to calculate factorial(1000) recursively.
Without increasing the recursion limit, it will not possible to
calculate factorial(1000) recursively with Ruby 1.8 (Win 98). It is
possible to do the same with Python.Hmmm… Calculating factorial recursively is really inefficient and
after all, Ruby is not a functional language although it has some
features of themdef fact1(n)
n == 1 ? 1 : n*fact1(n-1)
end
I am out of my depth here, but calculating factorial recursively is not
intrinsically inefficient, as it can be defined in a tail-recursive manner
(unlike fibonacci). It’s Ruby that’s inefficient by not “supporting”
tail-recursion optimisation, not the algorithm itself. That said, your
benchmarks (snipped) show a speed difference of only a factor of two
between iterative and recursive, which surprised me.
Further proof that Ruby does not truly have POLS!
Gavin
post.puts “”
Robert Klemme wrote:
srijit@yahoo.com schrieb im Newsbeitrag
news:221d8dbe.0308062037.2a5558f2@posting.google.com…Ruby is a nice and expressive language. Now my favourite Ruby site is
http://whytheluckystiff.net/articles/2003/08/04/rubyOneEightOhI have a query about Ruby
- Like Python can I increase the maximum depth of Ruby Interpreter
Stack? This will help to calculate factorial(1000) recursively.
Without increasing the recursion limit, it will not possible to
calculate factorial(1000) recursively with Ruby 1.8 (Win 98). It is
possible to do the same with Python.Hmmm… Calculating factorial recursively is really inefficient and after
all, Ruby is not a functional language although it has some features of
them
There were a few responses to Srijit’s question, all of them, it seems,
explaining why he was solving the problem the “wrong” way. None of the
responses (unless I missed it, in which case I apologize) actually
anaswered his original question.
So: can one increase the maximum depth of the Ruby interpreter stack?
James
“Gavin Sinclair” gsinclair@soyabean.com.au schrieb im Newsbeitrag
news:36655.203.185.214.34.1060244308.squirrel@webmail.imagineis.com…
I am out of my depth here, but calculating factorial recursively is not
intrinsically inefficient, as it can be defined in a tail-recursive
manner
(unlike fibonacci). It’s Ruby that’s inefficient by not “supporting”
tail-recursion optimisation, not the algorithm itself.
Hmmm, I don’t fully agree to you. Maybe nowadays one expects such
optimizations from a compiler / execution environment because they are
quite common. Nevertheless a method call (unless optimized away) imposes
a performance hit and thus defining a function recursively tends to be
slower.
The algorithm per se (i.e. effort measured as O calculus) does not differ
since the number of executions (either loopings or by recursions) stays
the same. So I’d like to refine your statement to “a recursive algorithm
is not intrinsically inefficient”. But an implementation has to consider
the environment (language, compiler, runtime) and I’d claim that on
average a recursive algorithm that can be transformed into an iteration
tends to be slower.
That said, your
benchmarks (snipped) show a speed difference of only a factor of two
between iterative and recursive, which surprised me.Further proof that Ruby does not truly have POLS!
What did you expect? 100? 
Regards
robert
Hi,
At Thu, 7 Aug 2003 21:59:20 +0900, james_b wrote:
So: can one increase the maximum depth of the Ruby interpreter stack?
It’s an OS issue. On Unixes, it’s done by ulimit command, but
I don’t know how it can be on Windows.
–
Nobu Nakada
nobu.nokada@softhome.net schrieb im Newsbeitrag
news:200308071406.h77E6TKa024307@sharui.nakada.kanuma.tochigi.jp…
Hi,
So: can one increase the maximum depth of the Ruby interpreter stack?
It’s an OS issue. On Unixes, it’s done by ulimit command, but
I don’t know how it can be on Windows.
Maybe here’s a misunderstanding: the problem was not the executable’s
stack but the stack of the Ruby thread. Or do Ruby’s threads use the
process’s stack? In that case I’d wonder how that was implemented…
Regards
robert
At Thu, 7 Aug 2003 21:59:20 +0900, > james_b wrote:
Hi,
At Fri, 8 Aug 2003 00:05:59 +0900, Robert Klemme wrote:
Maybe here’s a misunderstanding: the problem was not the executable’s
stack but the stack of the Ruby thread. Or do Ruby’s threads use the
process’s stack? In that case I’d wonder how that was implemented…
Yes. It is by setjmp()/longjmp(), read THREAD_SAVE_CONTEXT()
and rb_thread_restore_context() in eval.c for detail.
–
Nobu Nakada
nobu.nokada@softhome.net schrieb im Newsbeitrag
news:200308071520.h77FKeKa031765@sharui.nakada.kanuma.tochigi.jp…
Hi,
Maybe here’s a misunderstanding: the problem was not the executable’s
stack but the stack of the Ruby thread. Or do Ruby’s threads use the
process’s stack? In that case I’d wonder how that was implemented…Yes. It is by setjmp()/longjmp(), read THREAD_SAVE_CONTEXT()
and rb_thread_restore_context() in eval.c for detail.
Ah! Thanks!
robert
At Fri, 8 Aug 2003 00:05:59 +0900, > Robert Klemme wrote: