ross_at_cgl.ucsf.EDU writes:
>
>This would be new as of at least 5.0. In this release the use
>of unoptimized binaries for generating the reference numbers
>was discontinued, so it may be that machines tend to optimize
>the same way; however, unoptimized code should give more 'correct'
>answers insofar as there is a worthwhile distinction, so in general
>I'd trust the Intel numbers 'more', although there may be something
>in Dave Case's observation about the erfc function; however it didn't
>give a diff at step 1 and at step 100 the 'Ewald error' was still
>a small number and thus the diff might not be significant even if
>it was at step 1, if I am interpreting this 'estimate' correctly:
>
I took at a look at this and I noticed that the SGI produced what appeared
to be single-precision (stored into a double-precision, with all-zeros
beyond the last digit of the singleprecison) results for erfc() while
the glibc erfc() which is used on Linux gave double-precison values.
I checked both against Mathematica (which computes erfc() to arbitrary
precision) and the Linux erfc() values were equivalent to Mathematica's
values (to double precision).
However, I also noticed that sander's arguments to erfc() were slightly
different on SGI and Linux, which may also be causing some problems.
It's interesting that Dave Case noticed similar results on two Intel
OS's but I would suspect this is mostly by chance.
Dave
-----------------------------------------------------------------------------
Email:
-----------------------------------------------------------------------------
Received on Fri Aug 13 1999 - 13:48:28 PDT
