Bits module -- early working version

[Scott David Daniels]

I've been working on a module to get at the bits of all numeric types
(no, I haven't thought of how to solve the decimal data type that is
coming). I've finally got the bits module to pass all of my own tests,
so I'm looking for bug reports, design critiques, and general input. I
eventually plan to release this under an MIT-style license. If you are
interested in seeing read access to the bits of python's numbers, and
want to see what I'm up to / critique someone else's work / volunteer to
help extend, check out:

http://members.dsl-only.net/~daniels/bits.html

If you want to know what questions I have, here are my current set:

1) Do you know a case that fails?
2) Should the names be lsb, lsbit, or lsbitno (and similarly for msb*)?
I've gone with lsb, but cases can be made for the others.
3) Is "extract" the right name, or should I us a name more like "bits"?
4) Should bit(v, N) somehow be subsumed in extract(v, l, hi) (or
whatever extract should be called)?
5) Have I adequately explained what these functions do?
6) Do these functions work as-is (from source) for various machines?
I know/believe Intel x86/pentia work; what about alpha, 68K, ....
7) Should bitcount simply raise and exception on negative input?
8) If you supply an unexpected argument type for the number, should I
try to calla corresponding method? (__bit__ for bit, __msb__ for
msb, ....)

So I'd like feedback before actually releasing.

--
-Scott David Daniels
Sc***********@Acm.Org

[Mensanator]

>Subject: Bits module -- early working version

From: Scott David Daniels Sc***********@Acm.Org
Date: 2/12/2004 11:55 PM Central Standard Time
Message-id: <40******@nntp0.pdx.net>

I've been working on a module to get at the bits of all numeric types
(no, I haven't thought of how to solve the decimal data type that is
coming). I've finally got the bits module to pass all of my own tests,
so I'm looking for bug reports, design critiques, and general input. I
eventually plan to release this under an MIT-style license. If you are
interested in seeing read access to the bits of python's numbers, and
want to see what I'm up to / critique someone else's work / volunteer to
help extend, check out:

http://members.dsl-only.net/~daniels/bits.html

If you want to know what questions I have, here are my current set:

1) Do you know a case that fails?
2) Should the names be lsb, lsbit, or lsbitno (and similarly for msb*)?
I've gone with lsb, but cases can be made for the others.
3) Is "extract" the right name, or should I us a name more like "bits"?
4) Should bit(v, N) somehow be subsumed in extract(v, l, hi) (or
whatever extract should be called)?
5) Have I adequately explained what these functions do?
6) Do these functions work as-is (from source) for various machines?
I know/believe Intel x86/pentia work; what about alpha, 68K, ....
7) Should bitcount simply raise and exception on negative input?
8) If you supply an unexpected argument type for the number, should I
try to calla corresponding method? (__bit__ for bit, __msb__ for
msb, ....)

So I'd like feedback before actually releasing.
Testing for the lsb allows me to speed up my Collatz program since I can
extract all the factors of 2 in one fell swoop as opposed to iterating through
each one. For the large numbers I work with (2**100000 - 1 in the following
example), this optimization is signifigant:

c:\python23\user>python collatz_.py 100000

standard Python long ints without optimization
r1 863323 r2 481603 in 632.234999895 seconds

optimized with bits.lsb() bit scanning
r1 863323 r2 481603 in 332.5 seconds

But I had already been using the gmpy module which has the scan1()
function that does the same thing as bits.lsb(). And gmpy long ints are
more efficient than the Python long ints. Together, I get much better
performance:

optimized with gmpy.scan1() bit scanning
r1 863323 r2 481603 in 131.733999968 seconds

For my work, I can't see any advantage in using bits over gmpy.

--
-Scott David Daniels
Sc***********@Acm.Org

--
Mensanator
Ace of Clubs