Re: [Python-Dev] The Case Against Floating Point ==
On Thu, Mar 13, 2008, Imri Goldberg wrote: My suggestion is to do either of the following: 1. Change floating point == to behave like a valid floating point comparison. That means using precision and some error measure. 2. Change floating point == to raise an exception, with an error string suggesting using precision comparison, or the decimal module. This is an interesting idea, but python-dev is the wrong place. You should probably start with python-ideas, then move to c.l.python, then finally bring it up on python-3000. But in any event, it probably doesn't matter: it's too late. Although we have not released a beta, we are far along the alpha cycle and this is too big a change. Remember that Python 3.0 is scheduled to have final release in August. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ All problems in computer science can be solved by another level of indirection. --Butler Lampson ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The Case Against Floating Point ==
On Thu, Mar 13, 2008 at 4:20 AM, Imri Goldberg [EMAIL PROTECTED] wrote: My suggestion is to do either of the following: 1. Change floating point == to behave like a valid floating point comparison. That means using precision and some error measure. 2. Change floating point == to raise an exception, with an error string suggesting using precision comparison, or the decimal module. I don't much like either of these; I think option 1 would cause a lot of confusion and difficulty---it changes a conceptually simple operation into something more complicated. As for option 2., I'd agree that there are situations where having a warning (not an exception) for floating-point equality (and inequality) tests might be helpful; but that warning should be off by default, or at least easily turned off. Some Fortran compilers have such a (compile-time) warning, I believe. But Fortran's users are much more likely to be writing the sort of code that cares about this. Since this change is not backwards compatible, I suggest it be added only to Python 3. It's already too late for Python 3.0. 3. Programmers will still need the regular ==: Maybe, and even then, only for very rare cases. For these, a special function\method might be used, which could be named floating_exact_eq. I disagree with the 'very rare' here. I've seen, and written, code like: if a == 0.0: # deal with exceptional case else: b = c/a ... or similarly, a test (a==b) before doing a division by a-b. That one's kind of dodgy, by the way: a != b doesn't always guarantee that a-b is nonzero, though you're okay if you're on an IEEE 754 platform and a and b are both finite numbers. Or what if you wanted to generate random numbers in the open interval (0.0, 1.0). random.random gives you numbers in [0.0, 1.0), so a careful programmer might well write: while True: x = random.random() if x != 0.0: break (A less fussy programmer might just say that the chance of getting 0.0 is about 1 in 2**53, so it's never going to happen...) Other thoughts: - what should x == x do? - what should 1.0 in set([0.0, 1.0, 2.0]) and 3.0 in set([0.0, 1.0, 2.0]) do? Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The Case Against Floating Point ==
Imri Goldberg [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | Most experienced programmers know that you shouldn't compare floating | point numbers with ==. As a general statement, this is wrong. Mark gave examples. Please drop the proposal. The reason for the int division change is the idea that expressions involving integral values should, insofar as possible, have the same value result regardless of the types used to carry the input (or output) values. Hence 1/2 should equal 1.0/2.0 == .5. The idea that 1 == 1 and 1.0 == 1.0 should give a different answer goes against this principle and the 2.x project of number unification. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The Case Against Floating Point ==
I would suggest something like a ~= b, for approximately equal to. How approximately? Well, there would be a default that could be changed somewhere. Don't know if it's all that useful, though. Tiago A.O.A. Terry Reedy escreveu: Imri Goldberg [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | Most experienced programmers know that you shouldn't compare floating | point numbers with ==. As a general statement, this is wrong. Mark gave examples. Please drop the proposal. The reason for the int division change is the idea that expressions involving integral values should, insofar as possible, have the same value result regardless of the types used to carry the input (or output) values. Hence 1/2 should equal 1.0/2.0 == .5. The idea that 1 == 1 and 1.0 == 1.0 should give a different answer goes against this principle and the 2.x project of number unification. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/tiagoaoa%40cos.ufrj.br ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
