On Tue, Jan 27, 2015 at 10:37 AM, Guido van Rossum <guido@python.org> wrote:
By now can't you summarize the reasons that others have brought up?
I can try ;-) --probably not until this evening though.
Because we want it to be able to do something sane when comparing to zero --
<snip> I don't think you can have this always be sane. For someone who for
whatever reason is manipulating quantities that are in the range of 1e-100, 1e-12 is about as large as infinity.
Exactly why I favor having the abs_tolerance default to zero.
I think my reasoning comes down to the same rule I often use to decide whether we need one function or two -- if in every use case you always know whether you need version A or version B, then it's better to have two functions rather than a single one with a flag to request A or B.
And isn't it the case that whenever you are comparing to zero, you *know* that you are comparing to zero, and you *must* specify an absolute tolerance (otherwise it's not a use case at all)?
I really appreciate this API design approach, and in this case I started out with that idea. But I think this is likely to be used where you need to test a bunch of values with single function/set of parameters. In TestCase.assertIsCloseTo, as well as home grown loops and comprehensions. IIUC, numpy doesn't design APIs this way.
I'm not sure numpy's API is exactly designed at all ;-) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov