commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis Hendriks (JIRA)" <>
Subject [jira] [Updated] (MATH-595) StepNormalizer extension with normalization mode and bounds settings
Date Tue, 21 Jun 2011 06:57:47 GMT


Dennis Hendriks updated MATH-595:

    Attachment: step-normalizer-mode-bounds2.patch

Updated patch.

1. I added the license as requested.

2. "svn diff" produced a patch that could not be applied using the Linux patch command. I
used the Linux diff command instead (for only), and put that part back
into the patch. I can successfully apply it to trunk now.

3. I fixed a few javadoc warnings.

4. I could not figure out how to do checkstyle checking. The "mvn -Prc clean package" does
not seem to do this?

> StepNormalizer extension with normalization mode and bounds settings
> --------------------------------------------------------------------
>                 Key: MATH-595
>                 URL:
>             Project: Commons Math
>          Issue Type: Improvement
>            Reporter: Dennis Hendriks
>              Labels: patch
>             Fix For: 3.0
>         Attachments: step-normalizer-mode-bounds.patch, step-normalizer-mode-bounds2.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
> 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:


View raw message