Eric Niebler wrote:
Hi,
The accumulators library doesn't mandate laziness or eagerness. As you've noticed, some accumulators come in lazy or eager flavors. Each accumulator defines an operator() that accepts a sample and a result() function that extracts the result. Whether the bulk of the work gets done in operator() (eager) or in result() (lazy) is up to you.
HTH,
Thanks for the reply, Eric. It's great that the framework doesn't force things one way or the other. I was particularly interested in some of the statistics supplied with the library. With your handy hint for determining laziness (i.e. operator() or result() ), I see in the code that moment<> is eager. It's just a nit, but the documentation for those statistics would be improved IMO if they stated that - this might be as easy as a blanket statement that supplied statistics are eager unless otherwise stated. For my purposes, I need lazy_moment<> which thanks to the framework you've come up with is very straightforward to implement. Then things like lazy_skewness and lazy_kurtosis will rapidly follow. These will have near identical implementations to the existing skewness and kurtosis statistics with the exception that all moment<n>s will be replaced by lazy_moment<n>s. Half of me thinks there could be value in templating over the "moment type" in such cases but perhaps that is over-engineering. In any case, if I did offer up lazy versions, might there be interest in including them in the library itself? Pete