Jean Brouwers <[EMAIL PROTECTED]> added the comment: I did not compare performance (yet). If there is a particular test case, I am happy to measure that. Also, I made sure that the results and errors (!) for non-numeric items are the same as for the original, Slow Summation case.
The version I submitted is perhaps only slightly faster for most int and float cases, since it never creates and adds the 0 int default for the optional 'start' argument. For other int and float cases it will certainly be faster. Here are a few (extreme) examples. 1) Assume a long list consisting of one float followed by all ints. The existing code will switch to the float loop at the very first float encountered and then use C double add (plus the FPE protection overhead) to add all subsequent ints. My version will use C long adds for all ints, C double add for the float plus one C double add to combine the long and double results. 2) Consider a list of just 2 items, one float and one int (and no 'start' argument). The current code will first create a result object for the 'start' default 0. Then, it enters the int loop (since result is an int, 0) and gets the first item, the float. Since the item is not an int, it is added to the current result using PyNumber_Add. Next, it falls into the float loop, since the result is now a float, presumably. Next, it gets the int item and adds that int as C double to the C double in f_result. The end result C double f_result is returned as float. Quite costly for just one float and one int and maybe worse than than Slow Summation. 3) My version does not create a 0 int for the missing 'start'. That is only created when absolutely needed at some later time. In addition, all int items are added in C long i_sum and all floats are added in C double f_sum, regardless of the order they occur in the sequence. At the end of the iteration loop, the C long i_sum is added to C double f_sum once and a single float object is created and returned. That is very efficient and without any unnecessary overhead. In other words, for sequences with mixed int and float objects the difference can be significant, depending on where the very first float item is located in the sequence and how may int follow. However, for sequences with items of the same type, all int or all float, there will be little or no difference. /Jean Brouwers PS) There are two additional things to consider for the float case: - Ooverflow (ERANGE) and value (EDOM) errors in C double adds - Using a compensating summation for floats, like Kahan's method. __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2785> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
