Thank you very much for your comments. Here is my initial response to the first 3.
(1) Attached is an attempt to address the 1st issue (just the mathmodule). The macros PyFPE_START_PROTECT/_END_PROTECT have been moved outside the main loop and the errno is set following the IEEE 754 rules as you suggested.
One related issue is testing these, how can a NaN and +/-Infinity float object be created in Python?
(2) On your 2nd comment, supporting non-IEEE floating point, perhaps the Kahan method should be used in that case. If so, the next question is how to detect that? There are two symbols in pyconfig.h HAVE_IEEEFP_H and HAVE_LIBIEEE. Are those the proper ones to determine IEEE floating point support?
(3) On the 3rd comment, Raymond and I did discus using a single function to be called by the math and cmath modules. The question is where should that function reside? The math and cmath modules are not the right place since both are loadable modules. It will have to be somewhere inside the Python main/core.
Also, depending on the implementation of that function, it may require iterating the complex sequence twice. And that will force the C complex numbers to be created twice by the PyComplex_AsCComplex() call. Would that be a concern?
/Jean Brouwers
On Sun, May 11, 2008 at 1:49 PM, Mark Dickinson <
report@bugs.python.org> wrote:
One more question:
What are the use cases for an exact summation algorithm? That is, in what
situations does one care about exactness rather than simply accuracy? I
know that loss of accuracy is a problem in things like numeric integration
routines, but something like Kahan summation (faster and simpler, but not
exact) usually takes care of that.