Skip to content

Automatically determine extended double precision and quad precision support. #995

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
banana-bred opened this issue May 22, 2025 · 0 comments
Labels
idea Proposition of an idea and opening an issue to discuss it

Comments

@banana-bred
Copy link
Contributor

Motivation

I'm a little confused about the default in stdlib_kinds being to disable xdp and qp by setting those values to -1 unless the user explicitly asks for computation with qp during the preprocessing stage (unless I'm misunderstanding something and this is not the case). Is this what's happening ? If so, this disables the default computation of functions like gamma and log_gamma with complex(dp) arguments because they are expected to be calculated in qp.

Not having xdp and qp enabled as default for systems that do not support them is understandable. Although selected_real_kind() already handles this in sense by returning a value of -1 for unsupported kinds, trying to compile code with real(kind=-1) :: var will just produce an error, which is also not desirable.

Could there be a small (Fortran ?) program to run and determine which kinds are > 1 and which are == -1?

For example, if selected_real_kind(33) does not return -1, then we can set qp = selected_real_kind(33) in stdlib_kinds and ensure that qp is in the REAL_KINDS array before the preprocessing.
Maybe the user can then go ahead and explicitly disable xdp and qp kinds if they really want to, even though those kinds are supported by their system. This could probably be done by just changing the default value of WITH_QP in include/common.fypp after determining whether such a kind is supported (same goes for xdp), but maybe that's not a good approach.

This way, users can continue to seamlessly integrate stdlib in their fpm projects through

[dependencies]
stdlib = "*"

and have access to relatively common functions like the complex-valued gamma() that accept and return values in their supported precision.

Prior Art

No response

Additional Information

No response

@banana-bred banana-bred added the idea Proposition of an idea and opening an issue to discuss it label May 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
idea Proposition of an idea and opening an issue to discuss it
Projects
None yet
Development

No branches or pull requests

1 participant