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.
Chris
Re: Proposed solution to bug #6503.