bitwise module proposals (was Re: Discussion: new operators for numerical computation)

[Alex Martelli]

"Paul Foley" <see at below> wrote in message
news:m2d7ju5rha.fsf at mycroft.actrix.gen.nz...
    [snip]
> > And I like your solution of finessing this via names bitor, bitand, etc.
> > This
> > also makes it sensible to 'from bitwise import *' in a module that does
> > heavy bitwise processing.
>
> Yes, but how about renaming them logior()/logxor()/logand()/etc., and
> ash() for "arithmetic shift"...

They're not 'LOGical-AND' etc (that's what you get from 'a and b' &c),
they're 'BITwise-AND' etc -- at least in the terminology I'm most familiar
with.  And 'ash' is what one should put on one's head to atone for this
kind of ribbing (which I'm going to deadpan from beginning to end).


> >> >The 'bitwise' module could supply easily explicit bitfield-extraction
> >> >in place of the mask-and-shift idioms, too.
>
> Define a byte(x, y) function to define an object representing an x-bit
> byte offset y bits into an integer (using "byte" in the older sense,
> not necessarily meaning 8 bits) and a pair of functions, ldb() to
> "load byte"s from an integer, and dpb() to "deposit byte"s into an
> integer

IMHO, far too many people associate 'byte' with '8-bit unit' (I do
agree that this is imprecise, and 'octet' should be used when one
intends 'exactly 8 bits'); and another association is 'the natural
unit/granularity of storage on a given machine', which is also a
different nuance from 'a field of bits of arbitrary length'.  So,
name-wise, I strongly dislike this.  And if Python starts having
idiotical para-abbreviations -- not even real abbreviations, nor
quite acronyms -- such as 'ldb' and 'dpb' in its standard library,
well, I think I might split into a one-man faction and start to
design the language 'Monty' (I would have two versions, a
subset one plus, of course, the Full Monty).


However, the approach itself might be quite fine, just renaming
the class to 'bitfield' for example.  E.g.:

class bitfield:
    def __init__(self, offset, length, value=0):
        self.__offset=offset
        self.__mask=((1<<length)-1)<<offset
        self.value=value
    def extractFrom(self,x):
        self.value=(x&self.__mask)>>self.__offset
        return self
    def insertInto(self,x):
        return (x&~mask) | (self.value << self.__offset)

Other commodity methods could be added to allow using a
bitfield just like an int, without mentioning its .value attribute,
but this might be enough to allow the basic use cases:

    x=bitfield(3,2).extractFrom(anInteger).value

same as what I proposed to encode as

    x=bitfieldget(anInteger,3,2)

and

    x=bitfield(3,2,2).insertInto(anInteger)

same as what I proposed to encode as:

    x=bitfieldset(anInteger,3,2,2)

with some extra convenience in advanced cases.  But I
think this needs more design.  Or perhaps more accurately
a good marketeer, to sell the community on the no-doubt
huge advantages of this.


> > to supply a C implementation of course (cBitfield perhaps?).  No way to
> > take away | & << >> ~ until Python 3000, of course, but, yes, surely
when
> > 3000's time comes life will be easier if bitwise is the popular way to
do
> > things and the linenoise alternative an old/legacy/deprecated one:-).
>
> And why not carry this process to its logical conclusion and

Because the frequency of use of '+' in most kinds of programs is
orders of magnitude higher than that of '|', etc.  bit-wise and bit-field
operations are rare (for most programmers) enough that the slight
extra concision afforded by the linenoise is of moderate import; and
maintainers/readers of such programs may well be unfamiliar enough
with these operations, that the higher explicitness of the named functions
becomes a readability bonus.  No issues of priority between the various
operators, for examples -- issues that just don't arise with '+' and '*', as
we're all familiar from childhood with 'common arithmetic'.

> replace a+b with +(a, b), a*b with *(a, b), etc., too.  You can save
> a little typing by dropping the commas and writing (+ a b), (* a b),
> (logior a b), (ldb (byte 8 16) x), etc.   :-))

"f you want Common Lisp, you know where to find it", I believe.


Alex