[
https://issues.apache.org/jira/browse/MATH-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15326747#comment-15326747
]
Thomas Weise commented on MATH-1375:
------------------------------------
I agree, it should be configurable, with a reasonably-large default: One could
run several tests on existing problems (Maybe there already are some unit tests
or something?), check the largest number of iterations ever encountered in the
problematic methods, then multiply with 1000. This would be a good default
maximum loop count. Users would be extremely unlikely to experience any
difference in performance and results. (And even if they would, the changes
should be extremely small. And even if they were not, this would still be
within the contract of the methods, as result quality and discovery of optima
is not guaranteed anywhere.)
Regarding the second option, checking for interruption: I think that one would
be less desirable. So far, two issues have reported/confirmed that bug. Thus,
if one would build a productive system, currently, BOBYQA would not be an
option, as it might hang - and nobody knows why. So the issue should be fixed.
If we would fix it with checking for interruption, this would mean that
whenever we use BOBYQA, we need to start another thread, wait for, say, 10
minutes, and then interrupt. This would be a completely different scenario from
what is done so far and also completely different from how the other algorithms
behave. The required changes in code that uses or would use BOBYQA would be
much more severe than with the maximum loop counter option.
>From this perspective, it would - in my opinion - even be more feasible to
>provide a "maximum runtime" in ms and have methods check
>System.currentTimeMillis() from time to time. Such an option may actually even
>be better than having a maximum iteration limit, as it currently exists.
>Reason: Most algorithms support an iteration limit, but the runtime per
>iteration may differ extremely from algorithm to algorithm. The users
>currently cannot really know how much runtime an algorithm will take if they
>say "at most 1000 iterations", for instance. However, I think what most users
>actually want is to limit the runtime - so why not do it in a natural way, by
>letting them specify a time limit in ms? Hm ... that would actually be a
>feature request...
> BOBYQAOptimizer Seems to Sometimes Enter Endless Loop
> -----------------------------------------------------
>
> Key: MATH-1375
> URL: https://issues.apache.org/jira/browse/MATH-1375
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: Java 8 JDK, OpenJDK, Ubuntu
> Reporter: Thomas Weise
> Priority: Minor
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> I am using BOBYQAOptimizer to solve some numerical problems related to
> nonlinear function fitting. BOBYQAOptimizer is provided with close-to-optimal
> solutions which it is supposed to refine. In some cases, BOBYQAOptimizer
> seems to enter an endless loop, or at least an extremely long loop. The
> problem is almost impossible to reproduce as it occurs maybe once every 1000
> runs.
> From what I can see with the debugger, the source of the problem is probably
> method trsbox which is called by bobyqb. In trsbox, some values of a vector
> (sorry, forgot which one) grow extremely large (>=1e250). Either way, I
> noticed that both mentioned methods feature a for(;; ) loop.
> Now that algorithm looks quite mathematical to me and seemingly has been
> translated from FORTRAN or something. I think fixing and finding mathematical
> issues might be complicated (see also the caveats reported in the release
> notes) and overall, the algorithm is working.
> How about you also count the iterations of the for(;; ) loops in bobyqb and
> trsbox and throw an exception if they exceed some limit? In the easiest case,
> instead of for(;; ) you can do something like
> {code}
> for(int maxRemainingSteps=100; (--maxRemainingSteps)>=0;) {
> ...
> }
> throw new MaxCountExceededException(100);
> // or TooManyEvaluationsException(100);
> // or MathIllegalStateException(LocalizedFormats.SIMPLE_MESSAGE, "Huh?");
> {code}
> Since the original for loops are always left via "return", that would already
> do the trick. Or you could use an Incrementor object for this purpose. Either
> way, I think with the very simple fix above, you would prevent endless loops,
> add only a tiny bit of very easy-to-understand code, and would not break the
> algorithm contract, since such exceptions could be thrown sometimes even
> without the fix.
> In summary: BOBYQAOptimizer needs some work. Fixing the issue I observed
> properly (i.e., by fixing the special cases causing it) is probably very
> complex and is probably not feasible. Preventing it, however, seems to be
> rather easy, as I have shown above.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
