On 8/5/06, Chris MacRaild <c.a.macraild@xxxxxxxxxxx> wrote:
On Sat, 2006-08-05 at 00:08 +1000, Edward d'Auvergne wrote:
> > 2) there is an external module called fpconst which supplies similar
> > functionality. This relies on the python struct module to compare the
> > underlying bit sequence with the IEEE 754 standards. It seems to work
> > well on my machine, and I think most platforms should be compliant at
> > that level, but I'm not sure and I have limited opportunity to test
> > other platforms. On the up side the module is relatively small, and
> > could be incorporated into relax, so it need not be a dependency (its
> > under the Apache Licence).
>
> Would this module be useful for NaNs generated by the current code?
> Does it replace the inbuilt Python NaNs with it's own NaNs? The
> module's web page seems to be down at the moment.
>
fpconst won't override the inbuilt Python NaNs, but on the two machines
I have briefly tested it on, fpconst.isNaN() gives the right answer with
Python NaNs. So it will be useful in that it allows us to test output
from the current code for the pressence of NaNs. It does not provide a
complete and coherent set of NaN behaviour, though. This we might get
from Numpy, but I'm not absolutely sure.
If we made sure that all minimisation algorithms eventually terminate
via an iteration limitation, as you mentioned that NaNs propagate,
then do we need to catch NaN?
Re: [bug #6503] Uncaught nan in xh_vect