Fredrik Johansson [EMAIL PROTECTED] added the comment:
Some elaboration (that perhaps could be adapted into the documentation
or at least source comments).
There are two primary uses for numbits, both of which justify
(0).numbits() == 0.
The first is that for positive k, n = k.numbits() gives
STINNER Victor [EMAIL PROTECTED] added the comment:
See also issue #3724 which proposes to support long integers for
math.log2().
--
nosy: +haypo
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3439
Terry J. Reedy [EMAIL PROTECTED] added the comment:
To add support to the proposal: there is currently yet another thread on
c.l.p on how to calculate numbits efficiently. The OP needs it for
prototyping cryptographic algorithms and found Python-level code slower
than he wanted.
--
Fredrik Johansson [EMAIL PROTECTED] added the comment:
Wow, newbie error. Thanks for spotting!
In every case I can think of, I've wanted (0).numbits() to be 0. The
explanation in the docstring can probably be improved. What other
documentation is needed (where)?
Mark Dickinson [EMAIL PROTECTED] added the comment:
In every case I can think of, I've wanted (0).numbits() to be 0.
Me too, in most cases, though I've encountered the occasional case where
raising ValueError would be more appropriate and would catch some bugs
that might otherwise pass
Mark Dickinson [EMAIL PROTECTED] added the comment:
With the patch, the following code causes a
non-keyboard-interruptible interpreter hang.
from sys import maxint
(-maxint-1).numbits()
[... interpreter hang ...]
The culprit is, of course, the statement
if (n 0)
n = -n;
in
Mark Dickinson [EMAIL PROTECTED] added the comment:
One possible fix would be to compute the absolute value
of n as an unsigned long. I *think* the following is
portable and avoids any undefined behaviour coming
from signed arithmetic overflow.
unsigned long absn;
if (n 0)
absn = 1 +
Mark Dickinson [EMAIL PROTECTED] added the comment:
I'd also be interested in having _PyLong_NumBits exposed to Python in some
way or another. It's something I've needed many times before, and it's
used in the decimal module, for example.
My favorite workaround uses hex instead of bin:
New submission from Fredrik Johansson [EMAIL PROTECTED]:
Python 3.0b2 (r30b2:65106, Jul 18 2008, 18:44:17) [MSC v.1500 32 bit
(Intel)] on
win32
Type help, copyright, credits or license for more information.
import math
math.frexp(10**100)
(0.5714936956411375, 333)
math.frexp(10**1000)
Martin v. Löwis [EMAIL PROTECTED] added the comment:
Would you like to work on a patch?
--
nosy: +loewis
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3439
___
Raymond Hettinger [EMAIL PROTECTED] added the comment:
I prefer your idea to expose PyLong_Numbits(). IMO, frexp() is very
much a floating point concept and should probably remain that way.
--
nosy: +rhettinger
___
Python tracker [EMAIL PROTECTED]
Raymond Hettinger [EMAIL PROTECTED] added the comment:
Another reason to leave frexp() untouched is that it is tightly
coupled to ldexp() as its inverse, for a lossless roundtrip:
assert ldexp(*frexp(pi)) == pi
This relationship is bound to get mucked-up or confused if frexp starts
Fredrik Johansson [EMAIL PROTECTED] added the comment:
Raymond, yes, I think that a separate numbits function would better,
although exposing this functionality would not prevent also changing the
behavior of frexp. As I said, math.log already knows about long
integers, so handling long integers
Raymond Hettinger [EMAIL PROTECTED] added the comment:
numbers.Integral is already way too fat of an API. Am -1 on expanding
it further. Recommend sticking with the simplest, least invasive,
least pervasive version of your request, a numbits() method for ints.
FWIW, in Py2.6 you can already
14 matches
Mail list logo
