[accumulators] Is there a reset function yet?

Hi! I just discovered this nice functionality in boost, but while trying something as simple as calculating a mean from a set of numbers, I hit a strange drawback: It seems to be impossible to use the same accumulator again for a different set of numbers, because I cannot clear/ reset it. I found some old (ok, March 2009) discussions about this, but nothing in the documentation. By the way, does the accumulator do something to prevent an overflow when I add up everything into one variable? And does it prevent a loss of precision, when at a late stage the variable I sum everything into is very big, but the thing I add is very small? Maybe it would be a good idea to mention this in the documentation, as well... Many thanks in advance for any help Tim

On 5/21/2010 8:18 AM, Tim Odenthal wrote:
Hi!
I just discovered this nice functionality in boost, but while trying something as simple as calculating a mean from a set of numbers, I hit a strange drawback:
It seems to be impossible to use the same accumulator again for a different set of numbers, because I cannot clear/ reset it. I found some old (ok, March 2009) discussions about this, but nothing in the documentation.
No, accumulator_set::reset is not implemented yet. As others noted in the thread you found, you can assign to it a similarly initialized accumulator_set to get back to its original state.
By the way, does the accumulator do something to prevent an overflow when I add up everything into one variable?
No. It uses native intrinsics for raw performance. If you want anything fancy, you can use your own UDT for samples that check for overflow. Some construction required. :-( If you do build such a thing, I would consider making it an official part of Accumulators.
And does it prevent a loss of precision, when at a late stage the variable I sum everything into is very big, but the thing I add is very small?
No. See above.
Maybe it would be a good idea to mention this in the documentation, as well...
Indeed. Could you file a ticket at http://svn.boost.org so this doesn't get lost? Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

By the way, does the accumulator do something to prevent an overflow when I add up everything into one variable?
No. It uses native intrinsics for raw performance. If you want anything fancy, you can use your own UDT for samples that check for overflow. Some construction required. :-( If you do build such a thing, I would consider making it an official part of Accumulators. Eric Niebler BoostPro Computing
Hey Eric, I wonder, did we cross paths back in the day, on Compuserve like DDJFORUM or CLMFORUM? Your name is familiar. I faced a similar overflow problem for general work. I'm worried about adding signed and unsigned types, as well as different sizes of ints. I made an overflow_add and overflow_subtract template that just does the work in a larger type if one is available, and does necessary checking for the largest type. Rather than declare variables of some "checked" wrapper with its own overloaded operators, I just use overflow_add occasionally where needed. It really bugs me that I could not draw upon the CPU's native checking. It knows! So why do I have to go out of my way to figure it out based on primitive principles? I haven't done much writing lately, but I could share this with someone who wants to discuss it. It would need a little work to make it more portable: I know what the largest type is. Boost has a module that does fancy casting between integral types that is rather configurable; I know that an error is an overflow exception. Undoubtedly the "policy" can be separated out from the tricky part of actually doing the detection for every possible case, making that reusable in a larger sense. --John John M. Dlugosz TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
participants (3)
-
Eric Niebler
-
John Dlugosz
-
Tim Odenthal