Well, can ya?

Post a reply to this message

Please put the question in the body of the article, not in the subject.
You shouldn't force people to re-scale their windows/tabs in order to see
the whole question. The subject should contain a short phrase about the
topic of the article.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

On Fri, 2 May 2003 09:52:29 -0400, "Greg M. Johnson" <gregj:-)565### [at] aolcom>
wrote:

>Well, can ya?
>
>
The FM (as I believe it is affectionately called) only mentions the Julia Set,
6.5.1.6 
or do you mean for a pattern ?

Regards
        Stephen

Post a reply to this message

Yes, can one make a function of sorts that duplicates the fractal algorithm
so that you'd have a pattern.

<mca### [at] aolcom (S McAvoy)> wrote in message
news:3eb2cfbd.98435893@news.povray.org...
> On Fri, 2 May 2003 09:52:29 -0400, "Greg M. Johnson"
<gregj:-)565### [at] aolcom>
> wrote:
>
> >Well, can ya?
> >
> >
> The FM (as I believe it is affectionately called) only mentions the Julia
Set,
> 6.5.1.6
> or do you mean for a pattern ?
>
> Regards
>         Stephen

Post a reply to this message

On Fri, 2 May 2003 17:44:52 -0700, "Greg M. Johnson" <gregj;-)565### [at] aolcom>
wrote:

>Yes, can one make a function of sorts that duplicates the fractal algorithm
>so that you'd have a pattern.
>
That's beyond me, though as Pov supports Mandelbrot and Julia sets I would think
that It might need to be patched to get other types. What type of Fractal do you
want? If you can do something with formulas then Fractint can give you lots.
http://spanky.triumf.ca/www/fractint/fractint.html
  
Andrew Coppin has been doing something with the Mandelbrot set that's not
available at his link :-{
Simen Kvaal did a beautiful Pickover attractor as well, I sigh with envy.

Regards
        Stephen

Post a reply to this message

S McAvoy <mca### [at] aolcom> wrote:
> That's beyond me, though as Pov supports Mandelbrot and Julia sets I would think
> that It might need to be patched to get other types.

  If POV-Ray supported recursive functions, then you could do them with
those.
  In fact, I implemented the Mandelbrot pattern as a recursive function
in a prototype version of POV-Ray 3.5, and it worked ok (it was acceptably
fast).

  It's a bummer the recursion support didn't completely work out.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

On 2 May 2003 20:16:46 -0400, Warp <war### [at] tagpovrayorg> wrote:


>
>  It's a bummer the recursion support didn't completely work out.
>
'Tis, you can get lost in fractals :-)

Regards
        Stephen

Post a reply to this message

Warp wrote:
>   If POV-Ray supported recursive functions, then you could do them with
> those.
>   In fact, I implemented the Mandelbrot pattern as a recursive function
> in a prototype version of POV-Ray 3.5, and it worked ok (it was acceptably
> fast).

What du you need recursion for?  Most fractals I know of
(Mandelbrot included) are computed in simple iterations,
as in (pseudo-code):

FOR Y-coordinates [of the entire fractal image]
   FOR X-coordinates
     WHILE conditions (i.e.: |Z| < 4 AND num_loops < max_loops)
       Iterate function (i.e.: Z = Z*Z + C [Mandelbrot])
     END
     Draw Pixel
   END
END

Any end-recursive function can be written as an iteration.
And in most cases the iterative version will be faster.

> It's a bummer the recursion support didn't completely work out.

That is true, however. ;)

g.

-- 
++++++++++++++++ http://www.psico.ch/ ++++++++++++++++

Post a reply to this message

In article <3eb3ac4c@news.povray.org>, gimi <gim### [at] psicoch> wrote:

> What du you need recursion for?  Most fractals I know of
> (Mandelbrot included) are computed in simple iterations,
> as in (pseudo-code):

You can make an iterative version of any recursive algorithm. However, 
the recursive version is often much simpler, and most fractals are 
mathematically defined as recursive because of the self-similar nature 
of fractals. At the time this was written, POV supported function 
recursion, but it still does not support loops, though you can imitate 
it using a long string of select() calls.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> In article <3eb3ac4c@news.povray.org>, gimi <gim### [at] psicoch> wrote:
>>What du you need recursion for?  Most fractals I know of
>>(Mandelbrot included) are computed in simple iterations,
>>as in (pseudo-code):
 >
> You can make an iterative version of any recursive algorithm. 

AFAIK this is only proven to be true for end-recursive algorithms
(though /many/ of the functions with a single recursion call can
be made end-recursive; but you will usually run into trouble if
the algorithm has multiple recursive calls).

> However, the recursive version is often much simpler, 

I agree, but it depends on how you look at it.  For people
not too familiar with the concept, an iterative function
is far easier to grasp. - And, as I mentioned before, it's
faster (and more efficient) in almost every case (Note that
I speak as a programmer here, not as a mathematician).

 > and most fractals are mathematically defined as recursive
 > because of the self-similar nature of fractals.

Can you elaborate on this kind of definition?
   I don't doubt this, I just think that one can as well
define them by iterative means ("As long as the conditions
are not fulfilled, do repeat...").
   However, I doubt that the relation between recursion and
self-similarity is as strong as you think.  Recursion is
often (ab-)used in order to make code look slick, when in
fact it isn't.

 > At the time this was written, POV supported function
> recursion, but it still does not support loops, though you can imitate 
> it using a long string of select() calls.

You mean "does not support loops" because there is no
proper stack to store (local) variables on?  In this
case, yes; but I'd prefer to solve (not "imitate") this
by implementing one - *if* I *really* need to... ;)


BTW, Christopher, what is your profession?


g.

-- 
9) Count the number of odd entries in the 100th row of
Pascal's triangle.
++++++++++++++++ http://www.psico.ch/ ++++++++++++++++

Post a reply to this message

gimi <gim### [at] psicoch> wrote:
> What du you need recursion for?

  POV-Ray functions do not support iterative control structures. The only
way of making a loop with functions is using recursion (as in any functional
language).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> You can make an iterative version of any recursive algorithm.

  Not true. It has been proved that there are recursive algorithms which
can't be implemented as iterative ones.
  (The difference between recursive and iterative algorithms is the
amount of memory they require: If the amount of memory required by the
algorithm is directly proportional to the amount of loops performed
(typically when you need a stack) then it's recursive. If the amount of
memory needed is constant, ie. doesn't depend on the amount of loops,
then it's iterative.)

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

Warp wrote:
> gimi <gim### [at] psicoch> wrote:
>>What du you need recursion for?
> 
>   POV-Ray functions do not support iterative control structures. The only
> way of making a loop with functions is using recursion (as in any functional
> language).

I see that now...  I have just tried to do that
fractal pigment function thing myself.  What a pity! :(

<sulk>
Now I just feel like never calling the POV-Ray language
a "programming language" again!!
</sulk> ;)

g.

-- 
Be very careful to never use Date::Manip twice in the same
program, or you could form a black hole! :-)
  -- Randal L. Schwartz
++++++++++++++++ http://www.psico.ch/ ++++++++++++++++

Post a reply to this message

Warp wrote:
>   POV-Ray functions do not support iterative control structures. The only
> way of making a loop with functions is using recursion (as in any functional
> language).

One more thing: Neither does it support conditional
structures like "#if ... #else ... #end" nor "(C ? A : B)",
AFAICS in the docs.  So, One would have to workaround this
using "select"; now I understand why Christopher mentioned
that..!


Thanks,

g.

-- 
++++++++++++++++ http://www.psico.ch/ ++++++++++++++++

Post a reply to this message

gimi <gim### [at] psicoch> wrote:
> One more thing: Neither does it support conditional
> structures like "#if ... #else ... #end" nor "(C ? A : B)",
> AFAICS in the docs.

  It does. It's called 'select'. 'select' is not a workaround, it's a
conditional structure.

  In theory adding the support for recursive function calling should
be easy (AFAIK you could simply remove the existing check which stops
the parsing if recursion is detected). The problem is that there seems
to be cases where it doesn't work ok, and fixing it to work always may
need severe work. For simple recursive functions it should work ok (at
least according to prototype tests).
  (I don't know if it would be a good idea to enable recursion in a patched
version of povray because of the detected instability, but a personal
version would be interesting to try.)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
> gimi <gim### [at] psicoch> wrote:
>>One more thing: Neither does it support conditional
>>structures like "#if ... #else ... #end" nor "(C ? A : B)",
>>AFAICS in the docs.
[And gimi also wrote:]
 >> So, One would have to workaround this using "select";
 >> now I understand why Christopher mentioned that..!
 >
>   It does. It's called 'select'. 'select' is not a workaround, it's a
> conditional structure.

Of course 'select' isn't a workaround in itself, but its
use as a conditional *structure*.  In a practical sense,
it is of course the same, but I would be careful not to
speak of a "structure" if it's in fact a function or
operator.  After all, there must be a reason why there
*are* conditional structures, and not just functions,
in programming languages!?

It is listed as a float function in the docs, and I
prefer to put it in the same drawer together with the
signum function, or even the '<=>' operator (Perl).

Or would you call "if ... then ... else" a function?

However, as far as POV-Ray is concerned, I don't know
how these different statements are implemented, nor if
it means anything whether it's called a function or
not...

>   In theory adding the support for recursive function calling should
> be easy (AFAIK you could simply remove the existing check which stops
> the parsing if recursion is detected). The problem is that there seems
> to be cases where it doesn't work ok, and fixing it to work always may
> need severe work. For simple recursive functions it should work ok (at
> least according to prototype tests).

I can't help getting the feeling that this POV-language
design or implementation is a little messy...

>   (I don't know if it would be a good idea to enable recursion in a patched
> version of povray because of the detected instability, but a personal
> version would be interesting to try.)

It certainly would!  OTOH, I think that this would better
be accompanied with some major redesign... - SCNR ;)


Have a nice weekend, I'm off...

gimi

-- 
"What right does Congress have to go around making laws
just because they deem it necessary?" -- Marion Barry
++++++++++++++++ http://www.psico.ch/ ++++++++++++++++

Post a reply to this message

gimi <gim### [at] psicoch> wrote:
> After all, there must be a reason why there
> *are* conditional structures, and not just functions,
> in programming languages!?

  Have you taken a look to a (purely) functional language?

  Purely functional languages do not have loops (or other things like
assignment to a variable).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
> gimi <gim### [at] psicoch> wrote:
>>After all, there must be a reason why there
>>*are* conditional structures, and not just functions,
>>in programming languages!?
> 
>   Have you taken a look to a (purely) functional language?

Yes, several.

>   Purely functional languages do not have loops (or other things like
> assignment to a variable).

True.  But we're talking POV-Ray, not Gofer nor Miranda...

And now that you mention it, I'd prefer "Pure Functional
POV-Ray" to what is available now..! ;)


Ok, now I'm gone. - Really! :)
(Unless I'm urged to get the final word again :D)

g.

-- 
++++++++++++++++ http://www.psico.ch/ ++++++++++++++++

Post a reply to this message

In article <3eb3dcbc@news.povray.org>, gimi <gim### [at] psicoch> wrote:

> AFAIK this is only proven to be true for end-recursive algorithms
> (though /many/ of the functions with a single recursion call can
> be made end-recursive; but you will usually run into trouble if
> the algorithm has multiple recursive calls).

By multiple recursions, you mean multiple recursions from a single 
level, like branches on a tree? Those aren't a problem. And you don't 
need them to be tail-recursive, though some languages can optimize those 
into a more efficient iterative form automatically.
Here's a very simple proof: computer processors are iterative. Recursive 
functions are mimicked by using a chunk of memory as a stack. Turing 
machines are iterative, and I've never heard of a recursive function 
that could not be represented with a Turing machine.


> > However, the recursive version is often much simpler, 
> 
> I agree, but it depends on how you look at it.  For people
> not too familiar with the concept, an iterative function
> is far easier to grasp. - And, as I mentioned before, it's
> faster (and more efficient) in almost every case

Conceptually, a recursive definition is the most accurate description of 
many fractals, including the Mandelbrot set. Fractals come out naturally 
from recursive functions, but not from iterative ones. For example, the 
Mandelbrot set's mathematical definition:
z -> z^2 + c


> (Note that I speak as a programmer here, not as a mathematician).

Well, mathematically, iteration is a subset of recursion. In practical 
computer programming though, recursion is done with stacks and iteration.


>  > and most fractals are mathematically defined as recursive
>  > because of the self-similar nature of fractals.
> 
> Can you elaborate on this kind of definition?

http://www.wikipedia.org/w/wiki.phtml?search=fractal&go=Go
http://www.everything2.com/index.pl?node=fractal
http://www.fractalwisdom.com/FractalWisdom/fractal.html
http://www.google.com/ (just search for anything involving "fractal" and 
"recursive" or "recursion")

More info:
http://mathworld.wolfram.com/MandelbrotSet.html
http://mathworld.wolfram.com/Fractal.html


>    I don't doubt this, I just think that one can as well
> define them by iterative means ("As long as the conditions
> are not fulfilled, do repeat...").

As I've said, the recursive version is often much cleaner and simpler. 
Just look at a few examples. The iterative version can be faster to 
compute (especially when function calls are computationally expensive), 
but is usually derived from a recursive mathematical definition.


>    However, I doubt that the relation between recursion and
> self-similarity is as strong as you think.  Recursion is
> often (ab-)used in order to make code look slick, when in
> fact it isn't.

Look at pretty much anything ever written about fractals. The 
relationship between fractals and recursion predates computers. 
Mandelbrot and Leibniz used the exact term "recursive self similarity" 
to describe these shapes. Recursion is very, very important in the 
mathematics of fractals.


> You mean "does not support loops" because there is no
> proper stack to store (local) variables on?  In this
> case, yes; but I'd prefer to solve (not "imitate") this
> by implementing one - *if* I *really* need to... ;)

It has nothing to do with a stack...you don't need that for loops anyway 
(though the POV-Ray function VM does have one). There is no loop 
construct for functions, making iterative functions very awkward to do. 
You can use a chain of select() calls, but that limits complexity, is 
inefficient, and can only be done when you have a fairly small known 
maximum number of iterations. (infinite loops aren't possible)


> BTW, Christopher, what is your profession?

College student. Majoring in computer science (applied mathmatics), 
minoring in physics.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <3eb3eab4@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Not true. It has been proved that there are recursive algorithms which
> can't be implemented as iterative ones.

Can you give an example of one of these?

How about a slight modification: You can make an iterative version of 
any recursive algorithm that can be executed by a computer.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <3eb3f054$1@news.povray.org>, gimi <gim### [at] psicoch> wrote:

> <sulk>
> Now I just feel like never calling the POV-Ray language
> a "programming language" again!!
> </sulk> ;)

That's a bit stupid. The function language is a small subset of the POV 
language. You can implement iterative and recursive algroithms in "the 
POV-Ray language", just not in functions.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> Can you give an example of one of these?

  I don't remember any. (Can quicksort be made iteratively?)

> How about a slight modification: You can make an iterative version of 
> any recursive algorithm that can be executed by a computer.

  There are algorithms which need a stack (which size is proportional
to the amount of loops done). These are recursive algorithms which can't
be done iteratively.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <3eb4673c@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> Christopher James Huff <cja### [at] earthlinknet> wrote:
> > Can you give an example of one of these?
> 
>   I don't remember any. (Can quicksort be made iteratively?)

Can you remember any special terms I could use to look for information 
on these?


> > How about a slight modification: You can make an iterative version of 
> > any recursive algorithm that can be executed by a computer.
> 
>   There are algorithms which need a stack (which size is proportional
> to the amount of loops done). These are recursive algorithms which can't
> be done iteratively.

They can be done iteratively, you just need a stack. The problem may be 
the definitions we're using: by "iterative" I mean an implementation 
using a loop instead of recursive functions. I'm talking about the 
implementation in a language that supports loop structures (not POV 
functions) and/or recursion (also not POV functions). You can use 
recursion, or you can use loops and stacks. A VM or CPU are iterative, 
though you could mathematically define them as recursive. I don't know 
if this is any kind of standard definition, so don't take this as expert 
counsel.

BTW, something semi-related: I've got a working VM for Amber and am 
working on the compiler, and recently made some improvements to 
Sapphire, which should see another preview release soon. (After this 
semester ends...I haven't had much time to work on either.)
Among the improvements: objects now use copy-on-write. Actually, a kind 
of dual copy-on-write: methods and data are copied separately, and at 
another level the members are copied when used individually. 
Unfortunately, this means 3 integers overhead for reference counts, so 
objects aren't very memory efficient if you have lots of unique objects. 
That's what Amber is for, though, Sapphire just isn't designed for 
efficiency (though it is still much faster than a directly interpreted 
language like POV script).

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> Can you remember any special terms I could use to look for information 
> on these?

  Nope.

> They can be done iteratively, you just need a stack.

  If you need a stack (which size depends on the amount of loops performed),
it's not iterative.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Christopher James Huff wrote:
> In article <3eb3dcbc@news.povray.org>, gimi <gim### [at] psicoch> wrote:
>>AFAIK this is only proven to be true for end-recursive algorithms
>>(though /many/ of the functions with a single recursion call can
>>be made end-recursive; but you will usually run into trouble if
>>the algorithm has multiple recursive calls).
> 
> By multiple recursions, you mean multiple recursions from a single 
> level, like branches on a tree? Those aren't a problem. And you don't 
> need them to be tail-recursive, though some languages can optimize those 
> into a more efficient iterative form automatically.
> Here's a very simple proof: computer processors are iterative. Recursive 
> functions are mimicked by using a chunk of memory as a stack. Turing 
> machines are iterative, and I've never heard of a recursive function 
> that could not be represented with a Turing machine.

You are absolutely right!  However, a Turing machine may run
forever, and it never runs out of memory.  Thus, the concept
of computable functions or numbers may be more appealing to
mathematicians than it is to computer programmers...

I have an example for you - The Ackermann function A(m, n):

for m = 0           A(0, n) = n+1
     m > 0, n = 0    A(m, 0) = A(m-1, 1)
     m > 0, n > 0    A(m, n) = A(m-1, A(m, n-1))

( http://www.kosara.net/thoughts/ackermann.html
or http://www-users.cs.york.ac.uk/~susan/cyc/a/ackermnn.htm )

Although it *is* of course a (Turing) computable function,
it is not primitive recursive, thus cannot be coded using
just for- or while-loops (or "iteratively").

( http://www-users.cs.york.ac.uk/~susan/cyc/p/primrec.htm
and http://mathworld.wolfram.com/PrimitiveRecursiveFunction.html )

>[...]
> Conceptually, a recursive definition is the most accurate description of 
> many fractals, including the Mandelbrot set. Fractals come out naturally 
> from recursive functions, but not from iterative ones. For example, the 
> Mandelbrot set's mathematical definition:
> z -> z^2 + c
 >[...]

This makes complete sense; however, a fractal does not
necessarily have to be the result of a recursive function
(as is also being stated on 
http://www.wikipedia.org/w/wiki.phtml?search=fractal&go=Go ,
the first link you mentioned).

And this definition lacks the exit condition, so neither a
turing machine nor a computer would ever return a result,
if the algorithm is implemented according to just the formula.
( - Would it be correct to call it non-computable in this case?)

>[...]
> As I've said, the recursive version is often much cleaner and simpler. 
> Just look at a few examples. The iterative version can be faster to 
> compute (especially when function calls are computationally expensive), 
> but is usually derived from a recursive mathematical definition.
 >[...]

Agreed.  Again, because I think as a programmer, I try to
keep it simple, fast and efficient.  So I avoid recursion,
if possible.

Thanks for the links; the first one
( http://www.wikipedia.org/w/wiki.phtml?search=fractal&go=Go )
is very interesting!


I see that a long time has passed since I learned about that
stuff; I forgot a lot...  Luckily, I get my programs running
properly mostly without thinking about Mr. Turing or primitive
recursion. :)


-- 
I'm pretty sure I'm seeing einsteinian light bending around
the local gravitational increase caused by programs that use
Date::Manip. :-) -- Randal L. Schwartz
++++++++++++++++ http://www.psico.ch/ ++++++++++++++++

Post a reply to this message

Hi,

You can "fake" iteration/recursion as in the following code (fix the line
wraps).  Best implemented with a scripting language to implement the include
file.

Bye,
Hans Mikelson

mandelbrot.inc

#declare mandloop18 = function(x,y,z,zr,zi) {18};
#declare mandloop17 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop18(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),17)}
;
#declare mandloop16 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop17(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),16)}
;
#declare mandloop15 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop16(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),15)}
;
#declare mandloop14 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop15(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),14)}
;
#declare mandloop13 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop14(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),13)}
;
#declare mandloop12 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop13(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),12)}
;
#declare mandloop11 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop12(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),11)}
;
#declare mandloop10 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop11(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),10)}
;
#declare mandloop09 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop10(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),9)};
#declare mandloop08 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop09(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),8)};
#declare mandloop07 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop08(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),7)};
#declare mandloop06 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop07(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),6)};
#declare mandloop05 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop06(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),5)};
#declare mandloop04 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop05(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),4)};
#declare mandloop03 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop04(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),3)};
#declare mandloop02 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop03(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),2)};
#declare mandloop01 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop02(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),1)};
#declare mandloop00 = function(x,y,z,zr,zi)
{select(zr*zr-zi*zi+2*zr*zi-4,mandloop01(x,y,z,zr*zr-zi*zi+x,2*zr*zi+z),0)};
#declare mandlbrot = function {mandloop00(x,y,z,0,0)*.05};

#declare T_Mandel =
texture {
    pigment {
        function {mandlbrot(x,y,z) }
        //turbulence .1
        //octaves 5
        //omega 1.1
        //lambda 2.0
      color_map {
        [0.00 color rgbt<.10, .00,  .00, .0>]
        [0.40 color rgbt<.80, .40,  .00, .0>]
        [0.50 color rgbt<.40, .00,  .00, .0>]
        [0.60 color rgbt<.80, .40,  .00, .0>]
        [1.00 color rgbt<.10, .00,  .00, .0>]
      }
    }
    finish {
        ambient 1.0
        diffuse 0.0
    }
}

#include "mandelbrot.inc"

camera {location <0,4,0>  look_at <0,0,0>}
global_settings { ambient_light rgb 1}
background { color rgb <0,0,0> }

plane { y, -1 hollow on texture {T_Mandel scale 1}}

Post a reply to this message

"Hans Mikelson" <hlj### [at] werewolfnet> wrote in
news:3eff4d42$1@news.povray.org: 

> Hi,
> 
> You can "fake" iteration/recursion as in the following code (fix the
> line wraps).  Best implemented with a scripting language to implement
> the include file.
...

An interesting idea...

This led me to read a little about the Mandelbrot set today.

Then I wrote a macro that uses your idea. (See my code below.)

Tor Olav



// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

// By Tor Olav Kristensen

#version 3.5;

#include "functions.inc"

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#macro MandelbrotFunction(MaxIterations)

  #local MaxDistance = 100;
  #local Functions = array[MaxIterations]
  #local Functions[0] = function(Cr, Ci, Zr, Zi) { 1 }
  #local Cnt = 1;
  #while (Cnt < MaxIterations)
    #local IterationValue = 1 - Cnt/(MaxIterations - 1);
    #local Functions[Cnt] =
      function(Cr, Ci, Zr, Zi) {
        select(
          f_r(Zr, 0, Zi) - MaxDistance,
          Functions[Cnt - 1](Cr, Ci, Zr*Zr - Zi*Zi - Cr, 2*Zr*Zi - Ci),
          IterationValue
        )
      }
    #local Cnt = Cnt + 1;
  #end // while

  function { Functions[MaxIterations - 1](-x, y, 0, 0) }

#end // macro MandelbrotFunction

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#declare MandelbrotTexture =
  texture {
    pigment {
//      mandel 60 exponent 2 interior 0, 1 exterior 1, 1
      MandelbrotFunction(60)
      color_map {
        [ 0.0 color rgb <1.0, 1.0, 1.0> ]
/*
        [ 0.2 color rgb <1.0, 0.7, 0.0> ]
        [ 0.4 color rgb <0.7, 0.5, 0.0> ]
        [ 0.6 color rgb <0.5, 0.3, 0.0> ]
        [ 0.8 color rgb <0.3, 0.0, 0.0> ]
*/
        [ 1.0 color rgb <0.0, 0.0, 0.0> ]
      }
    }
  }

plane {
  -z, 0
  texture {
    MandelbrotTexture
//    translate <-0.43, 0.3415, 0>
//    scale 800
    finish {
      ambient color rgb <1, 1, 1> // *4
      diffuse 0
    }
  }
}

camera {
  orthographic
  location -z
  right 1.33*x
  up y 
  direction z
  scale <1, 1, 1>*2.5
  translate -0.5*x
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

Post a reply to this message