On 8/7/06, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
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.
Did you contact the FSF about the issue?
Whether to mix software covered under these two different licenses
*must* be a determination made by those attempting such a synthesis.
According to the FSF list of licences
(http://www.gnu.org/philosophy/license-list.html), all of the Apache
licences are GPL incompatible. For version 2 of the licence they say:
This is a free software license but it is incompatible with the GPL.
The Apache Software License is incompatible with the GPL because it
has a specific requirement that is not in the GPL: it has certain
patent termination cases that the GPL does not require. (We don't
think those patent termination cases are inherently a bad idea, but
nonetheless they are incompatible with the GNU GPL.)
After looking at the GPL FAQ and thinking about it for a while, I
don't believe the file can be put into the relax distribution. From
the link http://www.gnu.org/licenses/gpl-faq.html#MereAggregation I
would classify the co-distribution of relax with fpconst.py as an
imported module to be a single program rather than an aggregation of
programs. Because of the licence incompatibility, the link
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleAlone explains
how it is not legal to co-distribute.
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)
Because what I wrote above, it would probably have to be listed as a
dependency. However I don't really like that idea as dependencies are
a pain. Do you have the link to it's homepage? All the links I've
tried that look like it would be its homepage (for example
http://www.warnes.net/rwndown) are still down. Having it in-built
into relax would be better.
However I still question whether the floating point value of NaN
actually needs to be caught at all - it would be useful, but is
unnecessary. It's a rare occurrence to begin with and I can easily
modify the optimisation component of relax to break the infinite
loops. Therefore does anything else need to be done? It will be
glaringly obvious in the final results file if NaNs get through the
analysis. And if there is an issue in relax's handling of NaN then
that should be classified as a relax bug.
> 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?)
Who knows what end users will run it on? Someone may still be using a
vax ;) Not very important though and can be handled once a problem
arises - assuming that catching the NaN is important.
> 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
It can't be removed - this is a test fundamental to all optimisation
algorithms I know of. Its removal will result in infinite
optimisation loops.
NaN should propagate - however I do see one point at which they will
disappear and that is during AIC model selection. The AIC value will
be NaN (NaN + 2k = NaN) and any model with a non-NaN AIC value will be
selected. Unless of course all model-free models for that residue are
affected. Yet if they do propagate the results for that residue will
make no sense. That should be an indication to the end user that
there is a problem and that they should look at the final results file
in detail - none of the logs or intermediate results files need to be
initially examined to identify that there is a problem. If, however,
we can prevent users from encountering this problem as much as
possible, while making it possible to continue running if it does
occur, then NaNs shouldn't be a problem in relax.
Edward
Re: [bug #6503] Uncaught nan in xh_vect