commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Weise (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-1375) BOBYQAOptimizer Seems to Sometimes Enter Endless Loop
Date Mon, 13 Jun 2016 02:07:20 GMT

    [ 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)

Mime
View raw message