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

[Mensanator]

On Dec 18, 6:25 pm, "Alf P. Steinbach" <al... at start.no> wrote:
> * Mensanator:
>
> >> The second deviation is that since most names are constants,
>
> > Really? Does that mean you don't use literals, to save the time
> > required to convert them to integers? Isn't that done at compile
> > time?
>
> > So, instead of doing the Collatz Conjecture as
>
> > while a>1:
> >   f = gmpy.scan1(a,0)
> >   if f>0:
> >     a = a >> f
> >   else:
> >     a = a*3 + 1
>
> > You would do this?
>
> > zed = 0
> > one = 1
> > two = 2
> > twe = 3
> > while a>one:
> >   f = gmpy.scan1(a,zed)
> >   if f>zed:
> >     a = a >> f
> >   else:
> >     a = a*twe + one
>
> That seems to have no relation to what you quoted / responded to.

Whose fault is that? Here's a hint: when people's replies don't
make any sense, it's because they don't understand your prattle.
That's not good for someone who fancies himself a teacher of
programming.


>
> On the other hand, if there is some specific rôle played by the 3 above, where
> some other value (like e.g. 5) might be used instead, then a self descriptive
> name for that rôle might be good.
>
> Such reasonable naming (not what you did above) then allows easier modification
> of and makes it easier to understand the code.
>
> 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. ;-)

Ha! I know more about Collatz than you can ever find by Googling!
And how did I achieve that? By writing such code. Be a good boy and
maybe I'll show you how to do Ulam's Spiral with Turtle Graphics.

>
> > Does this really save any time?
>
> If by "it" you mean the silly naming, no it doesn't.
>
> On the contrary, it wastes time, both for writing the code and reading it.
>
> Generally, IMO, think about the clarity of your code. If naming something
> increases clarity, then name the thing. If it doesn't increase clarity, don't.
>
>
>
>
>
> > 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.
>
> > In that case, you DO want to use constants as opposed to literals:
>
> > ZED = gmpy.mpz(0)
> > ONE = gmpy.mpz(1)
> > TWO = gmpy.mpz(2)
> > TWE = gmpy.mpz(3)
> > while a>ONE:
> >   f = gmpy.scan1(a,0) # int used here, so it can be a literal
> >   if f>ZED:
> >     a = a >> f
> >   else:
> >     a = a*TWE + ONE
>
> > And yes, the time savings can be tremendous, especially when 'a'
> > has over 50,000 decimal digits.
>
> Yeah, good point. Few languages have compile time evaluation of logically
> constant expressions. 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.
>
> > . I do not follow PEP
> >> 8's recommendation to use uppercase names of constants. In fact almost no Python
> >> code does,
>
> > 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".

Why don't you try using what PEP 8 means by "constant".

> The problem with Python, as
> Google noted, is that the language is so excessively dynamic: even names of
> routines are variables, and there /are/ no named user defined constants except
> logically, in the programmer's mind. And logically (that is, at the "in the
> programmer's mind" level), if you define "constant" as a name whose value will
> not change after initialization, then routine names are constants.

You're sitting too close to the fire. Why don't you back off and
quit overanalizing things.

>
> However, if you define "constant" as only a global scope (that is, module scope)
> name that denotes a boolean, numerical or string or Null value and that doesn't
> change after initialization, then your statement about the scarcity of constants
> appears to be true, but using a practically useless definition.
>
> I think for such constants exported by modules it's a good idea to at least
> provide uppercase names so as conform to very firmly established convention.
> There might even be tools that rely on that convention. But for application code
> the uppercase names are just distracting, and they don't help you...

They help when I look at something like

a = (i-ONE)*NIN**(k-ONE) + (NIN**(k-ONE) - ONE)//TWO + ONE

>
> Cheers & hth.,
>
> - Alf