commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <>
Subject Re: [math][functor] More Design Concerns
Date Thu, 26 Jun 2003 02:17:26 GMT
> > c.) What is the platform of interest for [math]? Server Side or 
> > Application.

Remember that Jakarta's mission is create *server-side* libraries:

That doesn't mean that a library couldn't be used in client-side apps but
it does mean that your primary focus should be on server-side concerns. 
Commons Validator is a good example of a library that can be used client
side but was developed primarily for validating html forms in server apps.


> We should certainly not have to choose here -- nor should our users. 
> Nothing in the current implementation would create problems in 
> server-side applications -- at least nothing that I can see. If others 
> can see problems, we need to identify and address these specifically. 
> The most important thing to do here is to clearly document interfaces so
> that users know what is stateful, what is not, what is thread-safe, what
> is not, what creates singletons, pools or external storage (nothing so 
> far), etc.
> > 
> > d.) Should static method utilities be avoided at all costs in both 
> > cases? OR are there specific situations were static functions do not 
> > create garbage collection considerations and issues (like, when only 
> > returning primitives).
> I am starting to think that we should avoid static methods, and in fact 
> change StatUtils to require instantiation, but this has nothing to do 
> with garbage collection, since with a stateless collection of static 
> methods, there is no "garbage" to collect -- just a class loaded once 
> per JVM.  As long as there is no state associated with the class, I 
> don't see how classloader problems could really come into play (unless 
> users were relying on classloader priority to load different versions, 
> which is IMHO a bad idea and could apply to any of our classes).  The 
> real issue here is extensibility.  As I think more about the use cases 
> for StatUtils, I am less convinced than I was before that the 
> "convenience" and "efficiency" of not having to create an instance is 
> worth the anxiety about support for extensibility.  Therefore, I would 
> support changing the methods in StatUtils to be non-static.
> > 
> > 
> > (3.) A couple proposals:
> > 
> > (i.) Brent and Pietschmann can you make suggestions/recommendations as
> > to how your "function object" model could be applied to StaticUtil 
> > situations? Are you familiar with the Functors project and is there a 
> > possibility that they should be considered as the basic design
> strategy 
> > or base of implementation for your "Function Object" design? if they
> are 
> > a Commons project as well is there a possible dependency here we could
> > take advantage of?
> My opinion here is that a univariate real function is an object in its 
> own right. I suppose that it could extend Functor, but I do not see the 
> point in this and I would personally not like having to lose the typing 
> and force use and casting to Double to implement
> Object evaluate(Object obj);
> It should also be noted that this is a relatively trivial part of what 
> is really going on in the analysis package (i.e. rootfinding and spline 
> fitting).
> > 
> > (ii.) Robert, can you provide any information that relates to (d.) 
> > above? And if there are such cases where static utils are ok in a
> server 
> > env when there are significant garbage collection concerns?
> > 
> > (iii.) All, can we consider that there is consistent approach to
> dealing 
> > with Equation like math evaluations, whether matrix, statistical or 
> > numeric. Finding and defining such a consistency will enhance the 
> > "plug-n-play" capabilities of the library. Providing both a means to 
> > easily learn, use and combine functionalities across various parts of 
> > the library.
> > 
> > 
> Repeat comments above.  I do not believe that there is a "one size fits 
> all" nor that trying to force everything into a single pattern (which I 
> find hard to imagine) will make things easier.  Remember that many 
> (most?) users will come to commons-math with a specific problem in mind 
> and they will not likely want to invest large amounts of time in 
> learning the "commons-math design philosophy".  If we want to meet the 
> goals in the proposal, we will want to make things as simple and 
> "natural" to users as possible.  Obviously, the 10000 <favorite 
> currency> question is what is most "natural" for each functional area in
> commons-math.
> Another point that we need to keep in mind is that we have a naturally 
> layered structure, which will become even more so over time.  We should 
> be liberal in exposing technical functionality that "most users" will 
> not use and the mathematical orientation of the interfaces will 
> naturally increase as you go deeper into the infrastructure.  For 
> example, Brent did the hard work to derive and implement some special 
> functions that reside in the special package. These were the key to 
> providing the statistical testing/confidence intervals that "more users"
> may use.  "Most users" will not use the special functions directly -- 
> but it is very nice to have them exposed for the mathematical 
> programmers who want to exploit their many uses beyond what we have used
> them internally for. Moving up the layers, "most users" will not use the
> Chi-Square distribution directly (which builds on special); but that is 
> also very nice to have. Continuing up the call stack leading to the 
> stats tests, we come to rootfinding, which more users will use directly 
> and finally to the statistical tests and confidence intervals, which 
> will likely be used directly quite a bit by people with no understanding
> or interest in either rootfinding or special functions.  At each of the 
> layers, a different level of mathematical sophistication is expected and
> different kinds of interfaces are "natural".
> Finally, I think that it is appropriate to in some cases expose what 
> amounts the the "same functionality" via multiple different kinds of 
> interfaces.  For example, to get the mean of a collection of doubles, 
> you can now a) use StatUtils if what you have is an array of doubles and
> all you want is the mean b) instantiate a storage-less Univariate and 
> feed the values in (good for long lists of values that you don't want to
> store in memory) or c) if the numbers whose mean you want happen to be 
> exposed as properties of a collection of beans, instantiate a 
> BeanListUnivariate and use it to get the mean.  I see absolutely nothing
> wrong with this and in fact a lot that is "right" with this -- practical
> use cases drive design and the result is flexibility, convenience and 
> ease of use.
> Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

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

View raw message