Idea: support different real and complex kinds

[hsnyder]

It looks like FFTPACK has "double precision" hard coded in. Would the maintainers be open to accepting a pull request that made this configurable? I would:

• change all instances of "double precision" to "real(rk)" and do the same for complex
• add a new file, that contains "integer, parameter :: rk = kind(1.0d0)"
• include that new file in all the old fortran77 files, so that the kind being used could be changed at compile time in exactly one place.

We could use a module instead of "include", but I'm not familiar enough with old-style loose functions to know if that would work.

The end result would be that the functions are still only provided for one kind, but rather than that kind being hard-coded to double precision, the user could choose the kind themselves. And just to be clear, I'm offering to do this, not requesting that someone else do it (though that's fine too, of course).

So what do we think? Does that involve too many changes to the old code? Or is it ok?

[certik]

I think that works and is a good idea.

[zoziha]

I also think this is a good idea. This approach, I believe, has a certain amount of work, but it's okay.
Maybe we can change the kind of fftpack like this in the future until we have a Fortran Generics solution:

module fftpack_kind
 #if defined(SP)
     integer, parameter :: rk = sp
 #elif defined(QP)
     integer, parameter :: rk = qp
 #else
     integer, parameter :: rk = dp
 #endif
end module fftpack_kind

For the fpm command:

fpm build --flag "-DSP"

[certik]

@zoziha great idea. I was wondering about precisely this point.

[jacobwilliams]

Another option: use something like what I describe here: https://fortran-lang.discourse.group/t/library-exporting-interface-for-multiple-real-kinds/2686 to provide all the interfaces simultaneously. Is that useful for some applications? IDK.

[arjenmarkus]

See my reply to that thread. Op zo 30 jan. 2022 om 20:04 schreef Jacob Williams ***@***.***

…

: Another option: use something like what I describe here: https://fortran-lang.discourse.group/t/library-exporting-interface-for-multiple-real-kinds/2686 to provide all the interfaces simultaneously. Is that useful for some applications? IDK. — Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR3H2DDNIDVNXO7LRYLUYWDUDANCNFSM5DYBGZ7Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[zoziha]

There is another way to support multiple precision:

1. Use real to define real number instead of real(dp), and not explicitly define real number kind will make fftpack use the default real number kind, usually real32;
2. Compilers generally provide options to change the default real number kind, such as gfortran's -fdefault-real-8

[arjenmarkus]

That would be a bad idea in my opinion: - Not all compilers support that and the ones that do, come with a lot of caveats - ask Steve Kargl about it. - You would force people to use that option for at least part of their code nd it is easy to forget it. - How would you be able to support more than one type in the same program? My apologies for being so negative about it, but it is really a bad idea :). Op vr 27 mei 2022 om 11:29 schreef zoziha ***@***.***>:

…

There is another way to support multiple precision: 1. Use real to define real number instead of real(dp), and not explicitly define real number kind will make fftpack use the default real number kind, usually real32; 2. Compilers generally provide options to change the default real number kind, such as gfortran's -fdefault-real-8 — Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR5DVSINCTVXGKS7O7LVMCIWTANCNFSM5DYBGZ7Q> . You are receiving this because you commented.Message ID: ***@***.***>

[jacobwilliams]

This is what I do in my codes:

    module splpak_module

    use iso_fortran_env

    implicit none

    private

#ifdef REAL32
    integer,parameter :: wp = real32   !! Real working precision [4 bytes]
#elif REAL64
    integer,parameter :: wp = real64   !! Real working precision [8 bytes]
#elif REAL128
    integer,parameter :: wp = real128  !! Real working precision [16 bytes]
#else
    integer,parameter :: wp = real64   !! Real working precision if not specified [8 bytes]
#endif

    integer,parameter,public :: splpak_wp = wp   !! Real working precision

...

That way wp (or rk or whatever) can be a private variable used in the module. Then fftpack_wp is exported (we don't want to export the two-letter version for fear of namespace collisions. I think the explicit REAL32, etc is better than just SP, etc for the preprocessor directives.