On Sun, Mar 29, 2009 at 9:42 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> There are a couple of ancillary portability concerns due to optimizations which
> store system-dependent results of operations between constants in pyc files:
>
> - Issue #5057: code like '\U00012345'[0] is optimized away and its result stored
> as a constant in the pyc file, but the result should be different in UCS-2 and
> UCS-4 builds.
Why would anyone write such code (disregarding the \U escape problem)?
So why do we bother optimizing this?
> - Issue #5593: code like 1e16+2.9999 is optimized away and its result stored as
> a constant (again), but the result can vary slightly depending on the internal
> FPU precision.
I would just not bother constant folding involving FP, or only if the
values involved have an exact representation in IEEE binary FP format.
> These problems have probably been there for a long time and almost no one seems
> to complain, but I thought I'd report them here just in case.
I would expect that constant folding isn't nearly effective in Python
as in other (less dynamic) languages because it doesn't do anything
for NAMED constants. E.g.
MINUTE = 60
def half_hour():
return MINUTE*30
This should be folded to "return 1800" but doesn't because the
compiler doesn't know that MINUTE is a constant.
Has anyone ever profiled the effectiveness of constant folding on
real-world code? The only kind of constant folding that I expect to be
making a diference is things like unary operators, since e.g. "x = -2"
is technically an expression involving a unary minus.
ISTM that historically, almost every time we attempted some new form
of constant folding, we introduced a bug.
--
--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