steve+comp.lang.python at pearwood.info
Sun Jan 18 04:09:58 CET 2015
Ian Kelly wrote:
> On Sat, Jan 17, 2015 at 7:26 AM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> I don't understand why they add the error tolerances together. I can
>> understand taking the minimum, or the maximum:
> The usual idea is that the tolerance is calculated as a relative
> value, but an absolute tolerance is used instead when the values get
> close to zero, so under normal circumstances the relative tolerance
> will dominate and the absolute tolerance will be very small in
That suggests that approx_equal() should return True if the actual error is
smaller than *either* the absolute or relative error, that is, using the
> So why add them instead of taking the maximum? I'm not
> sure, but I would guess it's probably for efficiency. Determining the
> maximum requires the CPU to perform a conditional branch that a simple
> addition does not.
"Tell me whether these two numbers differ by at most X or Y%."
"Oh, that would take a nanosecond longer than I think is reasonable, so I'm
instead going to tell you whether they differ by some arbitrary Z instead."
I'm guessing that can only have come from the mindset of C/C++ programmers,
where this sort of thing is considered acceptable:
> In any case, this is not unique to numpy. See
> (equation 8.26)
Ah, well as soon as you start using GPUs for numerical computation, you're
already living in a state of sin. GPU's attitude to numerical correctness
is best described as "meh, close enough".
Seriously, anyone familiar with the horrible state of numeric computing
prior to IEEE-756 surely cannot look at GPU numerics without having
flashbacks to the bad old days where:
if x != 0:
y = 1/x
could crash with a divide by zero!
>> * taking the minimum is equivalent to the rule "numbers are close if they
>> differ by no more than BOTH the absolute tolerance AND the relative
> This is generally not the desired semantic, and it's not unheard of to
> pass 0 for one of the tolerances, in which case the minimum would
> clearly be incorrect.
True. In that case, you would have to treat 0 as a special case, which
starts getting messy.
More information about the Python-list