Re: math.frexp

From	Chris Angelico <rosuav@gmail.com>
Newsgroups	comp.lang.python
Subject	Re: math.frexp
Date	2016-07-16 02:44 +1000
Message-ID	<mailman.23.1468601093.2307.python-list@python.org> (permalink)
References	<5788cb76$0$1599$c3e8da3$5496439d@news.astraweb.com> <CAPTjJmq=wGopxP_49b6CEjU-N8YbyGeWF85YW+5pe+T_Lsycpg@mail.gmail.com> <mailman.16.1468583297.2307.python-list@python.org> <5789101c$0$1615$c3e8da3$5496439d@news.astraweb.com> <CAPTjJmp2CgWtrgT273mP52oLGEm4T+M0JVXPdDfJPuSqwX8gAw@mail.gmail.com>

Show all headers | 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

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