Fredrik Johansson added the comment:
I can think of two reasons to extend floor() and ceil() to complex numbers, and
they lead to different extensions.
The first is as a way to map complex numbers to nearby Gaussian integers by
defining floor(z) = floor(z.real) + floor(z.imag)*1j, etc
Fredrik Johansson fredrik.johans...@gmail.com added the comment:
I think datetime division would be a fine application for Fractions.
--
message_count: 18.0 - 19.0
nosy: +fredrikj
nosy_count: 7.0 - 8.0
___
Python tracker rep...@bugs.python.org
http
Fredrik Johansson fredrik.johans...@gmail.com added the comment:
I understand the connection with itertools, but why not just call a
binomial coefficient a binomial coefficient? Probably 90% of all math
libraries call this function 'binomial' or 'bincoef' and I suspect
that's the name most
Fredrik Johansson fredrik.johans...@gmail.com added the comment:
When did the name change back to numbits? Anyway, I think this reference
implementation is better:
def numbits(x):
x = abs(x)
n = 0
while x:
n += 1
x //= 2
return n
(//= 2 could be changed to = 1
Fredrik Johansson fredrik.johans...@gmail.com added the comment:
FYI, Brent Zimmermann call this function nbits(n) in Modern Computer
Arithmetic: http://www.loria.fr/~zimmerma/mca/pub226.html
I don't really care much about the name though.
In the documentation, should same value
Fredrik Johansson [EMAIL PROTECTED] added the comment:
In stdtypes.rst, x.numbits should be listed in the table under
Bit-string Operations on Integer Types and not in the table of
operations supported by all numeric types.
(1) the number of bits should be computed first directly using C
Fredrik Johansson [EMAIL PROTECTED] added the comment:
I propose to close this as won't fix; I'm not interested in 150ms
speed differences when dividing 10 digit numbers.
Sure.
(I care about differences like this, because they have a tendency to add
up. But it's a minor issue
Fredrik Johansson [EMAIL PROTECTED] added the comment:
The speed difference comes from different compiler options.
I figured as much. I'm using the binaries from python.org (see the .txt
file; it includes version headers).
The question is why the compilation changes for 2.6 slowed down
New submission from Fredrik Johansson [EMAIL PROTECTED]:
On my laptop (Windows XP, 32-bit), long division is about 15% slower in
2.6 compared to 2.5. See the attached .txt for timings.
I noticed this when comparing the unit tests for mpmath
(http://code.google.com/p/mpmath/) under 2.5 and 2.6
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
Fredrik Johansson [EMAIL PROTECTED] added the comment:
Another tack is to notice that numbits is the length of the bit sequence
representation of an int (excepting 0) and give ints a .__len__ method
;-). I would not expect that suggestion to fly very far, though.
FWIW, I'm one of the people
Fredrik Johansson [EMAIL PROTECTED] added the comment:
One other note: in Fredrik's patch there's commented out code for a
numbits *property* (rather than a method). Is there any good reason to
make this a property?
Aesthetically, I think numbits as a function would make more sense
Changes by Fredrik Johansson [EMAIL PROTECTED]:
--
nosy: +fredrikj
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3944
___
___
Python-bugs-list mailing
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
Fredrik Johansson [EMAIL PROTECTED] added the comment:
Indeed, that seems to be much faster. In the mean time, do you mind if I
steal the code? :-)
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3451
New submission from Fredrik Johansson [EMAIL PROTECTED]:
The docstring for random.Random mentions a method getrandombits().
Surely this should be getrandbits()?
This ghost method is also mentioned in the Library Reference page for
the random module.
--
assignee: georg.brandl
components
Fredrik Johansson [EMAIL PROTECTED] added the comment:
Yes, definitely! Though it depends a little bit how much complication
is involved.
Not that much, I think, the pure Python version being just a few lines
of code (plus a few more lines of boilerplate). But I'm not too familiar
Fredrik Johansson [EMAIL PROTECTED] added the comment:
For your convenience, I have split the division and numeral code off to
a standalone .py file which I'm attaching here.
I also updated the remainder logic to use the default divmod instead of
repeated subtraction, which ensures worst-case
Fredrik Johansson [EMAIL PROTECTED] added the comment:
And here some timings on my laptop.
Both int-str and balanced division become faster somewhere between 1000
and 2000 digits. This is after editing the division benchmark to use
random numbers instead of exact powers of ten (interestingly
New submission from Fredrik Johansson [EMAIL PROTECTED]:
A few weeks ago, I blogged about taking advantage of Karatsuba
multiplication and Newton's method to divide big integers quickly (some
of you may have read it, as it was posted to Daily Python-URL among
other places):
http://fredrik
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
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
Fredrik Johansson [EMAIL PROTECTED] added the comment:
I'm not qualified to comment on the implementation. The test cases all
look right.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2487
New submission from Fredrik Johansson [EMAIL PROTECTED]:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
Type help, copyright, credits or license for more information.
from math import ldexp
from sys import maxint
ldexp(1.234, maxint//2)
Traceback (most
24 matches
Mail list logo
