Issue722647
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: e.g. 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) * ![]() |
Date: 2003-04-16 20:28 | |
Logged In: YES user_id=31435 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 user_id=292741 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 some 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) * ![]() |
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) * ![]() |
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 n.bitwid(). 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) * ![]() |
Date: 2009-02-10 21:54 | |
Closing. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2009-02-10 21:54:32 | mark.dickinson | set | status: open -> closed resolution: rejected messages: + msg81607 |
2009-02-10 20:46:40 | mark.dickinson | set | nosy:
+ mark.dickinson messages: + msg81597 |
2008-02-26 23:29:58 | facundobatista | set | nosy:
+ facundobatista messages: + msg63057 |
2003-04-16 18:07:16 | gregsmith | create |