Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #111483

Re: math.frexp

Show key headers only | View raw

On Sat, Jul 16, 2016 at 2:32 AM, Steven D'Aprano <steve@pearwood.info> 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-200, 1e-200, 3.0
>
>
> Mathematically, the answer should be 6. In principle, by rescaling when
> needed to prevent overflow (or underflow), product() should be able to get
> something very close to 6, if not exactly 6.

I was under the impression that appropriate reordering of the elements
could prevent over/underflow and maximize accuracy, but that may be a
mistaken memory. However...

> But I'm not actually writing a general product() function. I'm doing this
> for geometric mean, so I return the scaling exponent and the mantissa[1]
> separately, and then take the nth-root of them individually, before
> combining them into the final result.

... this makes a lot of sense. In effect, I *think*, you're basically
doing the multiplication on something rather larger than a 64-bit IEEE
float, then taking the nth-root, and then combine them and convert
back to float. Is this about right?

ChrisA

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

math.frexp Steven D'Aprano <steve@pearwood.info> - 2016-07-15 21:39 +1000
  Re: math.frexp Chris Angelico <rosuav@gmail.com> - 2016-07-15 21:48 +1000
    Re: math.frexp Steven D'Aprano <steve@pearwood.info> - 2016-07-16 02:32 +1000
      Re: math.frexp Chris Angelico <rosuav@gmail.com> - 2016-07-16 02:44 +1000
      Re: math.frexp Random832 <random832@fastmail.com> - 2016-07-15 14:28 -0400
      Re: math.frexp Paul Rubin <no.email@nospam.invalid> - 2016-07-15 13:24 -0700
        Re: math.frexp Steven D'Aprano <steve@pearwood.info> - 2016-07-16 20:21 +1000
          Re: math.frexp Paul Rubin <no.email@nospam.invalid> - 2016-07-16 12:49 -0700
  Re: math.frexp Nobody <nobody@nowhere.invalid> - 2016-07-15 17:39 +0100
  Re: math.frexp Vlastimil Brom <vlastimil.brom@gmail.com> - 2016-07-17 01:18 +0200

csiph-web