PR #62 made a global switch from double precision to default real to support running do concurrent on GPUs. As suggested by @certik, a common practice is to use explicit kind parameters to allow for different precisions. As demonstrated by the aforementioned PR, a global precision change touches hundreds of lines across tens of files. For now at least, we should consider adopting the common practice of using defining named kind parameters (constants) for use throughout the code. I'm reasonably confident that if I try to do this myself, I will likely miss some of the required changes. This might be best accomplished in a (semi-)automated way with a script or with AI or with an AI-generated script.
The categories of required work include
I think it's ok to leave procedure names such as scalar_3D_premultiply_real as is.
The biggest downside of the above approach is that it requires recompiling when switching precision and it precludes mixed-precision (as does the current approach merged in the aforementioned PR).
FWIW, my preference for a long-term solution would be to instead use
- Parameterized derived types,
- Templates, or
- Generic subprograms.
At present, however, approach 1 is a lot of work and restricts us to very recent versions of most compilers. Approach 2 is supported only by one compiler experimentally: lfortran. Approach 3 probably has no compiler support yet.
PR #62 made a global switch from
double precisionto defaultrealto support runningdo concurrenton GPUs. As suggested by @certik, a common practice is to use explicit kind parameters to allow for different precisions. As demonstrated by the aforementioned PR, a global precision change touches hundreds of lines across tens of files. For now at least, we should consider adopting the common practice of using defining named kind parameters (constants) for use throughout the code. I'm reasonably confident that if I try to do this myself, I will likely miss some of the required changes. This might be best accomplished in a (semi-)automated way with a script or with AI or with an AI-generated script.The categories of required work include
formal_constants_mcontainingfp, andFORMAL_REAL_KIND, that facilitate selecting the global precision at compile timesrc,example, andtest, replacerealwithreal(fp)in all declarations1D0, with1_fpreal(foo), withreal(foo, fp)[real::]with[real(fp)::]realanddouble precision. (This could have the impact of doubling the CI time.)I think it's ok to leave procedure names such as
scalar_3D_premultiply_realas is.The biggest downside of the above approach is that it requires recompiling when switching precision and it precludes mixed-precision (as does the current approach merged in the aforementioned PR).
FWIW, my preference for a long-term solution would be to instead use
At present, however, approach 1 is a lot of work and restricts us to very recent versions of most compilers. Approach 2 is supported only by one compiler experimentally:
lfortran. Approach 3 probably has no compiler support yet.