StepNormalizer extension with normalization mode and bounds settings
--------------------------------------------------------------------
Key: MATH-595
URL: https://issues.apache.org/jira/browse/MATH-595
Project: Commons Math
Issue Type: Improvement
Reporter: Dennis Hendriks
Fix For: 3.0
Attachments: step-normalizer-mode-bounds.patch
While I was the StepNormalizer to get output at fixed interval points instead
of the points determined by the ODE integrator, I noticed the following:
1. It returns the first point (t0), and integer multiples of the step size add
to it (t0+h, t0+2h, ...). Let's call these the 'normalized points'. I wanted it
to return values at multiples of the step size, regardless of the start vaule.
This would be a different semantics of 'normalized points'.
2. It returns the first point (t0), and the last point only if it is a
'normalized point'. I wanted it to never return the first point, and always
return the last point, regardless of the 'normalized points'. If one used a
StepHandler directly, and not a StepNormalizer, the first point would not be
given to the handler, and the last point would. Thus, there is a difference in
first/last point handling for 'normal' StepHandlers and StepNormalizer with
FixedStepHandler.
Therefore I generalized the StepNormalizer:
1. It now has two modes (StepNormalizerMode enumeration). The first is
INCREMENT, which has the old semantics for 'normalized points'. The second is
MULTIPLES, which has the newly proposed semantics.
2. It is now possible to specify whether the first and last points should be
given to the underlying fixed step size step handler (StepNormalizerBounds
enumeration).
The changes should be transparent to already existing code, as I used the old
semantics for existing constructors. The only change is in the calculation that
determines whether the next 'normalized point' is in the current step interval.
For forward integration, the end point was considered to be in the interval,
while for backward integration the end point was considered NOT to be in the
interval. I changed this so that the end point is in the interval regardless of
the direction. This is the only non-backward compatible change. I personally
consider the old behavior to be wrong... This change is also required for the
correct functioning of the new bounds settings.
I also added a whole bunch of unit tests to test all different combinations of
normalization modes, bounds settings (first/last inclusion), integration
direction, and whether the 'normalized points' coincide/overlap the first/last
points. This results in 2*4*2*2=32 unit tests.
I believe that the generalizations that I introduced make the StepNormalizer
more powerful, and make it useful in more scenarios.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
