* 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

Reply via email to