[Python-ideas] Way to check for floating point "closeness"?
mistersheik at gmail.com
Fri Jan 16 01:46:46 CET 2015
I'm not sure what Steven's code is, but his hypothesis:
"Furthermore, for safety you normally want the larger estimate of error,
not the smaller…"
does not apply to the usual case where you have an actual value and an
estimate. He seems to be describing a symmetric error function, which is
not intuitive to me.
On Thu, Jan 15, 2015 at 7:23 PM, Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:
> On Jan 15, 2015, at 3:58 PM, Neil Girdhar <mistersheik at gmail.com> wrote:
> You almost always want to use either an absolute tolerance or a relative
> Exactly -- only the user knows what is wanted. The trick is that relative
> tolerance is the most-of the time choice for float compares, but it's not
> appropriate (or even possible) for zero.
> So here we are grappling for a way to have sensible behavior at zero with
> otherwise relative tolerance. It's probably not possible to do so in the
> general case.
> So we should probably simply require the user to specify either and
> absolute or relative tolerance and be done with it.
> Nothing will be relatively close to zero except zero, which is fine, but
> should be mentioned in the docs.
> It sounds like this is what Steven's code does. I just haven't figured out
> how to look at it on a phone.
> Here's why: Consider your estimated value a and your actual value b. If
> the estimate is taken to be the mean of a standard Gaussian distribution
> (the minimum assumptive distribution for a given mean and variance over the
> reals), then using an absolute tolerance is equivalent to verifying that
> the probability of observing b is within a interval with sufficient
> probability. Similarly, if the estimate is taken to be the mean of an
> standard exponential distribution (the minimum assumptive distribution for
> a given mean over the positive reals), then using a relative tolerance is
> equivalent to verifying the same thing.
> You almost always want one or the other. The symmetric error that people
> are proposing in this thread has no intuitive meaning to me.
> On Thu, Jan 15, 2015 at 6:47 PM, Chris Barker - NOAA Federal <
> chris.barker at noaa.gov> wrote:
>> On Jan 15, 2015, at 3:31 PM, Neil Girdhar <mistersheik at gmail.com> wrote:
>> absolute(*a* - *b*) <= (*atol* + *rtol* * absolute(*b*))
>> Oh, and if the numbers are small, then adding the absolute tolerance
>> changes the tolerance significantly -- so you don't get what you expect
>> there, either.
>>>> where atol is an absolute tolerance and rtol is a relative tolerance
>>>> (relative to the actual value b). This subsumes most of the proposals here.
>>> adding atol in there "takes care of" the near zero and straddleing zero
>>> issue ( I suspect that's why it's done that way), but it is fatally wrong
>>> for values much less than 1.0 -- the atol totally overwhelms the rtol.
>>> See my post earlier today.
>>> Christopher Barker, Ph.D.
>>> 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 at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas