a.) Is consistent library design important?
What's consistency? Mathematical functions, one of the most fundamental stuff in mathematics, are at least in syntax incompatible with Java OOP. Offering a syntax which is close to a model already used for several hundred years should be a consideration. Of course, Java source can't offer overloaded operators and so on, so there are limits.
d.) Should static method utilities be avoided at all costs in both cases?
No. There are legitimate use cases: 1. Factory methods. No argument. 2. If the functionality does not need data persisting the function call, there is clearly a "best" implementation (no need to override), no configuration data (as opposed to the obvious parameters), and no clear "object" (or rather, a class) to attach the the functionality, a static method can be the most intuitive design. The Java library has examples, like j.u.Arrays.* and of course Math.*. Candidates not in the Java library: max(x,y), max(array) Grey zone: calculate gamma(x) (consider accuracy settings configurable) Out: matrix inversion (no single "best" algorithm)
(i.) 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?
No. But I consider the UnivariateRealFunction as an avoidable artefact if Java only had function pointers. However, in this special case saving data while computing the function value in order to be used in a follow-up computation of the derivative at the same argument would be enough of a reason to introduce the concept anyway. FORTRAN programs use global data for this purpose, but then FORTRAN doesn't have threads and more possibilities for the compiler to watch which part of the code overwrites which data.
And if there are such cases where static utils are ok in a server env when there are significant garbage collection concerns?
I don't think static functions can cause any memory or GC related problem. If static functions pose a problem, then its typically an MT related problem, either unsync'd methods (duh!) or blocked threads. If they don't use any static data, such problems shouldn't occur.
Further comments: 1 Now there are two root finding frameworks in place. I think this should be unified. 2 Either derive ConvergenceException from MathException and use it in BrentSolver and SecantSolver too for indicating convergence problems, or replace it in or somewhere near Gamma.java with a MathException. 3 Both MathException and ConvergenceException don't compile on Java 1.3 and nobody noticed. This is ugly: we could - implement the recursive exception mechanisms in MathException, as everybody else does, or - get such an implementation from elsewhere (commons-recursive-exception? :-), - conditionally compile something, probably making a JDK 1.4 compiled commons-math.jar incompatible with JRE 1.3 - remove the constructors with recursive throwables, as they aren't yet used anyway. 4 LU composition and equation system solvers should be put in a separate class, similar to root finders. RealMatrix should only hold data and provide arithmetic. It may be necessary to have an additional object for holding the LU-data as a result of the decomposition algorithm. a static function can provide a simple interface to solving equation systems using default algorithms, the same way it is done in the root solving framework. 5 Static functions for calculating higher moments for arrays are unwise, because the array is repeatedly scanned if several moments are to be computed. This should be encapsulated in an object which can hold already computed results across invocations of different calculating routines. 6 Factorials and binominal coefficients are classical classroom examples, but I never saw them in any real world implementation of a numerical algorithm. Well, with the possible exception of number theory related stuff. In fact, encountering these is usually an indication that the algorithm could be sped up by at least an order of magnitude.
J.Pietschmann
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
