Tim,
Do you recall what ratio_bad() and the calls to it are doing in fracsubr.c? It seems to be at the root of the problem. Using debugflag=3400 also fixes the problem.
I do recall generally and could investigate it, but let me say this: there is absolutely no reliable way to automatically detect when the limit of precision for a fractal is reached with a particular type of math, especially with all the zoom box flexibility that we have (skewed, rotated, etc.) but also because it depends on the algorithm that is being iterated.
Granted. However, we aren't looking at a case where a change in the type of math is even possible (fp to ap, if it were possible). It shouldn't be necessary to use mathtolerance=0.05/1 (or debugflag=3400) to make Fractint generate the correct image.
I think you will find that if the ratio_bad logic is fixed for one fractal it will be broken for another. Or it will work, and the zoom box is broken, then it will break.
Fractal artists who live at the edge of precision toggles and want their PAR files reproducable need to consider forcing the type of math. It's been a while, but I assume that we have sufficient controls to do that.
Yes, we have sufficient controls, I just don't see why it should be necessary in this case.
The above comments should not be taken to mean that I oppose trying to improved automatic detection of precision failure, just that I know it's a very tough problem.
I suspect the problem we are seeing is caused by line 471 in fracsubr.c, where we goto expand_retry because one of the calls to ratio_bad() returned a 1 (this doesn't happen if we use mathtolerance=0.05/1 or debugflag=3400). We then adjust_to_limits(2.0), which will mess up the magnification (and corners, I think). Jonathan