[functor] New components: summarize and aggregate
-------------------------------------------------
Key: SANDBOX-341
URL: https://issues.apache.org/jira/browse/SANDBOX-341
Project: Commons Sandbox
Issue Type: Improvement
Components: Functor
Environment: JDK 1.6.0_25 but should work with any JDK 5+ (possibly
1.4 though I haven't tested).
Reporter: Liviu Tudor
Priority: Minor
Attachments: commons-functor-aggregate+summarizer.zip
This is the next step from https://issues.apache.org/jira/browse/SANDBOX-340 --
as instructed I'm finally hoping to get the code in the right place and
hopefully this is something that the functor component could do with.
Whereas initially I just started with the summarizer component, I have added
now the second one, the "aggregator" as they are somehow related. If this code
proves to be useful to functor in any way, it would actually be good to get
some feedback on these 2 to see if the class hierarchy can in fact be changed
to share some common functionality as I feel (probably due to the similar needs
that lead to writing/using these components) that somehow they should share a
common base.
In brief, the 2 components:
* aggregator: this just allows for data to be aggregated in a user defined way
(e.g. stored in a list for the purpose of averaging, computing the arithmetic
median etc). The classes provided actually offer the implementation for storing
data in a list and computing the above-mentioned values or summing up
everything.
* timed summarizer: this is another variation of the aggreator, however, it
adds the idea of regular "flushes", so based on a timer it will reset the value
and start summing/aggregating the data again. Rather than using an aggregator
which would store the whole data series (possibly for applying more complex
formulas), this component just computes on the fly on each request the formula
and stores the result of it. (Which does mean things like computing arithmetic
mean, median etc would be difficult to compute without knowing upfront how many
calls will be received -- i.e. how many elements we will be required to
summarize/aggregate.) So the memory footprint of running this is much smaller
-- even though, as I said, it achieves similar results. I have only provided a
summarizer which operates on integers, but obviously others for float, double
etc can be created if we go ahead with this design.
Hopefully the above make sense; this code has resulted from finding myself
writing similar components to these a few times and because it's always been
either one type (e.g. aggregator) or another (summarizer) I haven't given quite
possibly enough thought to the class design to join these 2. Also,
unfortunately, the time I sat down to make these components a bit more general
and submitted issue 340 was nearly 3 months ago so I'm trying to remember
myself all the ideas I had at a time so bear with me please if these are still
a bit fuzzy :) However, if you can make use of these I'm quite happy to
elaborate on areas that are unclear and obviously put some effort into getting
these components to the standards required to put these into a release.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
