<div class="gmail_quote">On Thu, Mar 13, 2008 at 4:20 AM, Imri Goldberg <<a href="mailto:lorgandon@gmail.com">lorgandon@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
My suggestion is to do either of the following:<br>
1. Change floating point == to behave like a valid floating point<br>
comparison. That means using precision and some error measure.<br>
2. Change floating point == to raise an exception, with an error string<br>
suggesting using precision comparison, or the decimal module.<br></blockquote><div><br class="webkit-block-placeholder"></div><div>I don't much like either of these; I think option 1 would cause<br></div><div>a lot of confusion and difficulty---it changes a conceptually</div>
<div>simple operation into something more complicated.</div><div><br class="webkit-block-placeholder"></div><div>As for option 2., I'd agree that there are situations where having</div><div>a warning (not an exception) for floating-point equality (and</div>
<div>inequality) tests might be helpful; but that warning should be</div><div>off by default, or at least easily turned off.</div><div><br class="webkit-block-placeholder"></div><div>Some Fortran compilers have such a (compile-time) warning,</div>
<div>I believe. But Fortran's users are much more likely to be</div><div>writing the sort of code that cares about this.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Since this change is not backwards compatible, I suggest it be added<br>
only to Python 3.<br>
</blockquote><div><br class="webkit-block-placeholder"></div><div>It's already too late for Python 3.0.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
3. Programmers will still need the regular ==:<br>
Maybe, and even then, only for very rare cases. For these, a special<br>
function\method might be used, which could be named floating_exact_eq.<br></blockquote><div><br class="webkit-block-placeholder"></div><div>I disagree with the 'very rare' here. I've seen, and written, code like:</div>
<div><br class="webkit-block-placeholder"></div><div>if a == 0.0:</div><div> # deal with exceptional case</div><div>else:</div><div> b = c/a</div><div> ...</div><div><br class="webkit-block-placeholder"></div><div>
or similarly, a test (a==b) before doing a division by a-b. That</div><div>one's kind of dodgy, by the way: a != b doesn't always guarantee</div><div>that a-b is nonzero, though you're okay if you're on an IEEE 754</div>
<div>platform and a and b are both finite numbers.</div><div><br class="webkit-block-placeholder"></div><div>Or what if you wanted to generate random numbers in the open interval</div><div>(0.0, 1.0). random.random gives you numbers in [0.0, 1.0), so a</div>
<div>careful programmer might well write:</div><div><br class="webkit-block-placeholder"></div><div>while True:</div><div> x = random.random()</div><div> if x != 0.0:</div><div> break</div><div><br class="webkit-block-placeholder">
</div><div>(A less fussy programmer might just say that the chance</div><div>of getting 0.0 is about 1 in 2**53, so it's never going to happen...)</div><div><br class="webkit-block-placeholder"></div><div>Other thoughts:</div>
<div><br></div><div> - what should x == x do?</div><div> - what should<br></div><div><br class="webkit-block-placeholder"></div><div>1.0 in set([0.0, 1.0, 2.0])</div><div><br class="webkit-block-placeholder"></div><div>and </div>
<div><br class="webkit-block-placeholder"></div><div>3.0 in set([0.0, 1.0, 2.0])</div><div><br class="webkit-block-placeholder"></div><div>do?</div><div><br class="webkit-block-placeholder"></div><div>Mark</div></div>