mail[Fwd: Re: Proposed solution to bug #6503.]


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Gary S. Thompson on August 09, 2006 - 18:00:

-- ------------------------------------------------------------------- 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 -------------------------------------------------------------------


--- Begin Message ---
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....



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



What do you think? I think I covered most of the issues. I've made a
branch of the 1.2 line located at
svn://svn.gna.org/svn/relax/branches/nan_catch_test which has all
these changes. Feel free to play around and modify this branch.


I'll have a bit more of a look, but it seems like a good fix.


But does it resolve the issue of whether the program should throw an
error and terminate or throw a warning and continue?




See my response on the previous thread. I'll post a small proposed modification later.

Chris



Edward





_______________________________________________
relax (http://nmr-relax.com)

This is the relax-devel mailing list
relax-devel@xxxxxxx

To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at
https://mail.gna.org/listinfo/relax-devel

.





--
-------------------------------------------------------------------
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
-------------------------------------------------------------------




--- End Message ---

Related Messages


Powered by MHonArc, Updated Thu Aug 17 14:20:57 2006