Guido van Rossum writes:
the point of the [Newton's method] example is to show how you would use is_close_to().
Except that this clearly is a Cauchy test, the algorithm doesn't know the limit. In principle, the appropriate computation would be symmetric. I don't think this is a problem in practice[1], but Skip's "straddling the tick" example is much stronger for an asymmetric comparison function. On the other hand, Skip's case requires an absolute comparison, not a relative one. The whole discussion has been really fast and loose about use cases. People with strong preferences can't seem to wrap their heads around others' use cases, examples poorly matched to the proposals are common, the expertise of the numerical experts seems irrelevant because we *don't* want accuracy even in corner cases, we just want to make it easier for naive users to avoid writing "x == y". ISTM that this PEP can be reduced to We need a floating comparison function that's good enough for government work, to help naive users avoid writing "x == y" for floating point comparisons. There are use cases where one of the values is a known accurate value, so the comparison function is asymmetric. This generally won't get things "too wrong" for symmetric comparisons, except where a relative comparison involves true values near zero. Unfortunately, not much can be done in that case because it requires enough domain knowledge to realize that true values near zero occur and that this is a problem, so use of this function is covered by "consenting adults".[2] And oh yeah, IANAEINA.[3] But for this PEP, I don't need to be. <wink/> Footnotes: [1] I've reconsidered. A priori, I still like symmetric errors better in general, but the target audience for this function isn't going to be reasoning about equivalence classes of IEEE 754 floats. [2] As is all use of floating point. [3] I am not an expert in numerical analysis. Which IIUC applies to the PEP author as well as to this poster.