On Feb 5, 2006, at 10:48 AM, Raymond Hettinger wrote: >>> So I was wondering if module math (and >>> perhaps by symmetry module cmath, too) shouldn't grow a function >>> 'areclose' (calling it just 'close' seems likely to engender >>> confusion, since 'close' is more often used as a verb than as an >>> adjective; maybe some other name would work better, e.g. >>> 'almost_equal') taking two float arguments and optional tolerances >>> and using roughly the same specs as Numeric, e.g.: >>> >>> def areclose(x,y,rtol=1.e-5,atol=1.e-8): >>> return abs(x-y)<atol+rtol*abs(y) > > IMO, the cure is worse than the disease. It is easier to learn about > the hazards of floating point equality testing than to think > through the > implications of tolerance testing (such as loss of transitivity) and > learning > how to set the right tolerance values for a given application (ones > that > give the right results across the entire domain of expected inputs). > > The areclose() function can be a dangerous crutch that temporarily > glosses over the issue. Without some numerical sophistication, it > would not > be hard create programs that look correct and pass a few test but, > in fact, > contain nasty bugs (non-termination, incorrect acceptance/ > rejection, etc).
For those of us that already know what we're doing with floating point, areclose would be very convenient to have. Especially for unit testing. I could definitely throw away a bunch of ugly code that uses less correct arbitrary tolerance guesses if it were around. -bob _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
