Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <20030610200518.72849.qmail@web41309.mail.yahoo.com>
Date: Tue, 10 Jun 2003 13:05:18 -0700 (PDT)
From: Al Chou <hotfusionman@yahoo.com>
Subject: Re: [math] proposed ordering for task list, scope of initial release
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <3EE6303E.6080700@steitz.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

--- Phil Steitz <phil@steitz.com> wrote:
> Al Chou wrote:
> > --- Phil Steitz <phil@steitz.com> wrote:
> > 
> >>Brent Worden wrote:
> >>
> >>>>-----Original Message-----
> >>>>From: Phil Steitz [mailto:steitzp@yahoo.com]
> >>>>Sent: Friday, June 06, 2003 12:21 PM
> >>>>To: commons-dev@jakarta.apache.org
> >>>>Subject: [math] proposed ordering for task list, scope of initial
> >>>>release
> >>>
> > [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 
> encapsulate.

My organizational instincts say to put the implementation in stat and delegate
to it from MathUtils.  Probably 99% of actual use will consist of code calling
MathUtils (because no one will bother to learn that the implementation is
really in stat), but until we see a performance problem I'm strongly for
categorizing things as what they are (what they are in my mind, of course <g>).
 Avoiding premature optimization and YAGNI, and so on....


> >>>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.
> > 
> 
> But why would we ever want to define that as a constant?

I wouldn't, at least not as a global constant.  That's why I suggested we
define an interface that can be implemented by the classes that need this
functionality.  That way we'll have a consistent way to set the value for each
class that needs it.  Currently, Brent's bisection method hardcodes it, whereas
Herr Pietschmann's framework provides a getter/setter pair in an interface.  I
wonder if it's even possible to abstract further and pull the accuracy aspect
into a separate interface.  Accuracy/error _seems_ like a general concept, but
it could be too fuzzy a concept to yield a concrete interface specification.


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

I agree; I'm certainly willing to defer decisions about this area for now.


Al

=====
Albert Davidson Chou

    Get answers to Mac questions at http://www.Mac-Mgrs.org/ .

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org