This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients Jeffrey.Kintscher, mark.dickinson, pablogsal, rhettinger, tim.peters, veky
Date 2020-08-06.23:57:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Cool!  So looks like you could also address an accuracy (not out-of-range) thing the frexp() method also does as well as possible: loosen the definition of "underflow" to include losing bits to subnormal products. For example, with the inputs

>>> xs = [1e-200, 1e-121, 1e308]
>>> product(xs)
>>> _.hex()
>>> # same thing
>>> prod2(xs) # a tiny implementation of the frexp() method
>>> _.hex()

product/ get only a handful of the leading result bits right, because

>>> 1e-200 * 1e-121
>>> _.hex()

loses all but a handful of the trailing bits due to being in the subnormal range.  Changing the order can repair that:

>>> 1e-200 * 1e308 * 1e-121

IOW, so far as "underflow" goes, we _start_ losing bits when the product becomes subnormal, well before it reaches 0.
Date User Action Args
2020-08-06 23:57:47tim.peterssetrecipients: + tim.peters, rhettinger, mark.dickinson, veky, pablogsal, Jeffrey.Kintscher
2020-08-06 23:57:47tim.peterssetmessageid: <>
2020-08-06 23:57:47tim.peterslinkissue41458 messages
2020-08-06 23:57:47tim.peterscreate