Hi Ed. I will check it.
I did the implementation in commit 23246 and 23268. Best Troels 2014-05-21 19:33 GMT+02:00 Edward d'Auvergne <[email protected]>: > 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
