You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
Motivation
I'm a little confused about the default in
stdlib_kinds
being to disablexdp
andqp
by setting those values to-1
unless the user explicitly asks for computation withqp
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 likegamma
andlog_gamma
withcomplex(dp)
arguments because they are expected to be calculated inqp
.Not having
xdp
andqp
enabled as default for systems that do not support them is understandable. Althoughselected_real_kind()
already handles this in sense by returning a value of-1
for unsupported kinds, trying to compile code withreal(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 setqp = selected_real_kind(33)
instdlib_kinds
and ensure thatqp
is in theREAL_KINDS
array before the preprocessing.Maybe the user can then go ahead and explicitly disable
xdp
andqp
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 ofWITH_QP
ininclude/common.fypp
after determining whether such a kind is supported (same goes forxdp
), but maybe that's not a good approach.This way, users can continue to seamlessly integrate stdlib in their fpm projects through
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
The text was updated successfully, but these errors were encountered: