On Thu, 15 Jan 2015 15:09:29 -0700, Phil Steitz wrote:
On 1/15/15 9:50 AM, Gilles wrote:
On Thu, 15 Jan 2015 10:02:32 +0100, Adriean Khisbe wrote:
Hi,
Working on a project I had to capture current state of a
DescriptiveStatistics, and choosed to use a
StatisticalSummaryValues
to hold the value.
I looked it if was possible to do it in one short method call, but
didn't found the method.
Good point. We should add this.
However I found some equivalent in SummaryStatistics:
/** * Return a {@link StatisticalSummaryValues} instance
reporting current * statistics. * @return Current values of
statistics */ public StatisticalSummary getSummary() {
return new StatisticalSummaryValues(getMean(), getVariance(),
getN(),
getMax(), getMin(), getSum()); }
Might be a good thing to port this functionnality in
DescriptiveStatistics so ones can do
recap.getSummary()instead
of
new StatisticalSummaryValues(recap.getMean(),
recap.getVariance(), recap.getN(),
recap.getMax(),
recap.getMin(), recap.getSum())
What do you think about this?
Personally, I don't like the "...Values" class.
I think that it should be a private inner class of
"SummaryStatistics"
(or package-private).
I like it and use it a lot. It is a handy way to persist / pass
around the results of a SummaryStatistics calculation - basically a
value object.
I wonder whether, to capture the state, we could have a
Map<DataTypeId, Double> getState()
method, where "DataTypeId" would either be an "enum" or a "String".
The problem with the data bag type approach to these things is there
is no type safety and you can end up with nasty bugs due to things
not being in the bag that you expect. If you try to make it safe by
making the DataTypeID an enum, you have just created an excessively
complicated value object - basically, engineering your own get/set
property mgt.
You might be right; I didn't think a lot about it.
Then couldn't "StatisticalSummary" itself be that enum rather than
an interface (since it seems to only enumerate data and have no
"behaviour")?
As I said above, what we need is a simple value object. I am fine
with dispensing with the interface though. What is useful is the
value object.
If so, I'd insist that each class provides its _own_ "Values" type,
as an inner class (to be as close as possible to the producer), thus:
StatisticalSummary.Values (instead of "StatisticalSummaryValues")
DescriptiveStatistics.Values
etc.
Gilles
For DescriptiveStatistics, the set of statistics is different, so I
would suggest we just add DescriptiveStatisticsValues and a
getSummary or getResults() method that returns one of those.
Patches welcome.
Phil
Regards,
Gilles
Regards :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
