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).
>
>
Yep I am pretty leary of this as well. All that is guarunteed is the bit
patterns (and remember the function has to look at the endianness of the
system)
Do you think the Python NaNs will all be double precision (as with all
the other floating point numbers)?
yes I expect so i can check the type and unpack them to check
regards
gary
n.b. I wouldn't trust anything that requires other bit patterns (e.g. a
vax or very old mips) as this implies that they are not ieee 754
compliant and propgation of nan and other floating point behaviour will
be different from expected
If this ever becomes an issue, the isnan() function could be modified
to handle different architectures. Adding a test to the test-suite
for the isnan() function would be perfect for catching this problem.
It's not something that needs to be implemented - if someone does try
to use relax on a vax or some other ancient system the test-suite will
fail and they can then send a message or bug report. Then, maybe, we
could consider adding NaN support for the vax. But until then it's
not worth the effort.
Edward
.
--
-------------------------------------------------------------------
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.