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