Jan van Oosterwijk wrote:
>
>
> [ snip ...]
>
>
> If you are interested in the highest available precision or range
> you can find it using the following module.
>
> !-->
> ! [JvO] 2000-08-13 Prec-mod.f90
> !-->
> ! Define highest integer range and real precision kinds.
> !-->
> module precision_M
> implicit NONE
> integer, parameter :: byte = selected_int_kind(1)
> integer, parameter :: word = selected_int_kind(range(1_byte)+1)
> integer, parameter :: long = selected_int_kind(range(1_word)+1)
> integer, parameter :: extd = selected_int_kind(range(1_long)+1)
> integer, parameter :: mpi = max(byte,word,long,extd) ! Highest
> ! ^^^
> integer, parameter :: sp = kind(1.0e0)
> integer, parameter :: dp = kind(1.0d0)
> integer, parameter :: ep = &
> & selected_real_kind(precision(1.0_dp)+1)
> integer, private, parameter :: c = (sign(1, ep) +1) / 2
> integer, parameter :: mpr = (1-c) * dp + c * ep ! Highest available
> ! ^^^ Another way to do the same.
This isn't guatanteed to be a portable solution. The standard does not
require kind values to increase as precision increases. It's become a
sort of defacto standard to have kind value be the same as the number of
bytes in the data thing (maybe with a control card option), but it's
not required. On processors that support more than one floating point
representation, say IEEE and a proprietary one with a bigger exponent
range and a smaller precision, then the relationship between kind number
and byte size must break down. Same thing could happen for integers if
the processor supported both ones and twos compliment arithmetic or
unsigned arithmetic. (Or maybe that's "one's and two's complement",
sigh.) The only safe way to get kind values is to read the fine manual.
Dick Hendrickson
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|