scott wrote:
>> The Xmorphia web site apparently no longer exists. (Firefox tells me 
>> the server cannot be found.)
>>
>> As for "Science, 261, 189, 9 July 1993", what does that actually *mean*?
> 
> I dug around and found the equations in some PDF paper:
> 
> http://citeseer.ist.psu.edu/45188.html
> 
> They're on page two, and if you understood how the wave equation worked 
> then it should be pretty trivial to implement.

I see. So we have two chemicals, who's concentrations are governed by a 
new, more complicated pair of differential equations. Is that basically 
what it means?

> If I get time I would like to try and implement this in a pixel shader, 
> it's exactly the thing that GPUs are good at - performing the same code 
> on a huge number of different pixels.

More precisely, doing the some thing on a huge number of different 
pixels *independently*. ;-) All goes horribly wrong with lots of data 
dependencies. Still, for this, only neighboring pixels matter, so it 
should still move like lightning...

>> Later I found books such as The Beauty of Fractals and so on in the 
>> local library. Most of these consisted of miles of very advanced 
>> mathematics, most of it concerning the statistical properties of the 
>> coastline or something, and almost none of it to do with drawing these 
>> fantastic images that I longed for. The tiny selection of actual 
>> *pictures* present usually included only the vaguest suggestion of 
>> what the image *is*, and absolutely no suggestion about HOW TO MAKE 
>> IT. It was an extremely frustrating time...
> 
> I think I looked at a BASIC implementation and figured out what the core 
> loop was doing.

Me too.

When my dad purchased AMOS Professional (look it up), it came with a 
5-disk set of example programs. One was a thing that drew a litle 
jellyfish. (I now realise that this was the quadratic Julia set C = 0.26 
or so.) And another program drew the Mandelbrot set. Slowly. Very 
slowly. (Hello? Interpretted language on an 8 MHz CPU with no FPU?)

The program in question had lots of different colouring options and so 
forth. It took a while to dig out the core loop. I was especially 
surprised to find that it does all these complicated calculations, and 
then THROWS THE ANSWER AWAY and only counts HOW MANY TIMES it's been 
round the loop. That was quite unexpected!

> It was pretty cool that such a small simple bit of code 
> made such nice pictures.

Indeed yes! I found this to be quite amazing...

Eventually I came to know the Mandelbrot algorithm like the back of my 
hand. But how to make that "cubic Mandelbrot" you see in all the books? 
Various simple manipulations of the loop formula failed to produce the 
correct image. Compare:

   X = X*X - Y*Y + A
   Y = 2*X*Y + B

Obviously (?!), the correct formula is in fact

   X = X*X*X - 3*X*Y*Y + A
   Y = 3*X*X*Y - Y*Y*Y + B

I would never have thought of that in a million years. At least, not 
until I finally worked out what a "complex number" actually is and how 
to do arithmetic with them...

> I tried writing a version in assembler, it 
> worked but using fixed point numbers meant you could only zoom in about 
> 3 or 4 times until it all went wrong (no FPU on that machine!).

Took 2 hours at 320x240 on my Amiga 1200 with a 20 MHz FPU.

Took 6 hours on the RM Nimbus we had at school, with a 286 and a copy of 
RMBASIC. Damn that was slow...!

By the time I got to college, I was writing programs in Pascal with 
random dithering, multiple colouring algorithms and other bells and 
whistles.

[Other examples that came with AMOS included an L-system that draws 
plants. I never did figure out how. Later I saw a Blitz Basic example 
that uses the Chaos Game to draw lots of interesting stuff in realtime. 
On, and that's also where I first figured out how to do the infinite 
trails trick...]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message