Edward d'Auvergne wrote:
On 8/9/06, Chris MacRaild wrote:
On Wed, 2006-08-09 at 12:42 +0100, Gary S. Thompson wrote:
> Chris MacRaild wrote:
>
> >On Wed, 2006-08-09 at 19:48 +1000, Edward d'Auvergne wrote:
> >
> >
> >>>>As the function 'self.grid_search()' executes 'self.minimise()'
this
> >>>>single change will cover both the grid search and
minimisation. The
> >>>>function 'isnan()' currently non-existent but could be
implemented as
> >>>>Gary previously mentioned by checking the hex bit pattern of NaN.
> >>>>
> >>>>
> >>>If isnan() is to be implimented in this way, then a similar
isinf() is
> >>>by far the best way to go. float('inf') is platform dependent, and
> >>>certainly will not work under Windows (I think I'm right in saying
> >>>windows has no valid string representation of inf or nan that
would work
> >>>in that context).
> >>>
> >>>
> >>That one I didn't know about. I thought Python handled inf
correctly
> >>but checking the bit value should be easy. What about checking that
> >>the value is less than 1e300 instead, as that is the arbitrary
> >>starting point for the grid search?
> >>
> >>
> >
> >In practise I'm fairly sure that will work. The purist might say that
> >the starting value should be INF, and the test should be for INF,
but I
> >can't imagine anyone wanting to accept a grid search with Chi2 >
1e300
> >
> >
>
> does comparison against inf work on all architectures/compilers....
>
The official line is that all Python behaviour with respect to special
float values is an accident arising from the specific
architecture/compiler comination. This applies to NaN, +INF, -INF, and
signed zero. That said, I dont recall INF behaviour being raised as an
issue in the various email list discussions I've read. I've just done a
quick test on my machine and see none of the craziness I saw with NaN
comparisons.
Maybe we could add to the test-suite two tests, one to see if the
isnan() functions properly and the other to test if isinf() functions.
The NaN and Inf values can be generated and the functions tested to
see if they recognise them. These two functions need to be added to
the 'nan_catch_test' branch. An idea may be to implement both of
these within a file called something like 'float.py' in the base relax
directory. Both functions could be accessible in the structure
'self.relax.float'. Gary, would you like to use the information in
your post at
https://mail.gna.org/public/relax-devel/2006-08/msg00013.html
and try to implement the NaN bit pattern matching function? Do you
think signalling NaNs are an issue or would the generated NaN be a
quite NaN?
Edward
.
yep I can have a go at that. As to signalling to the difference between
signalling and non signalling nans I am fairly hazy...;-) I can't see
any use to make a distinction at the moment. If this is a problem we can
always add a flag to the function plus default behaviour. Anyway just to
be sure I will dig a little deaper...
regards
gary
--
-------------------------------------------------------------------
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: Proposed solution to bug #6503.