commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brent Worden" <>
Subject RE: [math] Static Utils and Methods
Date Thu, 12 Jun 2003 05:38:51 GMT
> -----Original Message-----
> From: Mark R. Diggory []
> Brent Worden wrote:
> > On the discussion of MathUtils, StatUtils and the placement of the
> > average(double, double) method, if the method name was changed
> to midpoint,
> > would people prefer it be place in MathUtils, StatUtils, or up
> my keester.
> > Please, limit your replies to two emails.
> >
> > :-)
> >
> > Brent Worden
> >
> I would say, "up your keester"! ;-)
> Brent, this is all grounds for establishing the organization of the
> packages and the overall design process of the project, its all a very
> excellent discussion. :-) thanks...
> I think "midpoint" is somewhat vague too. Ok, maybe we can get a little
> deeper into this using your case as an example.
> (1) What are your requirements/needs for an "average(double, double)"
> style static method?

This is more of "looking to the future" need than anything else.  If we want
to incorporate non-parametric inference to the library, the average of two
numbers is needed a lot.

> (2) What are your (or others) needs for this to be present outside your
> class (or even static)? Are there others who need this method too?

I think only bisection would use it as of now.

> [my thought]: If its strictly just for (d1 + d2) / 2.0, I doubt you
> would want the cost of instantiating an entire Univariate implementation
> behind it. Especially when its called from within an iteration of some
> recursive convergence algorithm. Which brings us to the following.

I envisioned it solely as a simple, one-line, utility method.

> (3) We have a couple cases tangled together here.
> (a) the case of providing static functionality to (non-static)
> implementations of our algorithms.
> (b) the case of providing static utilities to commonly used simple math
> functions (factorial, sign, etc).

(b) is what I see XXXUtils being.

> Simply put, just because we wrote a powerful descriptive stats class,
> doesn't make it the most appropriate solution to put behind a static
> interface for something as simplified as (d1 + d2) / 2.0. Its like
> shooting a rabbit with a cannon, cannons are more expensive, take up
> more space and harder to move around than shotguns.
> I think it would be wise to separate the static methods using above two
> concepts when placing methods/functionality into the static interfaces.
> I think it would also be wise if we had some "protocol" for the election
> of a method into the MathUtils interface. Warranted, this may be a bit
> anal, but wouldn't it be wise to outline the appropriate requirements
> for when an method is added to MathUtils? This way it doesn't turn into
> "thrift store" of methods, some of which shouldn't have been there, some
> which never get used more than once.

Fine by me.  This makes sense to me.

Brent Worden

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

View raw message