FOTD 29-04-04 (Beyond the Limit [5])
FOTD -- April 29, 2004 (Rating 5) Fractal visionaries and enthusiasts: Today's image has been named "Beyond the Limit". But don't succumb to skeptic's panic. We are not headed into the supernatural. Since fractals have no limit of their own, the limit mentioned in the name is the resolution limit of the math routine used by the program to generate the image. The diagonal smearing visible in the image is the first sign of resolution breakdown. I needed to include the mathtolerance entry in the parameter file to be sure that the image is drawn at the correct magnitude on all machines at all screen resolutions. When this is done, we find ourselves with a rather pleasant star-like image, which, if it were not afflicted with resolution breakdown, would rate a 7. As it is, I can rate the image no higher than a 5. The render time of 6 minutes makes the overall value an 82. Don't even think of checking the midget at the center of the image. Nothing but colored splotches are down there. The midget needs a few more magnitudes of resolution before it will reveal itself. The best way of viewing the image is to download it from: <http://home.att.net/~Paul.N.Lee/FotD/FotD.html> and then step back a bit from the screen to where the impending breakdown is not visible. A sunny but chilly day here at Fractal Central on Wednesday was marginally satisfactory for the cat duo, who would have preferred a temperature of 70F 21C rather than the 59F 15C that actually prevailed. Today is starting equally sunny and notably warmer. The two ex-tomcats should be happy. For me it's just another routine day of too much work and too little play. But the work *will* be finished, and 24 hours from now the next FOTD fractal *will* appear. Until then, take care, and we don't even know what we don't know. Jim Muth jamth@mindspring.com jimmuth@aol.com START 20.0 PAR-FORMULA FILE================================ Beyond_the_Limit { ; time=0:06:07.62--SF5 on a P200 reset=2003 type=formula formulafile=allinone.frm formulaname=MandelbrotMix4 function=recip passes=1 center-mag=+3.429528921055553/+0.2562473412832469/\ 1.909924e+012 params=1/-1.5/0.01/-150/0/0 float=y maxiter=1200 inside=0 logmap=135 periodicity=10 mathtolerance=/1 colors=000N5CN8IMANMCVLFYLHdKJiKM\ qJOvJQzDSw7UvFZkMc`ThQ_zFzq5ki4ob4tW3xP3sRAnTHiVNe\ XU`Z_W`fSal`g`XUYTGVQ3ST9YWFbZKgaQldVqedczmRfzEzlJ\ hbNiTRiJVgKReLOcMLaMH_NEYOBXO8YPBYQEZRHZRK_SN_TQ`T\ T`UW`VZaVaaWdbXgbXjcYmcZpcZsWaqPdoIgmBil6OC9QEBSGE\ TIGVKIXLLYNN_PQaRSbTUdUXfWZgYai_ckaelbdjecigbgiafk\ `en_cpZbrZatXZrVWqTTpRQnPNmNKlLHkJEiHBhF8gD5fLLiS`\ kRbiRdhRefQgeQhcQjbQkaqhcskZunUwqPytKzwFozKdzPVzUU\ zWUzXUzYUzZUz`UzaUzbUzcUzeUzfUzgUzhUzjUzkUzlUzm`zr\ fzwmzhtzUzzFwzJtzNqzRozVlzZizbfzfdzjaznZzrWzvUzyWz\ vXztZzr_zpazmbzkcziezgfzehzbiz`kzZlzXmzVYz`Ize2zj6\ zf9zcDz`GzYKzVNzSRzPUzLYzI`zFdzCgz9kz6nz3qz0sz9uzH\ vzPxzXyzdyzVyzLyzCuzBqzBmzAjzAfz9bz9Zz8Wz8Sz7Oz7Lz\ 7Oz9RzBUzDWzFZzHazJczL`zOZzQWzSUzURzWPzYMz`KzbHzdF\ zfCzhAzj8zlAzfBzaCzXEzSFzNGzIHzDSzMazUZzTWzSTzSPzW\ MzZJzaGzdDzgAzj7zm4zp7zk9zgszzhzeZzLPz1Oz7 } frm:MandelbrotMix4 {; Jim Muth a=real(p1), b=imag(p1), d=real(p2), f=imag(p2), g=1/f, h=1/d, j=1/(f-b), z=(-a*b*g*h)^j, k=real(p3)+1, l=imag(p3)+100, c=fn1(pixel): z=k*((a*(z^b))+(d*(z^f)))+c, |z| < l } END 20.0 PAR-FORMULA FILE==================================
On Thu, 29 Apr 2004, Jim Muth wrote: (...)
I needed to include the mathtolerance entry in the parameter file to be sure that the image is drawn at the correct magnitude on all machines at all screen resolutions. (...) I once argued with the existence of this setting (for that I'm sorry). Later, I found that it seems to be broken in regards to zooming, which Jim seems to hav found out. A better name for it would be errortolerance. It's for _trying_ to determine when you need floating-point, then arbitrary precision. In this case, I'm not sure about _when_ it would be relevant, because parameter files jenerally specify float=yes or no (with a default to either "no or your SSTOOLS.INI setting").
The last time I remember seeing an obvious difference between the floating-point and the intejer versions of an image (that periodicity checking wouldn't explain more of), it was parameters NYUF004 from Dan Farmer (formula from Jm Collard-Richard) -- in the 19.6 release. Tines in the middle disappear with floating-point. In other words, contrary to what Jim observes, it _shouldn't_ very often hav any great effect on the way that renderings crop, but that's difficult to prove (and come up with any rule for the exceptions). The choice of integer/float/double/arbitrary seems to me to always be arbitrary. It's like the "auto" inversion coordinates that would be more informatively called "mouse", because that's where they come from. Hopefully, the code will get better if the documentation does. _______ Moer's truism: The trouble with most jobs is the job holder's resemblence to being one of a sled dog team. No one gets a change of scenery except the lead dog.
participants (2)
-
Jim Muth -
Private Instigator