math.frexp

[Chris Angelico]

On Sat, Jul 16, 2016 at 2:32 AM, Steven D'Aprano <steve at 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