> I have a feeling that the problem may be in the line search as all the
> other algorithms - Augmented Lagrangian constraint algorithm (also
> known as the Method of Multipliers) and Newton line search - have
> iteration limits. The sub loop of the Method of Multipliers is
> limited to 500. The upper limit in total is 1e7 although the
> constraint algorithm causes this to terminate a little early. A
> number of easy tests may pin-point the issue - turning constraints off
> "constraints=0", changing the line search algorithm ("More-Thuente" is
> a good one), changing the Hessian modification ("Chol" the cholesky
> modification may work), or changing to a non line search algorithm
> ("fr" Fletcher-Reeves conjugate gradient or "dogleg" trust-region
> algorithms for example). Another option is to increase the printed
> output by increasing the "print_flag" flag value to 2, 3, etc. These
> simple tests should hopefully pin-point the exact cause of the
> minimisation issue.
I'll look into it, but perhaps its sufficient to catch NaNs before they
cause the problen in the first place (though this might be harder than
it seems, see below...). Certainly it seems to me that the Grid Search
should report failure if it cant find a function value less than 1e300.
This should ensure the starting point of the minimisation always
evaluates to a finite floating-point value, as long the user always does
a grid search first.
Catching the NaN and maybe raising a 'RelaxError' might be best. I
think 1e300 is the value I use as the initial value - it's used to
test the function tolerance. NaN maybe a better starting value
though. Then if NaN is returned an error can be thrown within the
code not in 'minimise/'. Otherwise the point at which the NaN is
generated could be tracked down so the code causes the NaN can be
destroyed.
> Also, which version of Python are you using? It could be an issue
> with how Python handles the value of NaN. The first catch should be
> easy although by definition NaN != NaN. I don't know if Python does
> this properly so it might be worth avoiding the NaN value to start
> with.
I'm using Python 2.4.1 and Numeric 24.0, but I don't think that matters.
>From what I can gather Python inherits its fp behaviour almost entirely
from the underlying hardware/libc combination. This means NaN behaviour
is platform dependent, and all the obvious ways of catching NaNs (and
INFs and other special floats) tend to be non-portable (including NaN !=
NaN). I'll look into other options.
Maybe the built in Python function 'cmp' could be used to catch the
NaN. If two NaN values are supplied then the function should return
'0'. If NaN is compared to Inf then the value should be 1. Any other
number should return -1. This is how Python 2.4 sees the world!
Unfortunately I also tried the 'cmp' function under Python 2.1 and all
comparisons returned zero. According to the informative link
http://www.cs.ucla.edu/classes/winter04/cs131/hw/hw4.html version
2.3.3 and lower are likely to be affected. If the NaN is to be caught
using 'cmp' it will most likely cause issues if older versions of
Python are used. The relax manual says to use version 2.4 or higher
so it shouldn't be too important. In addition if someone uses an old
Python version the likelihood of them encountering the issue is low.
Avoiding the NaN in the first place may be a better solution though.
Edward
Re: [bug #6503] Uncaught nan in xh_vect