Hi, You should try the following. When the number is less than 1e-307, print out all the parameters of the model. What do you see? Or print out all arguments input into the function. It might be possible to catch this on line 1 instead.
Regards, Edward On 21 May 2014 19:24, Troels Emtekær Linnet <[email protected]> wrote: > Hi Ed. > > The trunk code says: > t113 = t97_nt99 - t112 > t115 = num_cpmg > t116 = power(0.5*(t97_t99 + t112), t115) > > I have tried to catch the underflow of t116, the power function. > This is when a number is represented as less than 1.e-307 (something). > >>>> import numpy as np >>>> print np.finfo('d') > Machine parameters for float64 > --------------------------------------------------------------------- > precision= 15 resolution= 1.0000000000000001e-15 > machep= -52 eps= 2.2204460492503131e-16 > negep = -53 epsneg= 1.1102230246251565e-16 > minexp= -1022 tiny= 2.2250738585072014e-308 > maxexp= 1024 max= 1.7976931348623157e+308 > nexp = 11 min= -max > --------------------------------------------------------------------- > > So, in the array, I look for the maximum power, and match the value > with the list, and see if that value is below the limit. > > Hm, maybe I should delete it again. > But I caught other numpy-raises error, found in the test-suite. > > But here this bug is triggered by an array, which is sent in with tcp > array of nan. > > I think it is because spin :71@N miss data from field 800. > > Best > Troels > > 2014-05-21 19:03 GMT+02:00 Edward d'Auvergne <[email protected]>: >> Hi, >> >> Maybe this shouldn't be a bug? It's only present in your 'disp_speed' >> branch and is only seen with a debugging flag turned on. If you add >> the check I mentioned at >> http://www.mail-archive.com/[email protected]/msg05731.html to the >> first line of this function, maybe all the checks you have added >> compared to the trunk could be removed and this issue will just >> disappear. It would be worth trying. Also, what does the following >> line do? >> >> # Calculate lowest positive val, which raised to the power will >> not be represented less than 1.-e300. >> low_pos_rep = power(1.e-300, 1./max_t115) >> >> Why is max_t115 inverted when the original code from Nikolai and Martin is: >> >> t115 = N/2; >> t116 = (t69/2+t83/2+t92/2+t96/2+t112/2).^t115; >> t118 = 1./t112; >> t120 = t69+t83-t92-t96+t112; >> t122 = (t69/2+t83/2+t92/2+t96/2-t112/2).^t115; >> >> Here t115 is never inverted. The 1/max_t115 is causing this divide by >> zero error. Anyway, adding the 'No Rex' check in the above link will >> likely make all of this redundant. >> >> Regards, >> >> Edward >> >> >> >> >> On 21 May 2014 18:46, Troels E. Linnet <[email protected]> >> wrote: >>> Follow-up Comment #3, bug #22065 (project relax): >>> >>> This only fails when --numpy-raise is set on. >>> >>> _______________________________________________________ >>> >>> Reply to this item at: >>> >>> <http://gna.org/bugs/?22065> >>> >>> _______________________________________________ >>> Message sent via/by Gna! >>> http://gna.org/ >>> _______________________________________________ relax (http://www.nmr-relax.com) This is the relax-devel mailing list [email protected] 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
