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 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
<http://bugs.python.org/
Fredrik Johansson 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 mos
Fredrik Johansson 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 >&
Fredrik Johansson 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 as ``x.bi
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 fir
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
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
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 a
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,
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 funct
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.n
Changes by Fredrik Johansson <[EMAIL PROTECTED]>:
--
nosy: +fredrikj
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3944>
___
__
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 ne
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.pytho
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.
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 (inte
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
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
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):
htt
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 handlin
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.
>>> impor
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.
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 ld
24 matches
Mail list logo