Allright.
The problem lies in:
test_opt_constr_cd_mt_S2_0_970_te_2048_Rex_0_149
From comments:
32-bit i686 Linux. s2 = 0.9700000000219662
64-bit x86_64 Linux. s2 = 0.9700000000219674
32-bit powerpc Darwin S2 = 0.9700000000219674
64-bit i386 Darwin = 0.9700000000219674
Matched value = 0.9700000000219674
windows 7 = 0.9700002183674102
The assert equal as standard goes to 7 decimals.
a = 0.9700000000219674
b = 0.9700002183674102
print a-b
-2.18345442837e-07
So, if the solution would be lower the assert equal to 6 decimal, it
will go fine.
Is that the solution?
And I do not understand why windows go so crazy wrong, compare to the
other systems.
System: Windows
Release: 7
Version: 6.1.7601
Win32 version: 7 6.1.7601 SP1 Multiprocessor Free
Distribution:
Architecture: 64bit WindowsPE
Machine: AMD64
Processor: Intel64 Family 6 Model 37 Stepping 2, GenuineIntel
Python version: 2.7.5
Numpy version: 1.7.1
Libc version:
s2: 0.9700002183674102
te (ps): 2048.015293187
rex: 0.14899473115727899
chi2: 2.3195994119090742e-10
iter: 116
f_count: 411
g_count: 411
h_count: 0
warning: None
Troels Emtekær Linnet
2013/6/18 Edward d'Auvergne <edward@xxxxxxxxxxxxx>
Yes, the problem is a precision issue. Your system ends up with
slightly different results from the perfect synthetic values. This is
not an issue though, as 0.9700002183674102 is pretty much the same as
0.970. Note the comments in that system test - it would be useful to
add an entry for the results from your system. These comments are
used to track and act as a record of how optimisation is different on
each system. It is useful to see which systems are not so accurate.
This is not the fix though.
The problem is within the value_test() method. Look carefully at how
the precision is set to 5 decimal places for model-free order
parameters and 4 for correlation times. Then look at which parameter
is failing. I'll give you another hint if this is not enough.
Regards,
Edward
On 18 June 2013 18:04, Troels E. Linnet
<NO-REPLY.INVALID-ADDRESS@xxxxxxx> wrote:
Follow-up Comment #1, bug #20821 (project relax):
It seems from the log file, that the precision on the windows compiled
system
is bad.
The true value should be:
S2=0.970, te=2048, Rex=0.149
Windows compiled minimise to: s2 0.9700002183674102
which is bad.
But, I don't know where to start?
Is it something with the compilation?
This is 64 bit compiled, and not 32 bit compiled.
Log file is provided.
(file #18115)
_______________________________________________________
Additional Item Attachment:
File name: 20130618_relax_disp_testsuite.txt Size:273 KB
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?20821>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
relax (http://www.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
Re: [bug #20821] Optimisation failure / round error on windows 64 bit