🚀 go-pugleaf

In article <1993Apr12.230442.6292@ast.saic.com>, hilljr@jupiter.saic.com (Jay R. Hill) writes:
...
|> 
|> Yuval and I have modified the GIPPP program so it now
|> computes an upper and lower limit to the MSet area.
|> The code is based in part on work of Marc Parmets and
|> information in Appendix D of the Science of Fractal Images.
|> It depends on accurate determination of the period at
|> any sample point.  The program will be ready shortly.
|> We plan to have about 120 segments, each square, which
|> when added together, will give the desired area estimates.
|> Preliminary results show the upper bound is 1.60986378
|> and the lower bound is 1.49713877. Since we know the 
|> contribution for each period and the precise value for
|> periods 1, 2, and 3, the lower bound can be adjusted
|> to 1.50403787.  The difference was taken from the 
|> 'inbetween' area which the distace estimator method
|> always has.  Please watch for Yuvals posting when it
|> is ready. We figure each subarea will require about
|> 12 to 24 hours on a workstation.
|> 

The method uses divide and conquor. The distance estimators 
tell us if a square is all in M or non of M is in the
square. If so we are done with the square, count its area.
The distance estimators require correct ID of the period.
We shall sum the areas by period.  If only part of a square 
is in or part out, then we subdivide recursively until some 
depth is attained.  Each depth level is another factor of
three computing.  When the depth is 19 or 20 we will quit.
The pixel counting method is integrated into GIPPP#3. The
efficiency of divide and conguor (which requires distance
estimator methods) may more than offset the extra computation
the distance estimation takes.  As you can see there advantages
to our method.  The basic mathematics are written up in 
Fractal Images where Yuval contributed a section. He plans
another paper in which the refinements used in GIPPP#3 will
be discussed.  The status is there is one more tweek he
wants to make on the period determination.  If an error is 
made in that determination, the lower bound is wrong.  So
far this has been only barley detectable (10^-6 or less)
but Yuval is a mathematician... ;^).  

The program is nearly ready. The complete source will be 
on ftp, as before.  The method of use will be as it was 
in GIPPP#1 (Fisher). EMail a message "join" and get back
a C program. Compile it, run it piping the result to mail.
The results will be tabulated.  Stats on the lower bound,
upper bound, and in-between areas will be collected by 
period.  I'm looking foreward to you on the net to join
us in this calculation.

Please let me know if you can help us with this. I need to
know how many MFlop-hrs you will likely have in the next 
several weeks at nice 19.  I'm trying to determine to what
depth we can take this.  Beta tests will be made later this
week. Thanks.

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);}