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 aleax, mark.dickinson, pitrou, remi.lapeyre, rhettinger, serhiy.storchaka, tim.peters, vstinner, xtreak
Date 2019-01-06.06:26:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1546756018.68.0.673382172365.issue35606@roundup.psfhosted.org>
In-reply-to
Content
I'd like to divorce `prod()` from floating-point complications.  The `sum()` builtin has proved extremely handy, even for floats, in large part because it's type-agnostic and straightforward.  While I'd usually use `prod()` on ints and Fractions, in almost all cases I have for multiplying floats a dirt simple implementation would work fine too (e.g., I don't multiply NaNs or infinities to begin with, overflow and underflow can't occur in context, and I usually couldn't care less about the accuracy of the trailing bits).

Not that floats should suffer benign neglect forever, but heroically complex - and expensive - float implementations should get their own function, like `fprod()` (like they got their own `fsum()` function).  Likewise if, e.g., someone wants an `iprod()` that makes heroic efforts to reorder partial products to speed multiplying sequences of giant integers, or `matprod()` to re-associate matrix multiplications in an optimal way, or ...
History
Date User Action Args
2019-01-06 06:27:00tim.peterssetrecipients: + tim.peters, aleax, rhettinger, mark.dickinson, pitrou, vstinner, serhiy.storchaka, remi.lapeyre, xtreak
2019-01-06 06:26:58tim.peterssetmessageid: <1546756018.68.0.673382172365.issue35606@roundup.psfhosted.org>
2019-01-06 06:26:58tim.peterslinkissue35606 messages
2019-01-06 06:26:58tim.peterscreate