On Sat, Jul 16, 2016 at 2:32 AM, Steven D'Aprano <st...@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 -- https://mail.python.org/mailman/listinfo/python-list
