🚀 go-pugleaf

In article <C5G3H7.DC6@world.std.com>, mrob@world.std.com (Robert P Munafo) writes:
> Another GIPPP status update, 
...
>I should also mention that Jay Hill and Yuval Fisher will be starting a GIPPP
>of their own, using a fundamentally different approach which promises to yield
>useful information.  To avoid confusion I will call mine "GIPPP #2 (Munafo)"
>and theirs "GIPPP #3 (Fisher/Hill)"; the first was "GIPPP #1 (Fisher)".
>
This is fine with us. 
 ...

|> The pixel count seems to decrease as precision increases, approaching a
|> limit around 8987087.  The higher count for low precision is probably the
|> result of roundoff error on a few points that are near the boundary of the
|> Mandelbrot Set but not actually in the Set itself. Iterating these points,
|> the roundoff error can result in a cycle (of very long period, probably);
|> without roundoff error the iterations would not repeat and would eventually
|> diverge.

Many of these points are chaotic, as I posted earier.  I gave a list of
points that can be expressed exactly in decimal (I know the machine is
binary, but I doubt there are any binary cases) which are chaotic.  I have
followed them for more than 8000000 iterations and found not the slightest
deviation from their wiggly path in C.  So the problem is how close to
the chaotic boundary do we have to be?  
> 
>It appears that the pixel count never really settles down on a specific value,
>but varies by one or two pixels depending on specifics of the floating-point
>precision used.  This is not surprising as the 44-bit results were simulated
>using a roundoff formula that does not perfectly mimic what hardware would do,
>and the 64-bit results were done on a different machine from the other results.

In the pixel counting method one evaluates a row of samples. Perhaps a 
Lyapunov exponent can be found that tells the divergence rate locally.
Can this help determine the proper cutoff in iterations?

|> 
|> Therefore, I think it is reasonable to put the error due to floating-point
|> roundoff at 3 pixels on an 8192x4096 grid, which comes out to 0.00000050.
|> 
This can be tested using the exact values for period 1, 2 and three areas
I posted.  I'll check into this.
...
|> 
|> NUMBER OF ITERATIONS:  Here the error can be estimated by running counts on
|> the same grid size with different iteration limits.  Some results:
|>   maxiter    escaped not_escaped error_estim
...
|>   1048575         79    35948768 0.0000033

This is in agreement with my result, carrying iter to 8388608.

|> These results are from iterating on a 16384x8192 grid; 
...
|> 
|> The GIPPP wlll use an iterations limit of 2147483648 (which is 2 to the 31st
|> power).  

While you are there, let it rip!

|> 
|> If anyone has comments on all this, let me know.  I'm getting ready to
|> start mailing the source code and instructions to participants.

There will be a week or so before GIPPP#3 is ready, can we get some of this 
in?

|> -- 
|> mrob's .sig #5 |Myers-Briggs: ESTJ or ENFJ (dep. on context)          -".'
|> collect all 5! |  NBCS 1.9.1: B3 c f g++ k r- s+ t+            	       -`'

Warmly,
Jay Hill
-- 
{ hilljr@jupiter.saic.com } begin writeln(3*ln(640320)/sqrt(163):17:15) end.
void main(){double sqrt(), y=1/sqrt(2.), a=.5, m=1,z; int n=0;
for(;m*=2,z=sqrt(1-y*y),y=(1-z)/(1+z),a=a*(1+y)*(1+y)-m*y,n<3;n++);
printf("17.15lf\n",1/a);}