octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #35534] fminunc: FunValCheck buggy


From: Rik
Subject: [Octave-bug-tracker] [bug #35534] fminunc: FunValCheck buggy
Date: Thu, 16 Feb 2012 18:09:13 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0

Follow-up Comment #4, bug #35534 (project octave):

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.



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?35534>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]