[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