Thu 16 Feb 2012 06:09:13 PM UTC, comment #4:
Just because Matlab does something, doesn't mean it is wrong. In this case, I don't see why we should avoid compatibility and keep Inf separate.
NaN and Inf are both saturating values in Octave which means any further mathematical operations involving them always return the same value.
Inf - 1e6 == Inf
Nan + 2 == NaN
They represent dead-ends which the optimization algorithm may be unable to get out of.
Imagine that an optimization routine uses a first derivative to guess at the next value of the objective function.
Phi(n+1) = Phi(n) + d/dx (Phi).
As soon as Phi(n) hits Inf this sort of algorithm is locked.
This may not be a particular issue for fminunc but the FunValCheck option is supported across all the optimization routines and should have the same behavior across all of them as well. Thus, if even one of the optimization routines does something similar to what I have described then Inf needs to be checked for.
Including Inf in the tests shouldn't be a problem for the actual algorithm in fminunc. You assert that fminunc might detect the change from objective_value1 to Inf as a positive increase and therefore reverse the search direction. If you are dealing with continuous functions, however, fminunc will have had ample warning that the objective function was increasing before hitting the value Inf. It would have reversed the search course very early on, and if it didn't and actually reached Inf, then something is wrong with the search and FunValCheck should terminate the procedure.
If you are dealing with a crazy function with point discontinuities then I'm afraid there is always going to be trouble and you might need to restrict minimization to the continuous regions and do local minima searches in those regions.
As for testing, I want to be thorough and show not only that the feature works as expected, but also that it doesn't break anything else. We know that it was a typo, but as a tester I need to treat the code as a black box. The %!error statement shows that FunValCheck correctly detects a complex value. The %!assert shows that there are no side effects in FunValCheck which would stop an ordinary function from working.
|