On Fri, 2013-04-26 at 23:55 +0200, Giorgio Pastore wrote:
> Van Snyder wrote:
> ....
> > If you're writing specific procedures for a generic, and you want to
> > handle both precisions guaranteed by the standard, i.e., default real
> > and double precision, it's not a good idea to use SELECTED_REAL_KIND(6)
> > for one of them, and SELECTED_REAL_KIND(12) for the other one. On some
> > platforms, these have the same kind type parameter, so your code won't
> > even compile.
>
> Possible. But I wouldn't like to use blindly a software using two
> representations for reals without knowing anything about the underlying
> precision. And if you know it, there is no problem in using the right
> request for decimal figures. If, in the future, those requests would
> result in the same kind value, the compiler will complain.
It is unhelpful if the compiler refuses to compile your software,
especially if you have several million lines of it, and even more
embarrassingly if it's a client, not yourself, who's trying to compile
it.
You choose the precision you need for your application software. For
support software, such as special function evaluation, quadrature, ...,
even something as mundane as a routine that dumps arrays just the way
you want them, write one specific version using default real, and
another using double precision (you choose whether to spell it DOUBLE
PRECISION or KIND(0.0d0)), and glue them together with a generic name.
Then, when you need a Bessel function in your application that needs 11
digits, the compiler will choose the correct one from your generic.
That way, if you move your code from, say, your 32-bit development
platform, where 6-digit floating point and 12-digit floating point have
different kind type parameter values, to your 64-bit production
platform, where they have the same kind type parameter values, your
software still compiles, and probably works.
> There is no reason, but compatibility issues with legacy software, to keep
> the old double precision type keyword. Thus, if we want to move from
> previous century Fortran to the contemporary one, we should try to adapt
> our programming style to the new standard, instead of insisting in keeping
> kind of geological stratification of keywords and concepts.
>
> Giorgio Pastore
|