Yes the exact result after rounding will depend on the order of arithmetic
operations and even an apparently insignificant change to the high-level
code can change the order in which an optimising compiler generates the
corresponding machine code. The operation order can also be influenced by
differences in hardware, e.g. different floating-point chip. If you could
absolutely specify the order of arithmetic operations in the generated
machine code you would get identical results, assuming of course that the
hardware always obeys the same rounding rules (if it's strictly IEEE it
should).
Sometimes you read that you should never perform an exact equality
comparison on floating point variables or constants. While this is in
general a good rule to follow it doesn't always apply. It's the safe
option if there's any possibility that the calculations to obtain the
values of the variables in question have been done differently, including
in a different order. If the calculations have been performed identically
then an exact comparison will work.
For example it will work in this (admittedly trivial) case:
REAL*4 A
A = 1.23456789
IF (A.EQ.1.23456789) ...
because the constant 1.23456789 will be rounded in memory identically (to
approximately 1.234568) in every instance (in fact a smart compiler will
recognise that the two instances of the constant are identical and assign
them to the same memory location so then there's no doubt it will work!).
Cheers
-- Ian
On 7 March 2013 13:59, Adam Ralph <[log in to unmask]> wrote:
>
>
>
> Dear Ed,
>
>
> It is not usual to find small discrepancies in floating point
> calculations. A simple test to demonstrate this is to calculate
> sum 1.0/n n=1->1000000 and n=1000000->1. You might find
> that the results differ. For 4-byte reals will tend to differ in the
> 6th significant digit and 8-byte reals in the 15th. Compilers are a
> lot more complicated so I am not surprised the results differ slightly.
> In general there is a trade-off between speed and precision, the
> -ffast-math option is obviously faster but results will be less precise.
> Or memory and precision, double vs single precision. The speed up
> in refmac is impressive but there are also the libraries to consider.
>
>
> Adam
>
>
>
>
>
>
>
>
>
> > Thierry,
>
> > I ran both versions on the same input file and numerical results are
> > essentially the same. After 10 cycles of refinement the r.m.s.d.
> > between two models produced with different versions is <0.0004A.
> > Basically, about 5% of coordinates differ in the last digit (i.e. by
> > 0.001A). Frankly, I expected results to be exactly identical, but the
> > difference is too small to be of concern, imho.
> >
> > Cheers,
> >
> > Ed.
>
> On 03/04/2013 10:19 AM, Fischmann, Thierry wrote:
> > Ed,
> >
> > Are the numerical results the same ? Not likely that there is a problem.
> But if you haven't done it already it is worth checking by running the
> tests provided with the suite. Aggressive optimization can be a source of
> bugs.
> >
> > Best regards
> > Thierry
> >
> > -----Original Message-----
> > From: CCP4 bulletin board [mailto:[log in to unmask]] On Behalf Of
> Ed Pozharski
> > Sent: Monday, March 04, 2013 8:55 AM
> > To: [log in to unmask]
> > Subject: Re: [ccp4bb] compiling refmac5 on Ubuntu 12.04
> >
> > On Mon, 2013-03-04 at 11:37 +0000, Marcin Wojdyr wrote:
> >> Running times were, correspondingly, 32.2s, 35.1s and 18.7s.
> >>
> > Numbers are almost too impressive to believe :)
> >
> > How does it compare with ifort (which I thought should be the fastest
> > option on intel processors and thus unavailable (not free) for most DIY
> > compilation given licensing issues)?
> >
>
>
> > --
> > Oh, suddenly throwing a giraffe into a volcano to make water is crazy?
> > Julian, King of Lemurs
>
