Edward d'Auvergne wrote:
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 am not a lawyer and the waters eem to be muddy...
Is the Apache license compatible with the GPL (GNU Public License)?
It is the unofficial position of The Apache Software Foundation that the
Apache license *is* compatible with the GPL. However, the Free Software
Foundation holds a different position, although we have not been able to
get them to give us categorical answers to our queries asking for
details on just what aspects they consider incompatible.
Whether to mix software covered under these two different licenses
*must* be a determination made by those attempting such a synthesis.
however I don''t see that ther is a problem if the file is in a separate
module... plenty of people install apache based software and gpl
software in their python machines. At worst all that would happen is
someone would complain and we would have to write out own...
( I reckon I could do the whole thing in a few hours at most including
some unit tests)
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?
It is completley cross platform as far as I can see. If you ran it on a
non ieee platform you might get some weird edge cases but this would be
for somewhat bizarra architectures these days (do you want to run it on
a gray or a vax?)
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.
If this will get rid of it, then thats great can of worms canned (but
will it stay that way or will unexpected things crawl out of the
woodwork)?? Also don't we want nans to propgate sometimes so that peple
know there has bee a problem, rather than have a warning burried in
miles of output
Edward
.
--
-------------------------------------------------------------------
Dr Gary Thompson
Astbury Centre for Structural Molecular Biology,
University of Leeds, Astbury Building,
Leeds, LS2 9JT, West-Yorkshire, UK Tel. +44-113-3433024
email: garyt@xxxxxxxxxxxxxxx Fax +44-113-2331407
-------------------------------------------------------------------
Re: [bug #6503] Uncaught nan in xh_vect