[R-pkg-devel] Modernizing legacy Fortran:, REAL(kind=8)
Thomas Petzoldt
thom@@@petzo|dt @end|ng |rom tu-dre@den@de
Wed Aug 30 08:43:04 CEST 2023
Hi,
some package maintainers including me got a reminder from Prof. Brian
Ripley to modernize REAL and INTEGER declarations using the KIND option:
On 29.08.2023 at 19:31 Prof Brian Ripley wrote:
> According to the Fortran standards, numerical values are just an
> enumeration, and what e.g. real(kind=4) means (or even if it is
> accepted) is implementation dependent.
>
> We see such constructs in packages
[... line with packages deleted to avoid exposing the other packages and
authors]
> Please change them to something portable (kind(1.0) or kind(1.0d0} are
> commonly used, as is c_double from iso_c_binding).
>
> Before 2023-09-26 to safely retain your package on CRAN (some of you
> have earlier deadlines for other issues).
We use a lot of legacy code that though partly modernized due to similar
requests, still uses a mix of DOUBLE PRECISION and a few REAL(KIND=8)
and COMPLEX(KIND=8). As the code will still remain legacy style with
respect to some other constructs, I wonder what to use to go a step
forward, but remain as consistent as possible, which is of course a
compromise. I see the following options:
a) change REAL(kind=8) back to DOUBLE PRECISION that is again old style.
It seems to be portable and is still widely used.
b) just formally change the few occurrences to:REAL(kind=0.0d) as
suggested. It is easy, but inconsistency remains.
c) or, define "dp" as recommended in modern style guides and use it
instead of REAL(kind=8) and the future also for DOUBLE PRECISION this way:
integer,parameter::dp=kind(0.0d0)
and then
real(dp)::a,b,c
However, this would need changes at many places, the mix between old and
new constructswill generally get worse.
Another question is, that with either of these, we may not be sure to
use 8 byte double. Changing this could influence for precision and
pointer arithmetics.
Any recommendations? Thanks a lot!
Thomas
More information about the R-package-devel
mailing list