On 8/9/06, 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
Using this test means that the isinf() bit pattern testing function
doesn't need to be implemented.
>
> > > This avoids fpconst.py and the switch from Numeric to Numpy. The
> > > question is whether to use the RelaxErrors or set some warning? Would
> > > this be alleviated by Gary's proposal of saving the program state just
> > > prior to throwing the error? For example using the function
> > > 'self.save()' within 'generic_fns/state.py', printing the error
> > > message, then quitting.
> >
> > Saving state as part of the exception handling is a nice idea, but has
> > its limitations. Because the error could be thrown before, during or
> > after some change to the program state, the state which is saved will be
> > undefined and possibly inconsistent. As such a saved state may be of
> > limited use to most users. It would be a very valuable tool for
> > debugging, though.
>
> I suppose it will probably leave too many temporary files lying
> around. relax tends to throw errors if you do the slightest thing
> wrong.
True. One option would be to leave the current behaviour as default, and
have an optional debugging mode which would allow for saving of state on
exceptions. Another feature which might be modified in debugging mode is
the suppression of tracebacks on KeyboardInterupt - it is sometimes nice
to know exactly what you have interupted when you are forced to ctrl-c
That's a an idea, dump the state if relax is run with the --debug
flag. I'm not sure I follow what you mean with the behaviour of the
keyboard interrupt? Do you mean that when ctrl-c is hit when run with
the --debug flag the program instantly and silently terminates without
printing the KeyboardInterrupt message?
Edward
Re: Proposed solution to bug #6503.