If the user asks for a derivation order that is too large for the number
of points in the finite differences algorithm, we now detect it before
the first call to the underlying function.
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1387064 13f79535-47bb-0310-9956-ffa450edef68
This class implements both UnivariateFunctionDifferentiator,
UnivariateVectorFunctionDifferentiator and
UnivariateMatrixFunctionDifferentiator. It is not limited in the
derivation order, but checks the order is consistent with the number of
points. Typically, attempting to extract 5th derivative from a 3 points
scheme will not work (a NumberIsTooLargeException will be thrown,
referencing the derivation order).
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1386745 13f79535-47bb-0310-9956-ffa450edef68
In some cases, users may already have all the derivatives available at
once. It was impossible to use this knowledge and create the object, so
users had to user dirty tricks like adding together variables holding
value and zero derivative with variables holding derivatives and zero
value.
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1386743 13f79535-47bb-0310-9956-ffa450edef68
One very important case corresponds to an unsupported derivation order.
The order is not enforced in the API, but is specified as the properties
of the DerivativeStructure argument, as well as the number of free
parameters. Some functions have no limitation on this order (typically
functions implemented using only the DerivativeStructure API), but some
functions may limit the derivation order to 1 or 2 as they implement the
differentiation themselves or through finite differences.
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1386741 13f79535-47bb-0310-9956-ffa450edef68
As a temporary hack for backward compatibility, some optimizers do
provide "optimize" methods which accept the new functions signatures
(i.e. MultivariateDifferentiableXxxFunction), but they do *not*
advertise it in their "implements" clause. The reason for that is that
Java forbid implementing a parameterized interface with two different
parameters. These optimizers already implement the interface with the
older functions signatures, and this cannot be removed as of 3.1.
When 4.0 will be started, the old signatures will be removed, and the
"implements" declarations will be updated.
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1384907 13f79535-47bb-0310-9956-ffa450edef68
Prior to this correction, when at one point in a program a user needed a
derivative with 1 parameter and order 5, and at another point needed a
derivative with 30 parameters and order 1, all DSCompilers from 1x1 to
30x5 were created. As the compilation rules for 30 parameters and 5
order are huge, this failed with memory heap errors after several
gigabytes were consumed.
The fix is to simply build the necessary compilers, and let the array
contain null references for the compilers never used (these null
references will be populated later if the user ask for some intermediate
value that need them, of course).
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1384905 13f79535-47bb-0310-9956-ffa450edef68
The interface and its implementations should be removed for 4.0. The
remaining uses in the library are only there for compatibility.
Everything else now use the new UnivariateDifferentiableFunction
interface and DerivativeStructure, which allow both arbitrary
differentiation order and arbitrary number of free parameters.
The next step for 3.1 is to replace the multidimensional functions (i.e.
multivariate functions, vector valued functions and matrix valued
functions).
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1383845 13f79535-47bb-0310-9956-ffa450edef68
The "Function" part of the name was forgotten when this new interface
was created a few weeks ago, for replacing the older
DifferentiableUnivariateFunction.
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1383441 13f79535-47bb-0310-9956-ffa450edef68
Thomas Neidhart
Luc Maisonobe
Sebastien Brisard
Phil Steitz