>
> One more sort of philosphical point that makes me want to keep
> Univariates as
> objects with statistics as properties: to me a Univariate is in
> fact a java
> bean. It's state is the data that it is characterizing and its
> properties are
> the statistics describing these data.
And why can't these statistics be objects? Objects that are smart in that
they know how to modify themselves. Currently, univariate has all that
knowledge which will get more complex with every new statistic. The object
approach places the responsibility of data update and computation where it
belongs, internal to the statistic.
> You are confusing strategies with implementations. The
> rootfinding framework
> exists to support multiple strategies to do rootfinding, not to support
> arbitrary numerical methods. A better analogy would be to the distribution
> framework which supports creation of different probability
> distributions. You
> could argue that a "statistic" is as natural an abstraction as a
> probability
> distribution. I disagree with that. There is lots of structure in a
> probability distribution, very little in a statistic from an abstract
> standpoint.
But the simple abstractions are always the most useful. They are more
easily adapted, reused, and understood.
> I disagree. Extending a class or adding a method to an interface
> is no harder
> than adding a new class (actually easier). It seems ridiculous
> to me to add a
> new class for each univariate statistic that we want to support.
Funny. You just suggested a way to support additional statistics is by
creating a new class via extension. Yet you claim adding a new class for a
statistic is ridiculous. Are you saying your idea is ridiculous?
> If the stats
> are going to be meaningfully integrated, they will have to be
> used/defined by
> the core univariate classes any way, unless your idea is to
> eliminate these and
> force users think about statistics one at a time instead of as part of a
> univariate statistical summary.
You can easily create a univariate class that is openended to the
statistics that it computes and treat them as a logical set. One would
create a univariate and any set of statistic objects. Then you would add
data to the univariate which would in turn pass the data to each of the
statistic objects.
The statistic objects then take that the data and update themselves. Now we
have a univariate that can compute any statistic, either one provided by
commonsmath or one created by a user, on a needs basis and not the
allornothing approach.
> This may be the crux of our
> disagreement. I
> see the statistics as natural properties of a set of data, not meaningful
> objects in their own right.
And what limits properties to be only dumb data values? With your logic,
objects such as Calendars, Colors, and InputStream could not be used as
properties. Currently, univariate has the responsibility of computing a
mean. Taking that responsibility away from univariate and giving it to a
statistic object makes that object tremendously meaningful.
>
> We are always going to have to discuss what goes in to
> commonsmath and what
> does not go in, regardless of how packages are organized. For
> example, I would
> be opposed (as I suspect J, Al and Brent would be too) to adding
> a Newton's
> method solver now, since it would provide no value beyond what we
> already have.
> This has nothing to do with how the package is organized.
>
> I would like to propose the following compromise solution that
> allows the kind
> of flexibility that you want without breaking things apart as much.
>
> 1. Rename StoreUnivariate to ExtendedUnivariate and change all
> other "Store"
> names to "Extended".
Changing the name doesn't make the design any better. Do you think if
Microsoft had named Windows, Portals, it would be a better OS?
>
> 2. Make the methods in StatUtils nonstatic. Continue to use
> these for basic
> computational methods shared by Univariate and ExtendedUnivariate
> implementations and for direct use by applications and elsewhere in
> commonsmath. These methods do not have to be used by all Univariate
> implementation strategies.
>
> 3. Add addValues methods to Univariate that accept double[], List and
> Collection with property name and eliminate ListUnivariate and
> BeanListUnivariate.
With that you just tripled the complexity of univariate. And as a result,
tripled the complexity of adding a statistic, tripled the likelihood of
introducing errors with each change, tripled this, tripled that. It's in
yet obvious this is flawed?
>
> 4. Rename UnivariateImpl to SimpleUnivariate and add a
> UnivariateFactory with
> factory methods to create Simple, Extended and whatever other sorts of
> Univariates we may define.
>
> To add new statistics or computational strategies in this
> environment, we can
> a) add to the Univariate interface if we think that they are
> really basic  I
> think that tbased confidence interval halfwidth for the mean is
> a basic stat
> that is now missing
Yes. And if you were a user, with the currently implementation, there is
nothing you could do about it but pray it'll be added in the next release of
commonsmath. However, with the object approach, you'd create a simple
statistic object that can be used with univariate and all your troubles go
away.
> for example b) add to the ExtendedUnivariate
> interface c)
> extend an existing Univariate implementation to add the new
> statistic or d)
> create a new Univariate including the new statistic or
> computational strategy.
> U
Again, you yourself labeled c and d as ridiculous when you labeled Mark's
idea of adding a class for each statistic as such.
The current univariates have encapsulated way too much responsibility
instead of delegating it to other objects. This makes the code very
unstable as it will need to change frequently. As I see it, the univariate
types are responsible for two things: maintaining a window of data and
computing summary statistics
I would suggest separating each of these responsibilities into separate
objects. I would make a window policy object that knows if/when data values
should be removed when others are added and if individual data values are
accessible. I would make a statistics strategy object that knows what
statistics to compute and how to compute them based on the window policy.
The univariate would act as a mediator between the two objects. I like
Mark's approach, but I think I would take it a little further in terms of
abstraction by making univariate independent of the statistics its
calculating.
Brent Worden
http://www.brent.worden.org

To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
