On Sat, 19 Dec 2009 04:29:22 +0100, Alf P. Steinbach wrote:
> * 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').
You're assuming that Mensanator's motive for writing code is to challenge
the Collatz Conjecture, rather than to just have fun doing maths and
programming, or to build up his skills for a serious effort at extending
the domain of values for which it is known to be true. Or just because he
needs a function that calculates the hailstone numbers.
>>>> 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!
You make no sense here. What I note below is the existence of an
implementation-specific optimizer. And your conclusion? That such
optimization is language specific! How does that make sense?
Obviously it wouldn't be sensible for CPython to optimize numeric
literals as mpz objects, because that would be a lot of overhead for very
little gain. But it might make sense for somebody to create a "Numeric
Python" implementation which used mpz as the standard integer type.
A slightly more tricky case is optimizing away more complex runtime
expressions. len("abc") is not necessarily the constant 3, because the
function len may have been replaced by something else, thus requiring it
to be calculated at runtime rather than compile-time. But an
implementation might relax that condition and treat built-ins as
constants. Guido probably will never allow such a thing in CPython, but
other implementations are free to do things differently. Even if people
argue that such a behavioural change is "no longer Python", there's
nothing preventing an optimizing implementation from replacing
"abc".__len__() with the constant 3 except the complexity of
implementation and the diminishing returns of doing so.
> 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.
Of course if a language makes a certain guarantee (for example, that
calls to math.exp(0) will be replaced at compile-time with 1.0) then the
compiler can make that substitution. But such optimizations tend not to
be specified by the language (in fact languages like C often tend to
leave large amounts of behaviour as implementation-defined), and even
when languages do make certain guarantees, implementations are free to
implement any behaviour not implicitly or explicitly forbidden.
>>>> 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. :-)
(1) It's not meaningless to talk about renaming names.
(2) I will not try to guess what you mean on the basis of what I consider
sensible, rather than respond to what you actually say.
(3) I've already gone over the name/value thing to death in another post,
so I'll do everyone a favour and not continue it here.
[...]
>> 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."
Since the above quote doesn't mention "constant", how on earth can you
use it as evidence for what "constant" refers to?
In any case, the words "constant" and "variable" have multiple meanings.
They can be either nouns or adjectives. Constants (nouns) are called
constants because of the value is constant (adjective) -- and similar for
variables.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
