[
https://issues.apache.org/jira/browse/MATH-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464765#comment-13464765
]
Luc Maisonobe commented on MATH-811:
------------------------------------
This is exactly the point.
The code snippet you show solves a difficult bug that did occur before we
introduced g0Positive.
The problem is that you cannot trust the sign of a value which was explicitely
been found as being a zero. First, we cannot yet force users to use a
bracketing solver. So users may experience convergence on the "wrong side" of a
zero, i.e. when they have a decreasing function, they may converge before the
zero and have g(ta) still positive (very small but positive). Then if g(tb) is
negative because it is slightly after the zero, the algorithm will detect a
sign change, trigger the solver, and finally converge again to the one that has
already been handled earlier! And of course, the second convergence will not
always be on the same point as the first one, only close enough to let you
wonder if it is really a new event or not.
In fact, even if we were able to force users to use bracketing solvers, this
would not be safe enough, and we would still need the g0Positive field. There
is still the rare case when the solver finds exactly a root. What sign should
be used if g(ta) = 0?
Once initialized at integration start (or when we know we are away from roots,
just like in the "else" part above), the g0Positive is really a stable
flip-flop.
bq. -> the value "increasing" relates to g function, and not to g0 value.
Yes, of course! A function becomes positive after its root when it is
increasing around this root.
bq. If removing g0positive field is a problem, we could put it again, but I
don't understand the reasons yet.
Yes, it is an important problem. It would reactivate a very nasty bug that took
a long time to analyze, understand and fix. Please put this field back.
> Improve event detection by selecting g function slope
> -----------------------------------------------------
>
> Key: MATH-811
> URL: https://issues.apache.org/jira/browse/MATH-811
> Project: Commons Math
> Issue Type: Improvement
> Affects Versions: 3.1
> Reporter: Yannick TANGUY
> Attachments: JIRA-811_slope_selection.patch,
> JIRA-811_slope_selection_V2.patch, JIRA-811_slope_selection_with_spaces.patch
>
>
> We would like to select g function slope in CommonsMath event detection
> feature.
> This would improve event detection for the final user (the possibility to
> ignore some events, and less computation time) and also correct a bug found
> while using OREKIT (see https://www.orekit.org/forge/issues/104) in our
> applications.
> The modification consists in adding a method (getSlopeSelection() : int) in
> EventHandler, and modifying one conditionnal in the method evaluateStep
> (class EventState).
> We can provide modified code and unitary tests for this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira