On Mon, Apr 6, 2009 at 1:22 PM, Mark Dickinson <dickinsm at gmail.com> wrote: > On Mon, Apr 6, 2009 at 9:05 PM, Raymond Hettinger <python at rcn.com> wrote: >> The code for the lsum() recipe is more readable with a line like: >> >> exp = long(mant * 2.0 ** 53) >> >> than with >> >> exp = long(mant * 9007199254740992.0) >> >> It would be ashamed if code written like the former suddenly >> started doing the exponentation in the inner-loop or if the code >> got rewritten by hand as shown. Do you have any evidence that people write lots of inner loops with constant expressions? In real-world code these just don't exist that much. The case of constant folding in Python is *much* weaker than in C because Python doesn't have real compile-time constants, so named "constants" are variables to the compiler. > Well, I'd say that the obvious solution here is to compute > the constant 2.0**53 just once, somewhere outside the > inner loop. In any case, that value would probably be better > written as 2.0**DBL_MANT_DIG (or something similar). So true. > As Antoine reported, the constant-folding caused quite > a confusing bug report (issue #5593): the problem (when > we eventually tracked it down) was that the folded > constant was in a .pyc file, and so wasn't updated when > the compiler flags changed. Right. Over the years the peephole optimizer and constant folding have been a constant (though small) source of bugs. I'm not sure that there is much real-world value in it, and it is certainly not right to choose speed over correctness. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4