> Alois Steindl wrote:
> >
> > Hello,
> > it looks indeed cryptographic. For the example given kind(1.0d0)
> > should really be preferrable. But think of the possibility of having 3
> > different precisions, then one might do something like
> > integer, parameter :: sp = selected_real_kind(1)
> > integer, parameter :: dp = selected_real_kind(precision(1.0_sp)+1)
> > integer, parameter :: qp = selected_real_kind(precision(1.0_dp)+1)
> >
> > This declaration would also work in case that the standard single
> > precision on the machine corresponds to dp above. (I imagine some
> > compiler with real=real*8, double=real*16 and an additional 'short
> > real'=real*4).
>
> And what about compilers with only real*8 and real*16 (without real*4) ?
>
> And what about compilers with real*1, real*2, real*4, real*8, .... ?
>
> Concerning these precision issues, I finally conclude that the best way (at
> least for me) was to write one different tiny module for each compiler, where
> the kinds are hard-coded according to the processor kind values:
>
> on a machine with 4, 8 & 16 bytes reals:
> integer, parameter :: sp=4, dp=8, qp=16
4, 8, and 16? How do these relate to the kind values?
> on a machine with only 8 & 16 bytes reals:
> integer, parameter :: sp=8, dp=8, qp=16
> and so on....
> I write my library routines by using only REAL and DOUBLE PRECISION, and I use
> REAL(sp) or REAL(dp) in my programs.
>
> Pierre Hugonnet
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|