On 1/15/15 4:41 PM, Gilles wrote:
> 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
The synchronized versions also produce these. Why insist on the
two-level names?
Phil
>
>
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
