[Boost-users] [accumulators] Is there a reset function yet?

[Tim Odenthal]

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
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

--
You received this message because you are subscribed to the Google Groups "BOOST Archives" group.
To post to this group, send email to boost...@googlegroups.com.
To unsubscribe from this group, send email to boost-list+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/boost-list?hl=en.

[Eric Niebler]

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

[John Dlugosz]

> > 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.