* Steven D'Aprano:
On Sat, 19 Dec 2009 01:25:48 +0100, Alf P. Steinbach wrote:
That said, and a bit off-tangent to your comment's main thrust, the time
spent on coding that repeated-division-by-2 optimization would, I think,
be better spent googling "Collatz Conjecture" -- avoiding writing
/any/ code. ;-)
That's a strange thing to say.
No. The code shown was like attacking Fermat's last theorem with a little Python
script checking out number triplets. It's already been done (not to mention that
that theorem's been proven, although that's, AFAIK, not the case for Collatz').
Now, it's a different story if you're using the gmpy module. You DON'T
want to use literals in loops involving gmpy, because they would have
to be coerced to .mpz's on every pass through the loop.
[...]
Yeah, good point. Few languages have compile time evaluation of
logically constant expressions.
Surely that's an implementation issue rather than a language issue.
No, it isn't.
An optimizer can only do so much, as you yourself note below!
With language support it's a very different matter because guarantees propagate
so that sophisticated analysis is no longer necessary: the compiler /knows/,
because it's explicitly being told.
C++0x will have that feature (called
'constexpr' IIRC) but in Python, current C++ etc. it's just a good idea
to precompute values, and name them, rather than computing them again
and again where they're needed.
CPython 2.5 and on has a keyhole optimizer that replaces many constant
expressions with pre-computed values.
# Python 2.4
dis.dis(compile('1+1', '', 'eval'))
0 0 LOAD_CONST 0 (1)
3 LOAD_CONST 0 (1)
6 BINARY_ADD
7 RETURN_VALUE
# Python 2.5
dis.dis(compile('1+1', '', 'eval'))
1 0 LOAD_CONST 1 (2)
3 RETURN_VALUE
Unfortunately it doesn't help Mensanator's case, because there's no way
to tell the compiler to generate mpz objects instead of int objects, and
expressions such as gmpy.mpz(0) are not recognised as compile-time
constants.
See?
;-)
Mine does when I use gmpy. Otherwise, the notion that "most names are
constants" is generally false.
No, it depends on what you mean by "constant".
All names are constant. Always. The Python language does not support
renaming names -- as far as I know, no language does.
No-ones been talking about renaming names. I think that's purely rhetorical on
your part but it may be that you really believe so. In the latter case, just try
to interpret statements so that they're meaningful instead of meaningless. :-)
The problem with Python,
as Google noted, is that the language is so excessively dynamic: even
names of routines are variables,
Don't say that, that is confusing the name with the value.
Nope.
The terms
"constant" and "variable" refer to the values bound to a name, not the
name itself:
I'm sorry, that's incorrect.
Quote from ยง4.1 "Naming and binding" of the Python 3.1.1 language spec:
"If a name is bound in a block, it is a local variable of that block, unless
declared as nonlocal. If a name is bound at the module level, it is a global
variable. (The variables of the module code block are local and global.) If a
variable is used in a code block but not defined there, it is a free variable."
what you mean is that even routines are variables.
I'm sorry but I can't make sense of what you write here. In addition I'm not
sure what you mean because there are two main interpretations.
If you mean that user defined Python routines are mutable, yes that's right, but
not what I was talking about (which you can easily see by checking whether it
makes sense in context; it doesn't).
If you mean that a routine of itself is a variable, no it isn't, but the name of
a routine, like "foo" in
def foo: print( "uh" )
or "bar" in
bar = lambda: print( "oh" )
is a variable, per the language specification's definition quoted above (and
also by any reasonable meaning of "variable"!).
The meaning of "variable" for Python terminology is specified by the language
specification, as quoted above: a variable is a name.
[snipped rest, irrelevant]
Cheers & hth.,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list