commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Al Chou <>
Subject Re: [math] proposed ordering for task list, scope of initial release
Date Tue, 10 Jun 2003 19:14:03 GMT
--- Phil Steitz <> wrote:
> Brent Worden wrote:
> >>-----Original Message-----
> >>From: Phil Steitz []
> >>Sent: Friday, June 06, 2003 12:21 PM
> >>To:
> >>Subject: [math] proposed ordering for task list, scope of initial
> >>release
> > Things that might be added:
> > Average of two numbers comes up a lot.
> Yes. Some (of us) might not like the organization of this; but I have a 
> couple of times posted the suggestion that we add several
> double[]->double functions to MathUtils representing the core 
> computations for univariate -- mean, min, max, variance, sum, sumsq. 
> This would be convenient for users and us as well.  I guess I would not 
> be averse to moving these to stat.StatUtils, maybe just adding ave(x,y) 
> to MathUtils.
> Given the post that I just saw regarding financial computations, I 
> suggest that we let MathUtils grow a bit (including the double[]->double 
> functions and then think about breaking it apart prior to release.  As 
> long as we stick to simple static methods, that will not be hard to do.

Would it be considered poor form to provide these methods in MathUtils but have
them delegate to the stat subtree of the class hierarchy.  That way all the
actual code would be in one place, but we wouldn't force users to know that
they're doing a statistical calculation when they just want average(x, y).

> > Some other constants besides E and PI: golden ratio, euler, sqrt(PI), etc.
> > I've used a default error constant several places.
>    It would be nice to come
> > up with a central location for such values.
> I get the first 3, but what exactly do you mean by the default error 
> constant?

I read that to mean the accuracy requested (aka allowable error) of a given
algorithm invocation.

> > In addition to the above, has any thought gone into a set of application
> > exceptions that will be thrown.  Are we going to rely on Java core
> > exceptions or are we going to create some application specific exceptions?
> > As I recall J uses a MathException in the solver routines and I added a
> > ConvergenceException.  Should we expand that list or fold it into one
> > generic application exception or do away with application exceptions all
> > together?
> My philosophy on this is that whatever exceptions we define should be 
> "close" to the components that throw them -- e.g. ConvergenceException. 
>   I do not like the idea of a generic "MathException."  As much as 
> possible, I think that we should rely on the built-ins (including the 
> extensions recently added to lang). Regarding ConvergenceException, I am 
> on the fence for inclusion in the initial release, though I see 
> something like this as eventually inevitable.  Correct me if I am wrong, 
> but the only place that this is used now is in the dist package and we 
> could either just throw a RuntimeException directly there or return NaN. 
>   I do see the semantic value of ConvergenceException, however.  I guess 
> I would vote for keeping it.

I agree that we should have exceptions be as specific as possible. 
MathException could be an abstract parent for all of the commons-math exception
classes, maybe.


Albert Davidson Chou

    Get answers to Mac questions at .

Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).

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

View raw message