commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] AbstractStorelessStats stores raw data.
Date Wed, 07 Aug 2013 00:17:49 GMT
On 8/6/13 7:27 AM, Ajo Fod wrote:
> Is this an issue then?

Best not to top-post.  Lets see if we get any other views on how the
setup may be improved.  Then when we have consensus that a design
change is warranted and what that change will be, we can open a
ticket to track the work.

> -Ajo
> On Fri, Aug 2, 2013 at 3:48 PM, Phil Steitz <> wrote:
>> On 8/2/13 3:09 PM, Ajo Fod wrote:
>>> The class design of AbstractStorelessStats (Storeless) suggests that it
>> is
>>> storing data in its parent AbstractUnivariate (Parent) and there are
>>> methods accesible to a child of this class that shouldn't be to something
>>> that is storeless in:
>>> private double[] storedData;
>>> ... perhaps Percentile etc should inherit from another subclass of the
>>> Parent?
>> I agree that there is no reason that
>> AbstractStorelessUnivariateStatistic should extend
>> AbstractUnivariateStatistic and the smelliness of exposing getData
>> in the child is a good reason for it *not* to.  I think the
>> implemented interfaces do make sense to inherit from one another,
>> but the abstract parents should be independent.  While cleaning this
>> up, I would also nuke the argumentless evaluate() from
>> AbstractUnivariateStatistic.
>> Percentile in its current implementation requires the data to be
>> stored in memory, so it is not a "storeless" - i.e., it should
>> inherit as it does from AbstractUnivariateStatistic.  We have been
>> talking about implementing a "storeless" approximation algorithm,
>> but that should go in a new class which would inherit from
>> AbstractStorelessUnivariateStatistic.
>> There may be other reasons that I don't remember for why the
>> abstract parent inheritence is there.  But those should be picked up
>> by the unit tests.  Any better ideas on how to achieve what we have
>> been achieving with these classes?  As I said above, as long as the
>> tests pass with only trivial mods, I am OK breaking the parent /
>> child on the abstract parents.  Now is a great time to think about
>> other ways to make the code easier to understand / use.
>> Phil
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message