On Dec 18, 6:25 pm, "Alf P. Steinbach" <al...@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 -- http://mail.python.org/mailman/listinfo/python-list
