Discussion: new operators for numerical computation

[Paul Foley]

On Mon, 31 Jul 2000 11:43:14 +0200, Alex Martelli wrote:

>> >> FLAG = bitwise.or(FLAG1, FLAG2, FLAG3, FLAG4, FLAG5, FLAG6, FLAG7,
> FLAG8)
>> >
>> >What an EXCELLENT idea.  shift left/right could also be packaged that
>> >way (or, almost so; 'or' is a reserved words in Python...).

> 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"...

>> >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

> 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
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.   :-))

-- 
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc, informally-specified, bug-ridden,
slow implementation of half of Common Lisp.

(setq reply-to
  (concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))