Prev: Solaris 2.6 boot errors
Next: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments
From: Steven D'Aprano on 19 Dec 2009 00:41
On Fri, 18 Dec 2009 21:29:27 -0600, John Bokma wrote:

> Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> writes:
>
>> CPython 2.5 and on has a keyhole optimizer that replaces many constant
> ^^^^^^^
> Shouldn't that be peephole?

Alternate names for the same thing.


>> expressions with pre-computed values.
>
> And that's called constant folding.

Yes.

> Unless I misread your post (or have been out of touch with compiler
> building too long)

No :)



--
Steven
From: Mensanator on 19 Dec 2009 01:06
On Dec 18, 6:25 pm, "Alf P. Steinbach" <al...(a)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

From: Alf P. Steinbach on 19 Dec 2009 01:21
* Mensanator:
>>
>> 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.

It's probably good for you that you know so much about Collatz.

I fail to see the relevance to anything.


Cheers & hth.,

- Alf
From: Mensanator on 19 Dec 2009 01:35
On Dec 19, 12:21 am, "Alf P. Steinbach" <al...(a)start.no> wrote:
> * Mensanator:
>
>
>
> >> 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.
>
> It's probably good for you that you know so much about Collatz.
>
> I fail to see the relevance to anything.

No kidding. Here let me explain it:

You said my time would be better spent googling "Collatz Conjecture".

I said I know more than can be found by googling. Therefore,
it follows that my time could NOT be better spent googling.

Thus, your staement is shown to be false.

QED

>
> Cheers & hth.,
>
> - Alf

From: Steven D'Aprano on 19 Dec 2009 01:40
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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Solaris 2.6 boot errors
Next: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments