[
https://issues.apache.org/jira/browse/MATH-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe updated MATH-716:
-------------------------------
Assignee: Luc Maisonobe
The problem Pascal (who works with me) describes has already been encountered
during the development of the algorithm. The solution found at that time seems
to be insufficient. What happens is that in order to still gain a few digits
while rebalancing the bracketing interval, we base our retargeting on the
currently best solution. In this case, we set targetY = -yA/16 and fail to
rebalance. Using the other bracket would improve rebalancing but waste
evaluations as was observed during development. So its not a perfect solution
either.
I think a compromise would be to attempt rebalancing with a progressively more
aggressive target. We could start from the current setting (i.e -1/16 of the
best bracket), and if we still update the same side, move towards larger
targets.
> BracketingNthOrderBrentSolver exceeds maxIterationCount while updating always
> the same boundary
> -----------------------------------------------------------------------------------------------
>
> Key: MATH-716
> URL: https://issues.apache.org/jira/browse/MATH-716
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 3.0
> Reporter: Pascal Parraud
> Assignee: Luc Maisonobe
> Priority: Minor
>
> In some cases, the aging feature in BracketingNthOrderBrentSolver fails.
> It attempts to balance the bracketing points by targeting a non-zero value
> instead of the real root. However, the chosen target is too close too zero,
> and the inverse polynomial approximation is always on the same side, thus
> always updates the same bracket.
> In the real used case for a large program, I had a bracket point xA =
> 12500.0, yA = 3.7e-16, agingA = 0, which is the (really good) estimate of the
> zero on one side of the root and xB = 12500.03, yB = -7.0e-5, agingB = 97.
> This shows that the bracketing interval is completely unbalanced, and we
> never succeed to rebalance it as we always updates (xA, yA) and never updates
> (xB, yB).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
