[Python-bugs-list] [ python-Feature Requests-722647 ] lower-level API for longs
SourceForge.net
noreply@sourceforge.net
Wed, 16 Apr 2003 13:28:37 -0700
Feature Requests item #722647, was opened at 2003-04-16 14:07
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=722647&group_id=5470
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: lower-level API for longs
Initial Comment:
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....
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2003-04-16 16:28
Message:
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=722647&group_id=5470