Hello.  I am rather new to the POV programming world, and hope this is an
intelligent question.  My current project is to write a series of user
defined macros that would give all "LOGO turtle" graphics in 3D.  The math
to define the <xyz> position and heading, pitch and bank is easy enough, but
trying to recurse (call a macro from itself) quickly results in an error
from the symbol tables being too deeply nested.  I have a fast Athlon with 1
gig RAM and over 200 gigs free disk space, so memory not a problem.  Is
there any reasonably easy way to recompile POV-Ray to allow MUCH deeper
nesting or should I just forget about elegant code and reiterate while
running my own stack with a global index and arrays?  Thanx


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.590 / Virus Database: 373 - Release Date: 2/16/2004

Post a reply to this message

Recursive function calls are a burden in practically all programming
languages because they have quite a lot of overhead (the exception
being the tail recursion optimization in some languages when the
recursive call is made properly). Recursion is usually also considerably
slower than doing it iteratively.

  While it's proven that certain algorithms can only be done recursively
(ie. using a recursion stack) and cannot be done iteratively, you should
still try.
  If you need a stack, then you'll have to use an array. The problem is,
of course, that arrays are fixed in size (ok, you can increase the
size of an array by creating a bigger array and copying the contents
of the old one to the new one, but that's some overhead as well).

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

I am rather thinking the best way is to write an "interpreter" in POV-SDL,
and let it read instructions from a file written in parallel from a task
running on another machine on my LAN.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.590 / Virus Database: 373 - Release Date: 2/16/2004

Post a reply to this message

"Recursion is usually also considerably slower than doing it iteratively."

Going a bit off-topic here, but this affirmation is true if slightly
misleading -- recursive programming is often slower than iterative
programming, but unless there's a serious bug involved they're always the
same order, whether you recourse or iterate. That is, if you have an
iterative function that has an execution time of A*(input dimension) for
some constant A, then the recursive version will be B*(input dimension) with
B > A (both linear, but recursion time growing quicker), as opposed to, say
B*(input dimension)^2 (the recursive version being showing quadratic growth
instead of linear).

"While it's proven that certain algorithms can only be done recursively"

Quicksort is a case, if I'm not mistaken. In fact I think it's thought of as
massively recursive, whatever that means


"Warp" <war### [at] tagpovrayorg> wrote in message
news:4084e27b@news.povray.org...
>   Recursive function calls are a burden in practically all programming
> languages because they have quite a lot of overhead (the exception
> being the tail recursion optimization in some languages when the
> recursive call is made properly). Recursion is usually also considerably
> slower than doing it iteratively.
>
>   While it's proven that certain algorithms can only be done recursively
> (ie. using a recursion stack) and cannot be done iteratively, you should
> still try.
>   If you need a stack, then you'll have to use an array. The problem is,
> of course, that arrays are fixed in size (ok, you can increase the
> size of an array by creating a bigger array and copying the contents
> of the old one to the new one, but that's some overhead as well).
>
> -- 
> plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
> sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
> density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
> <1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Doppelganger <ped### [at] netcabopt> wrote:
> unless there's a serious bug involved they're always the
> same order

  Same order, of course, but the constant factor is bigger for recursive
programs, which means that it will be slower than the iterative one.

> "While it's proven that certain algorithms can only be done recursively"

> Quicksort is a case, if I'm not mistaken. In fact I think it's thought of as
> massively recursive, whatever that means

  In the case of quicksort you know how deep your iteration stack will
at maximum be before you start sorting. This means that you can allocate
a properly sized stack (which size keeps fixed during the whole execution
of the algorithm) and use it to make an implementation without recursive
function calls.
  Since the stack can be allocated at the beginning and its size doesn't
need to be modified during the algorithm, and since the algorithm can
then be implemented without using recursive function calls (just using
this stack to "emulate" recursiveness), its speed should be possible
to be made equivalent to an iterative algorithm.

  In this regard quicksort is not one of the worst algorithms if
recursion is a big problem. There are, however, algorithms where
there's no way to predict how deep the recursion stack will be,
and those are more problematic.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

I stand corrected :)


"Warp" <war### [at] tagpovrayorg> wrote in message
news:411e9bc0@news.povray.org...
> Doppelganger <ped### [at] netcabopt> wrote:
> > unless there's a serious bug involved they're always the
> > same order
>
>   Same order, of course, but the constant factor is bigger for recursive
> programs, which means that it will be slower than the iterative one.
>
> > "While it's proven that certain algorithms can only be done recursively"
>
> > Quicksort is a case, if I'm not mistaken. In fact I think it's thought
of as
> > massively recursive, whatever that means
>
>   In the case of quicksort you know how deep your iteration stack will
> at maximum be before you start sorting. This means that you can allocate
> a properly sized stack (which size keeps fixed during the whole execution
> of the algorithm) and use it to make an implementation without recursive
> function calls.
>   Since the stack can be allocated at the beginning and its size doesn't
> need to be modified during the algorithm, and since the algorithm can
> then be implemented without using recursive function calls (just using
> this stack to "emulate" recursiveness), its speed should be possible
> to be made equivalent to an iterative algorithm.
>
>   In this regard quicksort is not one of the worst algorithms if
> recursion is a big problem. There are, however, algorithms where
> there's no way to predict how deep the recursion stack will be,
> and those are more problematic.
>
> -- 
> plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
> sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
> density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
> <1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message