"Steven D'Aprano" <[email protected]> wrote
Pardon me, but that's incorrect. Python is not assembly, or C, and the
behaviour of bit shifting in Python is NOT machine specific.
http://docs.python.org/library/stdtypes.html#bit-string-operations-on-integer-types
In Python, a left shift of n MUST return the equivalent of
multiplication by 2**n, and a right shift MUST return the equivalent of
integer division by 2**n. Any other result is a SERIOUS bug in Python
So it seems, I apologise, I had assumed that for bit shifting
Python did indeed just pass it down to the C compiler which
in turn passes it to the CPU.
As someone who works a lot at the CPU level that's slightly
dissappointing since it makes bit shifting predictable but unreliable
from my perspective - I can't guarantee the effect on the CPU...
But since it's never actually caused me a problem I won't lose
sleep over it.
So while I bow to your knowledge of bit operations in assembler on
obscure four bit processors,
I haven't used 4 bit CPUs since working on the millenium
bug ~10 years ago but the same applies in higher order processors
too. I only used a 4 bit CPU since you gave a 4 bit example.
But given the above it's irrelevant, the language defines the
behaviour and I was wrong about that.
Python does not do that. (I'm not even
sure if Python runs on any four bit CPUs!)
Probably not but it does run on some 8 bit ones.
> It is certainly good practice if you are dealing with numbers which
> might be more than 24 bits to start with:
Its more than good practice there, its essential.
Hardly. There are other ways of truncating a number to 8 bits
I meant the truncating was needed not the & mechanism.
[and discussing the case where you know your input is already 8 bits]
In the case in point the & 255 keeps the coding style consistent
and provides an extra measure of protection against unexpected
oddities so I would keep it in there.
So you add unnecessary operations to be consistent? That's terrible
practice.
No but I don't mix two styles of guard.
If I need a guard and I'm already using masks then I'll use a mask,
I certainly wouldn't mix asserts and masks for similar functions.
If I'm sure I don't need the guard then I definitely wouldn't add one
just for consistency of style.
So if you have an operation like this:
n = 12*i**3 + 7
and later on, you then want n = i+1, do you write:
n = 1*i**1 + 1
No I'd write
n = i+1
rather than
n = lambda x: x+1(i)
or even (if Python had such an incr function)
n = incr(i)
since the arithmetic version is more consistent that the
function call or the lambda.
> cycles and needlessly complicating the code. The right way to guard
> against "this will never happen" scenarios is with assert:
>
> assert n.bit_length() <= 32 # or "assert 0 <= n < 2**32"
I would accept the second condition but the mask is much faster.
Premature (micro) optimizations is the root of all evil. An assert that
can be turned off and not executed is infinitely faster than a bit
shift which is always executed whether you want it or not.
But I did want it :-)
And either way, the 20 seconds I lose trying to interpret the bit ops
when I read the code is far more important than the 0.000001 seconds I
lose executing the assert :)
Ah, but to me bit ops are normal code so I don't lose time reading
them. In fact I'd take longer to figure out the assert. Readability is all
about idioms and if you do a lot of bit tweaking masking is the normal
idiom. (The only difference is that I would have used hex rather than
decimal numbers for the masks - because I read bit patterns in hex
faster than in decimal)
bit_length doesn't seem to work on any of my Pythons (2.5,2.6 and
3.1)
It won't work in 2.5 or 2.6. You're probably trying this:
123.bit_length()
Indeed, I tried using a variable and it worked.
Thanks for that I hadn't come across bit_length() before.
--
Alan Gauld
Author of the Learn to Program web site
http://www.alan-g.me.uk/
_______________________________________________
Tutor maillist - [email protected]
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
