This addition is for consistency with other user-implemented interfaces
as step handlers and event handlers. However, since the equations have
only the state as input and the produce derivatives as output, their
init method also only uses state, as derivatives can be computed only
after equations have been initialized, not before.
This layer implements boilerplate code, mainly step handling and events
handling. It is independent of the type of integrator used. Below this
layer will be the real implementations (Runge-Kutta, embedded
runge-Kutta, Gragg-Bulirsch-Stoer, Adams, ...).
We have merged together what was initially in an integrator interface
and in an AbstractIntegrator class. The separation was only due to
backward compatibility issues which prevented to push some functions up
in the interface. A consequence was that users needed to use the
abstract class in their declaration as soon as they needed the
additional features ... which was most of the cases. We try to fix this
here. When 4.0 will be out, the same merging will be done in the
double[] implementation of ode.
JIRA: MATH-1288
This corresponds to an improved g-stop feature. It basically allow to
manage discrete events that occur during ode integration. when the event
occurs, user can decide to log it and continue, or to change the
dynamics of a problem (for example to handle derivatives
discontinuities) or even to stop the integration before its target date
(for example when the exact final date cannot be known beforehand but is
discovered on the fly). It is the second major feature of our ode
package.
This corresponds to a continuous output feature. It basically allow to
navigate throughout current step instead of having only discrete grid
points. It is a major feature of our ode package.
JIRA: MATH-1288
The base elements are the primary equation that users must implement,
and optional secondary equations to support features like adjoint
parameters or variational equations. Some containers to hold current
state are also introduced to simplify API (these container do not exist
in the double[] version of the API).
JIRA: MATH-1288
As the purpose was only to sort neurons according to an associated
value, using an explicit comparator is simpler. Implementing Comparable
induces also implementing equals and hashcode which are not really
meaningful. They are nevertheless required by our code quality checking
tools.
