Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Steven D'Aprano]

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