_ _An Issue I was forgetting about is wheter or not , Abstract factory
calculate method should be override to provide support for Complex
types.
On jueves, 16 de febrero de 2012 at 5:27 PM, leandro pezzente
wrote:Now that Commons Math 3.0 is almost released I guess I can start
a
thread regarding this proposal , I think its a really cool feature and
that It can improve Math Commons flexibility in a huge grade.
This is my Basic Proposal : To Implement an Abstract Factory Pattern (
that is , an abstract class that relies in implementing a set of
methods , but whose internal logic works on those abstract methods )
that implements UnivariateFunction , wich creates an univariate
function as an aproximation ( that is a finite number of terms ) to a
funcional series. Basically , you extend the abstract class , you
implement :
double function( int n , double x )
wich is an abstract method that comprises the functional term of the
series aproximation and
double constants (int n )
wich is an abstract method that comprises how the nth constanst the
form of the constants.
i.e. , for an Expotential function this functions would be implemented
as :
protected double function ( int n , double x)
{
return ( FastMath.pow( x , (double ) n ) );
}
protected double constants( int n)
{
return ( 1 / factorial ( n ) )
}
private double factorial( int n )
{
if ( index == 0)
{
return 1.0;
}
else
{
return ( (double) (index) * factorial( index - 1) );
}
}
Abstract Factory Class has a single constructor , wich takes the
number of terms that will be calculated , that is what should be the
maximun nth index at wich the infinite series will be cut. Thats
because , in some implementations you can rely on having a less
precise result in favor of faster calculations. There is a private
MAX_ITERATIONS int variable that would regulate what number of
iterations should not be exceed , by default I setted to 98 , since
the most commons series constants involved a factorial function , wich
return Double.NaN for indexes beyond 98 ( that is a double greater
than 1E+153 ) , but It sgould be discussed if a final implementation
should be dropped in favor of flexibility , since implementations that
not requiere a factorial function then could override this variable (
for example an aproximation to a Fourier series ).
The internal calculation performed by the private calculate method( )
uses an recursive iterative summation approach , i think its fairly
safer since the number of iterations should be fairly low , given the
1E-16 double precission limit , that is , I dont think most
implementers would build an aproximation of 1,000,000 or so terms ,
which could produce a heap overflow with default JVM params , but then
again , partly of the idea of addressing a maximun iteration number is
to address those cases.
The proposal is made so MAth commons users can implement their own
univariate functions in case the API can not provided a successfull or
a required one. Since only two methods ( and possibly a constant )
would be implemented , i think its a fairly Easy to Use template.
Now , there are a fair ammount of issues that should be discussed
still , I would address the ones I have already thougth of ( and the
ones Gilles already mentioned ) , but you are all welcome to
contribute :
+ The Javadoc should be clearer about how methods are implemented and
how abstract methods should be implemented. Thats is , Javadoc
comments need a big clean up. As Gilles addressed , Documentation is
Incomplete and contains a lot of typos .
+ A way of enforcing implementer a subclass arguments limit both for
precission and convergence should be propossed. I.E. in my
Hypergeometric example , I havent detailed witch limits Alpha , Beta
and Gamma values limits for optimal convergence ( that is Math.abs(
Gamma - ( Alpha + Beta ))) > 0.0 for Absolute converergence ). Now I
do think , convergence should be enforced in some way in the abstract
template so and IllegalArgumentExceotion would be throw if adequate
implemetation params are not achieved , since , as Gilles addressed ,
this coding Style is best avoided ( I already get rid of setResult in
my own Eclipse project ).
+ There is an Issue regarding Superclass constructor , the big problem
is , If a subclass depends of implementation params , this should be
instantiated BEFORE a superclass constructor should be called ( or
both constants() and function methods would be called with
uninstianted arguments ). But this could provide being confussing for
a function implementer. ATM , I have no idea how this could be solved.
+ Abstract Class should be renamed in a propper way more suitable with
Math Commons Coding Conventions and Style. AS Gilles Addresed ,
formatting is not compliant and UnivariateFunctionFactory does not
refelct the concept at hand.
I hope I have made the concept as clearer as i could , i think , this
could be a really nice feature in future Math commons Releases.
Comments and Feedback are welcome and encouraged ,
Leandro A. Pezzente.
