commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <j3322...@yahoo.de>
Subject Re: [math][functor] More Design Concerns
Date Fri, 27 Jun 2003 20:00:08 GMT
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 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message