Re: [bug #20821] Optimisation failure / round error on windows 64 bit -- June 19, 2013 - 07:43

Hi Edward.

I will fix it.

Just to make it clear.

I use the winpython system on my windows computer, not EPD.
That is to produce a total "standalone" python/relax program, without the necessity to have

admin rights for installation. And the possibility to drag it along on a USB stick with me.
And to easily put it on teaching computers, without to involve the IT department.
I still need to figure out, if you can build relax with mingw, which would be

very nice. The necessicity for Install of Visual Studio Express 2012, which is several gigabytes,

is quite unwanted.

On linux, I have used EPD to solve not to install wxpython on all lab computers, and
solve python dependencies for all of them. Just installing it in the EPD python.

The entropy has grown in our linux installations, and so I am looking for a central solution.

Best
Troels


Troels Emtekær Linnet


2013/6/18 Edward d'Auvergne <edward@xxxxxxxxxxxxx>:
> Exactly, that is the solution!  I've noticed in general that MS
> Windows has roughly the same precision as the other systems.  You can
> see that in the comments of the other tests.  I also do not see this
> precision failure on 32-bit Windows 2000 or 64-bit Windows Vista and
> 7.  Why your specific system is 4 orders of magnitude less precise is
> completely unclear to me.  Maybe it is the use of the EPD distribution
> (https://www.enthought.com/products/epd/), as this is the biggest
> difference with the systems.  I really don't know.  But in any case,
> the results are precise enough for any analysis of real data.
>
> Regards,
>
> Edward
>
>
>
>
> On 18 June 2013 18:42, Troels Emtekær Linnet <tlinnet@xxxxxxxxx> wrote:
>> 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