wrong xlf90 fp math ? 
Author Message
 wrong xlf90 fp math ?

The following program generates quite different output using nag f95
5.0 and xlf90 8.1.1.2

INTEGER, PARAMETER :: sp=KIND(1.0)
INTEGER, PARAMETER :: dp=KIND(1.0D0)
REAL(kind=sp), PARAMETER :: f13_sp=1.0_sp/3.0_sp
REAL(kind=dp), PARAMETER :: f13_dp=1.0_dp/3.0_dp
REAL(kind=dp), PARAMETER :: x=3.0_dp
write(6,*) x**f13_sp-x**(1.0_sp/3.0_sp)
write(6,*) x**f13_dp-x**(1.0_sp/3.0_sp)
write(6,*) x**f13_dp-x**(1.0_dp/3.0_dp)
END

nag :
  0.0000000000000000E+000
  -1.5740326153590445E-08
  0.0000000000000000E+000
xlf :
 0.157403261535904448E-07
 0.000000000000000000E+00
 0.000000000000000000E+00

Is xlf wrong, or nag, or is there no clear answer ?

Joost



Sat, 15 Jul 2006 04:54:40 GMT  
 wrong xlf90 fp math ?

Quote:

> The following program generates quite different output using nag f95
> 5.0 and xlf90 8.1.1.2
> Is xlf wrong, or nag, or is there no clear answer ?

There is no clear answer.  You can't count on exactness in
floatting point arithmetic.  If I followed the code correctly,
the NAG compiler is giving the "obvious" answer, but the
differences are all within plausible rounding error, so neither
can be said to be wrong.

At first guess, the ibm compiler might be computing the
1./3. accurately to double precision.  While you certainly
can't count on it, it isn't unarguably wrong either.  (Some
people might argue that it is wrong, but it isn't unarguable...
since I argue with it; it is a best a fine point).

If you have code that depends on the ibm answer, then that
code is certainly wrong.  If you have code that depends on
the nag answer, then I'd say that code is, well, questionable
at best.  Robust code shouldn't depend on such exact
comparisons.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain



Sat, 15 Jul 2006 05:29:02 GMT  
 wrong xlf90 fp math ?

 on Mon, 26 Jan 2004 13:29:02 -0800,

Quote:

>> The following program generates quite different output using nag f95
>> 5.0 and xlf90 8.1.1.2

>> Is xlf wrong, or nag, or is there no clear answer ?

>There is no clear answer.  You can't count on exactness in
>floatting point arithmetic.  If I followed the code correctly,
>the NAG compiler is giving the "obvious" answer, but the
>differences are all within plausible rounding error, so neither
>can be said to be wrong.

>At first guess, the ibm compiler might be computing the
>1./3. accurately to double precision.  While you certainly
>can't count on it, it isn't unarguably wrong either.  (Some
>people might argue that it is wrong, but it isn't unarguable...
>since I argue with it; it is a best a fine point).

>If you have code that depends on the ibm answer, then that
>code is certainly wrong.  If you have code that depends on
>the nag answer, then I'd say that code is, well, questionable
>at best.  Robust code shouldn't depend on such exact
>comparisons.

         If you care about this sort of thing, xlf has compiler
options (like -qfloat=rndsngl which forces rounding after every
single precision operation) which you should investigate.
                        James B. Shearer


Sat, 15 Jul 2006 08:31:41 GMT  
 wrong xlf90 fp math ?

Quote:

> There is no clear answer.  You can't count on exactness in
> floatting point arithmetic.  If I followed the code correctly,
> the NAG compiler is giving the "obvious" answer, but the
> differences are all within plausible rounding error, so neither
> can be said to be wrong.

> At first guess, the ibm compiler might be computing the
> 1./3. accurately to double precision.  While you certainly
> can't count on it, it isn't unarguably wrong either.  (Some
> people might argue that it is wrong, but it isn't unarguable...
> since I argue with it; it is a best a fine point).

That is exactly what XLF is doing.  The OP may want to take a look at
the documentation for the -qfloat option in his XLF user's guide.  The
-qfloat=rndsngl option is the one he is looking for.  Without this
option (or one of the other options that turns it on, like -qarch=ppc),
XLF does single precision floating-point operations in double precision,
rounding only at the end of the complete expression evaluation instead
of each operation.  This can give results that aren't exactly
IEEE-compliant, but on some (mostly older) systems, it's faster.  With
this option, I obtained the same results from XLF as the OP got from the
NAG compiler (give or take a 17th significant digit).


Sat, 15 Jul 2006 09:02:04 GMT  
 wrong xlf90 fp math ?

Quote:
> XLF does single precision floating-point operations in double precision,
> rounding only at the end of the complete expression evaluation instead
> of each operation.  This can give results that aren't exactly
> IEEE-compliant, but on some (mostly older) systems, it's faster.  With
> this option, I obtained the same results from XLF as the OP got from the
> NAG compiler (give or take a 17th significant digit).

The case was derived from a bug in my code (using 1./3. instead of
1.D0/3.D0) that only showed up after porting to a different system,
which is unfortunate (and wouldn't have happened if things had to be
strictly IEEE). The mentioned option should help to localize these
problems earlier in the future.

Thanks,

Joost



Sat, 15 Jul 2006 16:11:48 GMT  
 wrong xlf90 fp math ?

Quote:


> > Is xlf wrong, or nag, or is there no clear answer ?
> There is no clear answer.  You can't count on exactness in
> floatting point arithmetic.  If I followed the code correctly,
> the NAG compiler is giving the "obvious" answer, but the
> differences are all within plausible rounding error, so neither
> can be said to be wrong.

I think Joost's issue was whether, given the definitions

    INTEGER, PARAMETER :: sp=KIND(1.0)
    REAL(kind=sp), PARAMETER :: f13_sp=1.0_sp/3.0_sp

the term "f13_sp" and the subexpression "(1.0_sp/3.0_sp)" should be
rigorously equivalent.  I would expect them to be, and I would find it
--ahem-- "peculiar" if the standard left the issue open.

--
pa at panix dot com



Sat, 15 Jul 2006 23:27:32 GMT  
 wrong xlf90 fp math ?

Quote:

> > XLF does single precision floating-point operations in double precision,
> > rounding only at the end of the complete expression evaluation instead
> > of each operation.  This can give results that aren't exactly
> > IEEE-compliant, but on some (mostly older) systems, it's faster.  With
> > this option, I obtained the same results from XLF as the OP got from the
> > NAG compiler (give or take a 17th significant digit).

> The case was derived from a bug in my code (using 1./3. instead of
> 1.D0/3.D0) that only showed up after porting to a different system,
> which is unfortunate (and wouldn't have happened if things had to be
> strictly IEEE). The mentioned option should help to localize these
> problems earlier in the future.

Something I've found to work for me is to eliminate (or at least minimise) mixing double
and single precision arithmetic. And, as others have also mentioned, I always use the
-qfloat=rndsngl on IBMs. I also use the -qfloat=nomaf as well but the impact of that is
smaller than the rndsngl...and it further slows stuff down. I needed those switches to
achieve the same results on an IBM compared to a variety of other platforms (SGI, Sun,
etc.) For production runs (i.e. not testing or debugging code) on IBMs, I use neither
rndsngl or nomaf since double precision is my default real type (set in the code, not via
compiler options.)

cheers,

paulv

--
Paul van Delst



Sun, 16 Jul 2006 22:27:37 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. integer math-based FP library?

2. More than two FP-TB-3 with FP-TC-120

3. OO and FP (was subtyping in FP)

4. FP Component Libraries? (FP vs OOP)

5. FP to FP Binary/Hex

6. built-in math functions (was Re: RXMATH math package for REXX)

7. Additions to math.c (more math functions)

8. Uncommon Math Functions on a Math-Coprocessor

9. Uncommon Math Functions on a Math-Coprocessor

10. Grabbing Wrong Field, Wrong File

11. Where am I wrong?(this has to be wrong, it can't be so simple)

12. Stippled text on a canvas drawn in the wrong place using the wrong color

 

 
Powered by phpBB® Forum Software