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 <rustompm...@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. -- http://mail.python.org/mailman/listinfo/python-list
