Title: lower-level API for longs
Type: enhancement Stage:
Components: Interpreter Core Versions:
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: facundobatista, gregsmith, mark.dickinson, tim.peters
Priority: normal Keywords:

Created on 2003-04-16 18:07 by gregsmith, last changed 2009-02-10 21:54 by mark.dickinson. This issue is now closed.

Messages (6)
msg61112 - (view) Author: Gregory Smith (gregsmith) Date: 2003-04-16 18:07
something to make it a little more efficient to
build stuff on long integers; some simple things which 
are much faster to do in C than in python:

   n.bitwid()    1+ floor(log2(abs(n)) - # of useful bits
    n.bit(x)       (n>>x)&1
    n.bit(hi,lo)    (n>>lo) & ( (1<<(hi-lo))-1)
      n.bitrev(m)  - reverse the lower m bits of n,
return that

      n.findup( val=1, startbit=0)
        "search leftwards for a bit matching 'val',
starting at
          bit 'startbit'; -1 if none"
      n.finddown(val=1, startbit=n.bitwid())
         " search rightwards"

And some which would depend on the underlying
implementation (which appears to be pretty much
cast in cement, if not actual stone) :

   n.bitarray()   returns array.array('H') containing
raw bits

   long_fromarray(seq, neg=0)  - reverse of n.bitarray

If there's any interest in this, and no reason to shoot it
down right away, I cld write a PEP on it.

It would also be nice to have field-insertion operators,
that raises the question of wether these should return
a new long, or wether they should be built on a 
mutable 'bit-sequence' type which can act like a long.
Maybe this should be an 'array-of-bit' suggestion....
msg61113 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2003-04-16 20:28
Logged In: YES 

Go for it.  It has a better chance at acceptance if it sticks to 
inquiry methods (e.g., tie it into adding a new mutable bit 
array type too, and the odds plummet).  Note that "bitwid" is 
an egregiously un-Pythonic abbreviation -- are you trying to 
save "th" at the end?  If so, don't.  Note the same methods 
will have to be added to ints too -- Python's trying to eradicate 
the user-visible differences between ints and longs, so adding 
methods unique to one of those types would llikely be 
rejected for that reason alone.

Don't forget popcount (number of 1 bits set); there and 
elsewhere, what to do about negative inputs will be 
contentious.  Following GMP's lead is better than making 
stuff up then.
msg61114 - (view) Author: Gregory Smith (gregsmith) Date: 2003-05-08 21:14
Logged In: YES 

Fair enough - it sounds like the additional methods, if
any, should be kept to a minimum, and some of the other
stuff that I want to do should maybe be in an add-on module
rather than an addition to the core language. if/When I have
time I'll write a PEP for the methods and maybe another one
for the array-of-bit support , or bitstream, or whatever it
winds up being. A goal here is to be able to do
variable-length coding/decoding in Python without
being too slow; if I can think up a more general-purpose
thing that  can do that, so much the better.

popcount I hadn't heard of, but Google just found it
for me in a Java lib. Definitely fits into the class of
things-which-go-much-faster-in-C. And yes, it makes a 
lot of sense to do this to ints and longs uniformly.

msg63057 - (view) Author: Facundo Batista (facundobatista) * (Python committer) Date: 2008-02-26 23:29
Gregory, you're keeping this as a recordatory (it passed almost five
years and a lot of water under "long" bridge), or can be closed?

Thank you!
msg81597 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-02-10 20:46
I recommend closing this due to lack of interest/PEP/patch.

2.7 and 3.1 now have n.bit_length(), which matches Gregory's proposed 

I'm semi-interested in the bit-access methods n.bit(x) and n.bit(hi, lo), 
but not enough to write a PEP or patch right now.

For n.bitarray(), it might be better to expose the 
_PyLong_{As,From}ByteArray methods instead.
msg81607 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-02-10 21:54
Date User Action Args
2009-02-10 21:54:32mark.dickinsonsetstatus: open -> closed
resolution: rejected
messages: + msg81607
2009-02-10 20:46:40mark.dickinsonsetnosy: + mark.dickinson
messages: + msg81597
2008-02-26 23:29:58facundobatistasetnosy: + facundobatista
messages: + msg63057
2003-04-16 18:07:16gregsmithcreate