Mark,
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:

>
> Mark Dickinson <dickinsm@gmail.com> added the comment:
>
> 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.
>
> __________________________________
> Tracker <report@bugs.python.org>
> <http://bugs.python.org/issue2819>
> __________________________________
>