On Sun, 10 Nov 2002, Tim Wegner wrote:
The logic is in frasubr.c. Search for variables like ratio_bad.
There are some command line variables that let one play with this. Checkout the variable mathtolerance.
I've been steping through the code a bit... The errors in precision kick in around... Breakpoint 1, ratio_bad (actual=4.842708265645479e-14, desired=4.8405723873656825e-14) at fracsubr.c:777 777 tol = math_tol[1]; ... so I set double math_tol[2]={.05,.0003}; (in cmdfiles.c) and that seems to fix the problem (it switches over to arbitrary precision now just when you can bearly notice the horizontal resolution droping) I'm not sure if this is the best solution or not. A noteworthy side-effect from the earlier bug was that when the screen starts getting blocky, then you can no longer zoom in anymore. Your corners will never change. (And so arbitrary precision will never kick in) (I'm guessing the round-off error is effecting the corners too, or at least the distance between them -- once the corners get rounded off then the ratio will alway be close to 1.0000000.., again arb. prec. will never kick in) (Also towards the higher magnifications (e14..e18) the X and Y deltas seemed to be getting kinda.. out of proportion, like X:Y was over 1:100. But it might be ok, I havn't actually done the math on this yet.) What makes me think that just increasing the tolerance might not be the best solution is that only the testx_try values are becoming inacuarte, the testy_try values are still good for much longer.. for example (testy): Breakpoint 1, ratio_bad (actual=-1.3877787807814599e-17, desired=-1.3877787807814457e-17) at fracsubr.c:777 That's 1.0000000000000102321783533857667315777894704554 When testx's ratio is 1.0020376352163461152038502178961419435419136290
My suggestion is to add this issue to a todo list for later. It would be a good thing to revevisit after a major rewrite is done.