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 reduce(mul, values)
>
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
precision you have after th
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 of precision.
Simplest
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.
--
https://mail.python.org/mailman/listinfo/python-list
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, 2.0*
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:
>
> 2.0, 1e200, 1e200, 1e
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 approach
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 e
On Fri, Jul 15, 2016 at 9:39 PM, Steven D'Aprano 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)
> 8.75
>
>
>
uct_naive([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
10 matches
Mail list logo
