Short-circuit Logic
88888 Dihedral
dihedral88888 at gmail.com
Thu May 30 23:11:38 EDT 2013
Steven D'Aprano於 2013年5月30日星期四UTC+8上午10時28分57秒寫道:
> On Wed, 29 May 2013 10:50:47 -0600, Ian Kelly wrote:
>
>
>
> > On Wed, May 29, 2013 at 8:33 AM, rusi <rustompmody at gmail.com> wrote:
>
> >> 0.0 == 0.0 implies 5.4 == 5.4
>
> >> is not a true statement is what (I think) Steven is saying. 0 (or if
>
> >> you prefer 0.0) is special and is treated specially.
>
> >
>
> > It has nothing to do with 0 being special. A floating point number will
>
> > always equal itself (except for nan, which is even more special), and in
>
> > particular 5.4 == 5.4. But if you have two different calculations that
>
> > produce 0, or two different calculations that produce 5.4, you might
>
> > actually get two different numbers that approximate 0 or 5.4 thanks to
>
> > rounding error. If you then compare those two ever-so-slightly
>
> > different numbers, you will find them unequal.
>
>
>
> EXACTLY!
>
>
>
> The problem does not lie with the *equality operator*, it lies with the
>
> calculations. And that is an intractable problem -- in general, floating
>
> point is *hard*. So the problem occurs when we start with a perfectly
>
> good statement of the facts:
>
>
>
> "If you naively test the results of a calculation for equality without
>
> understanding what you are doing, you will often get surprising results"
>
>
>
> which then turns into a general heuristic that is often, but not always,
>
> reasonable:
>
>
>
> "In general, you should test for floating point *approximate* equality,
>
> in some appropriate sense, rather than exact equality"
>
>
>
> which then gets mangled to:
>
>
>
> "Never test floating point numbers for equality"
>
>
>
> and then implemented badly by people who have no clue what they are doing
>
> and have misunderstood the nature of the problem, leading to either:
>
>
>
> * de facto exact equality testing, only slower and with the *illusion* of
>
> avoiding equality, e.g. "abs(x-y) < sys.float_info.epsilon" is just a
>
> long and slow way of saying "x == y" when both numbers are sufficiently
>
> large;
>
>
>
> * incorrectly accepting non-equal numbers as "equal" just because they
>
> happen to be "close".
>
>
>
>
>
> The problem is that there is *no one right answer*, except "have everyone
>
> become an expert in floating point, then judge every case on its merits",
>
> which will never happen.
>
>
>
> But if nothing else, I wish that we can get past the rank superstition
>
> that you should "never" test floats for equality. That would be a step
>
> forward.
>
>
>
>
>
>
>
> --
>
> Steven
The string used to represent a floating number
in a computer language is normally in the decimal base of very
some limited digits.
Anyway with the advances of A/D-converters in the past 10 years
which are reflected in the anttena- transmitter parts in phones,
the long integer part in Python can really beat the low cost
32- 64 bit floating computations in scientific calculations.
More information about the Python-list
mailing list