Re: math.frexp

2016-07-15 13:39 GMT+02:00 Steven D'Aprano : > I'm experimenting with various implementations of product(values). Here's a > naive version that easily suffers from overflow: > > from functools import reduce > from operator import mul > > def product_naive(values): > return

Re: math.frexp

Steven D'Aprano writes: >>> protection against overflow of intermediate values. >> Might be simplest to just add the logarithms. > Simplest, but least accurate, even with Kahan summation or equivalent. Well the idea was to avoid overflow first, then hold on to whatever

Re: math.frexp

On Sat, 16 Jul 2016 06:24 am, Paul Rubin wrote: > Steven D'Aprano writes: >> But this can give some protection against overflow of intermediate >> values. > > Might be simplest to just add the logarithms. Look up Kahan summation > for how to do that while minimizing loss

Re: math.frexp

Steven D'Aprano writes: > But this can give some protection against overflow of intermediate > values. Might be simplest to just add the logarithms. Look up Kahan summation for how to do that while minimizing loss of precision. --

Re: math.frexp

On Fri, Jul 15, 2016, at 12:32, Steven D'Aprano wrote: > I can take the geometric mean of: > > [2.0**900, 2.0**920, 2.0**960, 2.0**980, 2.0**990] > > and get to within a relative error of 1e-14 of the correct answer, > 2**950: > > py> geometric_mean([2.0**900, 2.0**920, 2.0**960, 2.0**980,

Re: math.frexp

On Sat, Jul 16, 2016 at 2:32 AM, Steven D'Aprano wrote: > If the result is too big to be represented as a float at the end of the > product, then of course it will overflow. But this can give some protection > against overflow of intermediate values. Consider multiplying: > >

Re: math.frexp

On Fri, 15 Jul 2016 21:39:31 +1000, Steven D'Aprano wrote: > prod *= (m1*m2) Should be: prod = m1*m2 or: prod *= m1 (in the latter case, there's no point in decomposing prod). Of course, if the result overflows, it's going to overflow whether you use the naive

Re: math.frexp

On Fri, 15 Jul 2016 09:48 pm, Chris Angelico wrote: >> py> product_scaled([2.5, 3.5]) # expected 8.75 >> 2.734375 >> > > You're chaining your product twice. (Also your scale, although that > appears to be correct.) Changing it to "prod = m1 * m2" gives 8.75. D'oh! Thanks! I needed some fresh

Re: math.frexp

On Fri, Jul 15, 2016 at 9:39 PM, Steven D'Aprano <st...@pearwood.info> wrote: > py> from math import frexp > py> x = 2.5 > py> y = 3.5 > py> x*y > 8.75 > py> m1, e1 = math.frexp(x) > py> m2, e2 = math.frexp(y) > py> m1*m2 * 2.0**(e1 + e2) >

math.frexp

[1e200, 1e200, 1e200]) inf So I started experimenting with math.frexp, but I'm having trouble understanding what I'm doing wrong here. Help on built-in function frexp in module math: frexp(...) frexp(x) Return the mantissa and exponent of x, as pair (m, e). m is a float and e is

[issue3439] math.frexp and obtaining the bit size of a large integer

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

[issue3439] math.frexp and obtaining the bit size of a large integer

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

[issue3439] math.frexp and obtaining the bit size of a large integer

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. --

[issue3439] math.frexp and obtaining the bit size of a large integer

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)?

[issue3439] math.frexp and obtaining the bit size of a large integer

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

[issue3439] math.frexp and obtaining the bit size of a large integer

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

[issue3439] math.frexp and obtaining the bit size of a large integer

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 +

[issue3439] math.frexp and obtaining the bit size of a large integer

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:

[issue3439] math.frexp and obtaining the bit size of a large integer

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

[issue3439] math.frexp and obtaining the bit size of a large integer

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 ___

[issue3439] math.frexp and obtaining the bit size of a large integer

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]

[issue3439] math.frexp and obtaining the bit size of a large integer

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

[issue3439] math.frexp and obtaining the bit size of a large integer

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

[issue3439] math.frexp and obtaining the bit size of a large integer

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