[ 
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

Reply via email to