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.