commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [math] proposed ordering for task list, scope of initial release
Date Tue, 10 Jun 2003 19:23:42 GMT
Al Chou wrote:
> --- Phil Steitz <> wrote:
>>Brent Worden wrote:
>>>>-----Original Message-----
>>>>From: Phil Steitz []
>>>>Sent: Friday, June 06, 2003 12:21 PM
>>>>Subject: [math] proposed ordering for task list, scope of initial
> [deletia]
>>>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).
I actually was thinking the other way around.  If you feel strongly 
about keeping these things in stat, we can create StatUtils.  The point 
is to encapsulate these basic functions so that a) users can get them 
immediately without thinking about our stat abstractions and b) we can 
get the storage-based computations of the basic quantities in one place. 
  When the UnivariateImpl window is finite, it should use the same 
computations that AbstractStoreUnivariate does -- this is why we need to 

>>>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 
> I read that to mean the accuracy requested (aka allowable error) of a given
> algorithm invocation.

But why would we ever want to define that as a constant?

>>>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
>>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.

I do not see the need for an abstract hierarchy of math exceptions at 
this time.  Of course, I could be convinced of this is someone explains 
why we can't just use or subclass things in java + lang.
> Al
> =====
> 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:

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

View raw message