It ought to be said that nan and inf etc have very clearly defined bit
patterns in memory that are defined by an ieee754 cf
http://steve.hollasch.net/cgindex/coding/ieeefloat.html and
http://www.psc.edu/general/software/packages/ieee/ieee.html. Thus its a
question of python/compilers not putting nan in the right place and not
using comaprisons etc properly when nans are are present. It should
always be possible to detect if a nan is present by the bit pattern in
memory (and this is the way fpconst.py does it). It is of course
possible to test if nans are supported correctly on a paricular
architecture and compiler by comparisons etc and if not warnings etc
could be raised or alternative code executed)
another thing to say is that though fpconst.py is gpl incompatible due
to some arcana about /patent termination cases
(http://en.wikipedia.org/wiki/Apache_License)/ in the apache license,
due to they way it works should be relativley easy to cook up our own
version which would bullet proof and low maintenance in the same way as
fpconst.py is... and also quite legal
Could the fpconst.py file be legally included in a relax distribution?
I can't reach it's homepage so I can't read the licence. Do you
think it is cross platform or is it dependent upon the underlying C
libraries? Importantly does the value of NaN actually need to be
caught? Prevention could be used to eliminate most NaNs and the cure
could be to have iteration limits.
The limit on the iterations for the backtracking line search will
probably not be too much of an issue. The bigger issue is that the
convergence test:
fk_new - fk <= f_tol,
when fk_new and fk are both chi-squared values of NaN, never evaluates
true. Then the number of iterations of the optimisation algorithm
will hence be the most expensive factor rather than the backtracking
subalgorithm.
Edward
Re: [bug #6503] Uncaught nan in xh_vect