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

[Alf P. Steinbach]

* 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.

I would rather not speculate about motives.

I can say things about the code that was presented, and I did, but as for the 
motives that went into creating it or presenting it in this thread, well I'm not 
telepathic.


>>>>> 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?

No, I meant exactly what I wrote, that an optimizer only can do so much, which 
you also noted yourself; that language support facilitates this optimization; 
and that few languages have that support (but e.g. C++0x will have it).


[snip]

>> 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.

Yes, that's what C++0x 'constexpr' is about.

But I've lost the context here, not sure what this is all about.


[snip]

> (1) It's not meaningless to talk about renaming names.

Well, as good as meaningless, IMHO. In fact, earlier, when you wrote under the 
assumption that I was talking about such renaming, you seemed to maintain that 
it was pretty meaningless. I conclude from that that also this is relative.


> (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.

I rather hoped you would try to employ the "sensible" heuristic.

The problem so far has, apparently, been that you refuse to accept the language 
specification's definition, in §4.1, of variable as name and vice versa.

An "is-it-sensible" heuristic could have cleared that up, I think.


> (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.

But when that is the problem, a basic misunderstanding of what a word means, 
then it's worth uh, harping on the issue, I think:


> [...]
>>> 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?

I don't. I use it as evidence for what "name" refers to. A constant "name" is 
then, logically, a constant such thing, to wit, a constant variable. You may 
find that terminology paradoxical. For C++, which has the means of enforcing it, 
it's a FAQ (many novices have some trouble accepting constant /variables/...). 
If it helps let's adopt Java's terminology and talk about "final" variables. Or, 
as Bjarne had it in original C++, "readonly" variables.


> 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.

Yeah, but you're not seriously suggesting that any global variable initialized 
to a constant (immutable value) should be uppercased. So "constant" in this 
regard does not refer to the refererred to value. It refers to the id(v).


Cheers & hth.,

- Alf