On 7/26/2010 1:59 PM, Gaetano Mendola wrote:
On 07/26/2010 06:55 PM, Jeffrey Lee Hellrung, Jr. wrote:
Or is the proposition to replace the (naive) summation algorithm with kahan summation algorithm for only floating point types?
A possible scenario can be:
1) Leave the naive summation algorith as it is now 2) Create (with a typedef?) fast_sum that is the same of sum (naive) 2) Rename the sum_kahan as accurate_sum implemented as sum (naive) 3) Specialize the accurate_sum for floating points types implemented as the real kahan's algorithm
however this can lead to have someone using accurate_sum for integral type and find it out is not accurate at all !
IMHO "accurate" or "fast" are missleading. What if someone comes out with an algorithm that gives better results and even faster than actual implementation?
Think about how many sorting algorithms there are out there.
I think the best is to leave sum as it is now (no complains about someone's regression tests failing), implement the sum_kahan only for floating types and have it listed in documentation specifying that is implemented only for floating types. The string Kahan in the name will also give to users the hint on what it does and what the performance loss is going to be.
That's perfectly reasonable, but care must be taken that the sum_kahan satisfies any dependency on the "sum" feature. That is, if someone asks for "mean" (which depends on a "sum" feature) and "sum_kahan", they don't get "mean", "sum", and "sum_kahan". The accumulators library makes this pretty straightforward.
BTW, what's the procedure to submit something officially to boost?
In this case, you would open a feature request on svn.boost.org ("New Ticket"), assign to me, and attach your patch. If it looks good, I'll merge it. Your patch should have docs and tests. Don't worry about formatting the docs. I can do that. I wouldn't ask you to set up the doc build chain; it's a headache. Thanks! -- Eric Niebler BoostPro Computing http://www.boostpro.com