Mark R. Diggory wrote:
> 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 followup 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
(commonsrecursiveexception? :),
 conditionally compile something, probably making a JDK 1.4 compiled
commonsmath.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 LUdata 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, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
