Given the following program, which works if and only if the compiler 
allows higher than double precision, I was surprised to find that a 
certain compiler, for which pdp = 15, php = 18, printed y with only
8 correct significant digits instead of the 15 or 16 I had expected.
Intel and Sun f95, for both of which pdp = 15, php = 33, printed y 
with 16 correct digits. IMHO that was correct.

Has the first compiler a bug or have I misread the f95 standard? 

PROGRAM testprecision1 ! hp = higher than double precision if possible.
  IMPLICIT NONE        ! Should y have pdp good digits?
  INTEGER ,PARAMETER :: dp = kind(1d0), pdp = precision(1._dp), &
       hp = selected_real_kind(pdp+1),  php = precision(1._hp)
  REAL(hp) :: x = 1/9._hp, y
  CHARACTER:: fmt*24  ! Format that will depend on the value of php
  PRINT *,'DP kind',dp,'precision',pdp,' HP kind',hp,'precision',php
  WRITE(fmt,"(A,2(I0,A))") '(" ",A," = ",F',php+3,'.',php+1,')'
  y = 2*real(x,dp)
  PRINT fmt,  'x',x,'y',y
  PRINT "(7X,A)",'....v....1....v....2....v....3....v'
END PROGRAM testprecision1

-- John Harper, School of Mathematics, Statistics and Computer Science, 
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5662 fax (+64)(4)463 5045

John Harper <harper@mcs.vuw.ac.nz> wrote:

> Given the following program, which works if and only if the compiler 
> allows higher than double precision, I was surprised to find that a 
> certain compiler, for which pdp = 15, php = 18, printed y with only
> 8 correct significant digits instead of the 15 or 16 I had expected.
> Intel and Sun f95, for both of which pdp = 15, php = 33, printed y 
> with 16 correct digits. IMHO that was correct.
> 
> Has the first compiler a bug or have I misread the f95 standard? 
> 
> PROGRAM testprecision1 ! hp = higher than double precision if possible.
>   IMPLICIT NONE        ! Should y have pdp good digits?
>   INTEGER ,PARAMETER :: dp = kind(1d0), pdp = precision(1._dp), &
>        hp = selected_real_kind(pdp+1),  php = precision(1._hp)
>   REAL(hp) :: x = 1/9._hp, y
>   CHARACTER:: fmt*24  ! Format that will depend on the value of php
>   PRINT *,'DP kind',dp,'precision',pdp,' HP kind',hp,'precision',php
>   WRITE(fmt,"(A,2(I0,A))") '(" ",A," = ",F',php+3,'.',php+1,')'
>   y = 2*real(x,dp)
>   PRINT fmt,  'x',x,'y',y
>   PRINT "(7X,A)",'....v....1....v....2....v....3....v'
> END PROGRAM testprecision1

Intriguing. So I see. Simpler versions also exhibit the same phenomenon.
It's a little hard for me to pin down what triggers it and why. Looks to
me like you are reading it fine.

Well, ok, to be pedantic, the standard doesn't guarantee that you get
much of any precision at all in any operation. Just because a kind can
represent reals with 15 digits of accuracy doesn't guarantee that any of
the operations are accurate to even 1 digit. But that's purely academic.
I think it pretty clear that someting isn't working as intended with
compiler number 1 (which, oddly, seems to match the behavior of the
first compiler I tried).

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

John Harper wrote:
> Given the following program, which works if and only if the compiler 
> allows higher than double precision, I was surprised to find that a 
> certain compiler, for which pdp = 15, php = 18, printed y with only
> 8 correct significant digits instead of the 15 or 16 I had expected.
> Intel and Sun f95, for both of which pdp = 15, php = 33, printed y 
> with 16 correct digits. IMHO that was correct.
> 
> Has the first compiler a bug or have I misread the f95 standard? 
> 
> PROGRAM testprecision1 ! hp = higher than double precision if possible.
>   IMPLICIT NONE        ! Should y have pdp good digits?
>   INTEGER ,PARAMETER :: dp = kind(1d0), pdp = precision(1._dp), &
>        hp = selected_real_kind(pdp+1),  php = precision(1._hp)
>   REAL(hp) :: x = 1/9._hp, y
>   CHARACTER:: fmt*24  ! Format that will depend on the value of php
>   PRINT *,'DP kind',dp,'precision',pdp,' HP kind',hp,'precision',php
>   WRITE(fmt,"(A,2(I0,A))") '(" ",A," = ",F',php+3,'.',php+1,')'
>   y = 2*real(x,dp)
>   PRINT fmt,  'x',x,'y',y
>   PRINT "(7X,A)",'....v....1....v....2....v....3....v'
> END PROGRAM testprecision1
> 


Output from WIN32 gfortran (gcc version 4.3.0 20070824 (experimental) 
(GCC)) seems to be what you expect.

  DP kind           8 precision          15  HP kind          10 precision
    18
  x = 0.1111111111111111111
  y = 0.2222222222222222099
        ....v....1....v....2....v....3....v

On 23 f=E9v, 02:36, har...@mcs.vuw.ac.nz (John Harper) wrote:
> Given the following program, which works if and only if the compiler
> allows higher than double precision, I was surprised to find that a
> certain compiler, for which pdp =3D 15, php =3D 18, printed y with only
> 8 correct significant digits instead of the 15 or 16 I had expected.
> Intel and Sun f95, for both of which pdp =3D 15, php =3D 33, printed y
> with 16 correct digits. IMHO that was correct.
>
> Has the first compiler a bug or have I misread the f95 standard?
>
> PROGRAM testprecision1 ! hp =3D higher than double precision if possible.
>   IMPLICIT NONE        ! Should y have pdp good digits?
>   INTEGER ,PARAMETER :: dp =3D kind(1d0), pdp =3D precision(1._dp), &
>        hp =3D selected_real_kind(pdp+1),  php =3D precision(1._hp)
>   REAL(hp) :: x =3D 1/9._hp, y
>   CHARACTER:: fmt*24  ! Format that will depend on the value of php
>   PRINT *,'DP kind',dp,'precision',pdp,' HP kind',hp,'precision',php
>   WRITE(fmt,"(A,2(I0,A))") '(" ",A," =3D ",F',php+3,'.',php+1,')'
>   y =3D 2*real(x,dp)
>   PRINT fmt,  'x',x,'y',y
>   PRINT "(7X,A)",'....v....1....v....2....v....3....v'
> END PROGRAM testprecision1
>
> -- John Harper, School of Mathematics, Statistics and Computer Science,
> Victoria University, PO Box 600, Wellington 6140, New Zealand
> e-mail john.har...@vuw.ac.nz phone (+64)(4)463 5662 fax (+64)(4)463 5045

It looks like a compiler bug. Instead of REAL(x,dp), I also tried
DBLE(x) with the same result (only 8 digits) instead of 16 with other
compilers like ifort and gfortran.

You should report it to Andy ...