[analysis]:
Uses Objectified "Functions", or "Functors" these objects resemble the same approach used in the Commons sandbox Functor package.
[stats]: Univariate use what amount to "Data Beans" with get/set style methods, StatUtils provide easy static access focal point. TestStatistic provides Bi/Multivariate Statistical tests as functions. Distributions are a mix of bean and objects math evaluation methods.
[linear]:
Approaches a OOD that provides math function methods like RealMatrix add(RealMatrix m).
[random]: Amounts to a random "value server" or "value iterator" design.
[special]: Static Beta and Gamma distribution utilities.
[util]:
DoubleArray "Wrapper/Collection" tools and ContinuedFraction data structure. MthUtils is another Static method focal point.
How many models do we currently have? Three:
*Functors* Objects that act as Math Functions, taking data as input, providing data output. Example:
public interface UnivariateRealFunction {
public double value(double x) throws MathException; {
*Beans* Objects with getters/setters Example:
public Interface Univariate {
public double getMean();
*Straight Class* Objects with functional methods that evaluate to a result. Example:
public interface RealMatrix {
public RealMatrix add(RealMatrix m) throws IllegalArgumentException;
(2) Considerations
a.) Is consistent library design important? Can all these models interace effectively? Are all these different design models required? Is there a single design model that can span the entire library?
b.) Which design strategy is of more interest to the project? Small compact classes used to complete one specific task, where the programming is primarily OOD in nature? or Feature rich interfaces that encapsulate full ranges of functionality, where programming is primarily "procedural" in nature?
c.) What is the platform of interest for [math]? Server Side or Application.
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).
(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?
(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.
I think the Functors Design Pattern approaches something similar to the Aspect Oriented Design strategy, basically separating the concerns into "Data Collections/Objects" and "Functions/Operations" that can be evaluate/perform processing on those objects.
Either way, I hope some of us will take a quick over the the package and comment according about their opinion. I hope Rodney Waldhoff will feel comfortable about stepping back in and discussing some more about his approach with us.
The site: http://jakarta.apache.org/commons/sandbox/functor/
Specifically of interest are the basic interfaces. http://jakarta.apache.org/commons/sandbox/functor/xref/index.html
-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
