Re: Trigonometric "fractals" are dependent on bailout?

On Aug 25, 9:47 pm, David Makin <dave_ma...@xxxxxxxxxxx> wrote:
On 26 Aug, 03:33, David Makin <dave_ma...@xxxxxxxxxxx> wrote:





On 26 Aug, 03:03, David Makin <dave_ma...@xxxxxxxxxxx> wrote:

I tried z = sin(z)^2+c in Ultrafractal but couldn't reproduce the
behaviour you describe even with a bailout of 1e100 - is the program
you were trying using the FPU ?

Actually I re-read what you wrote, I'll rephrase the above -
Ultrafractal appears to render things as I would expect as you
increase the bailout.
I think the behaviour you describe simply stems from the fact that
unlike z^2+c where there is a magnitude of z beyond which all points
are "outside" this is not the case with trigonometric formulas so as
you increase the bailout more of the true inside is revealed - in fact
the only way to see the entire inside of a trigonometric (or other
periodic) formula would be to use an infinite bailout !
In other words yes - what gets rendered as "inside" is indeed
dependant on bailout.

I should also mention I finally observed the "bowl-shaped" areas of
inside that appear - they seem to be an error in calculation as you
say because their appearance varies with change of precision setting
in Ultrafractal.

That makes more sense. I just did an interesting little
experiment using a computer algebra package that can
run all sorts of mathematical formulas.

I chose a complex number in one of those "bowls", and
decided to observe it's numeric behavior under iteration.
I discovered they appear with a bailout as low as
100,000,000.

The point is: 0.60288526849445 + 0.65233649287795i.

Running this through the program yields the following
for the orbit:

z_0 = 0.60288526849445 + 0.65233649287795i
z_1 = 0.74968289743755 + 1.449888669631377i
z_2 = 0.7777041974371 + 5.169553715368868i
z_3 = -117.835060385819743 + 7729.342428579344291i

The next iteration gave a number so huge it filled up
several pages of screen, so it's obvious an overflow
would result.

What this shows is that you've got to be careful when
you're writing fractal programs! You have to check for
that overflow and make sure to color overflowed points
as "outside" (after all your bailout value is going to be
less than an overflow, ain't it?). And especially when the
overflow can happen with a bailout as small as 100,000,000.
On those trig fractals parts of the long spikes get cut off
due to the finite bailout, so you need to increase it to see
more of the spike if you want to explore that, and if
your program can't handle overflow, well, you're
screwed.

.

Relevant Pages

  • Re: Trigonometric "fractals" are dependent on bailout?
    ... Ultrafractal appears to render things as I would expect as you ... increase the bailout. ... that overflow and make sure to color overflowed points ... On those trig fractals parts of the long spikes get cut off ...
    (sci.fractals)
  • Re: Trigonometric "fractals" are dependent on bailout?
    ... Ultrafractal appears to render things as I would expect as you ... increase the bailout. ... that overflow and make sure to color overflowed points ... How would it run slower? ...
    (sci.fractals)
  • Re: Trigonometric "fractals" are dependent on bailout?
    ... try doing a calculation on a Pentium where overflow occurs on the first step and there are several more steps of calculation to do that involve the overflowed variable. ... >>> increase the bailout. ... > decided to observe it's numeric behavior under iteration. ...
    (sci.fractals)
  • Re: Trigonometric "fractals" are dependent on bailout?
    ... Actually I re-read what you wrote, ... Ultrafractal appears to render things as I would expect as you ... increase the bailout. ... are "outside" this is not the case with trigonometric formulas so as ...
    (sci.fractals)
  • Re: Trigonometric "fractals" are dependent on bailout?
    ... Actually I re-read what you wrote, ... Ultrafractal appears to render things as I would expect as you ... increase the bailout. ... are "outside" this is not the case with trigonometric formulas so as ...
    (sci.fractals)