On Mon, Jan 26, 2015 at 1:39 AM, Andrew Barnert <abarnert@yahoo.com.dmarc.invalid> wrote:
If assertAlmostEqual is primarily intended for float comparisons, and it really is misleadingly bad for that use,
Since I was complaining about assertAlmostEqual, I should probably say explicitly what I don't like: It has two arguments for specifying precision: "places", which is measured in decimal digits, and "delta", which is an absolute tolerance like the ones we've discussed here. The fact that this pair of options exists, and the fact that relative precision is very very frequently talked about in terms of "significant digits", strongly suggests to me that these are the two settings for relative and absolute tolerances, and setting places=7 means that the numbers should match up to 7 significant digits. However, this is not what places=7. In fact, if 'places' is specified, then it means we set the absolute tolerance to 5 * 10**(-places - 1). So the problems are: - This is confusing/misleading/surprising. - There is no support for relative tolerances, which are almost always what you want -- using the same tolerances for comparing two numbers in the millions and for comparing two numbers in the millionths is going to lead to ugly results. - Because there is no support for relative tolerances, the defaults are wildly inappropriate unless the numbers being compared happen to be of normal size, like say between 10**-2 and 10**2. The docs don't warn about this. And in fact if you want to get a useful result when comparing two large numbers, you actually have to assert that they are the same to some negative number of decimal places. Technically this can be worked out from docstring (it references round(), and round() is documented to accept a negative ndigits argument), but it's very surprising and obscure. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org