Precision API strategy: `wp`-only getters vs `sp`/`dp`/`qp` convenience interfaces

[lukaswittmann]

Context

fclap currently treats real(wp) as the float precision.

Problem

This improves consistency, but it also means users cannot do:

real :: x
call args%get("factor", x)

when x is not real(wp) (e.g. wp=dp, x=sp) this will fail at compile time ( as its not matching any specific binding).

Discussion

Should fclap remain strict wp-only for generic get, or provide explicit convenience APIs for other kinds (sp, dp, qp) without reintroducing generic ambiguity?

Options

• Keeping get strictly at real(wp) will require explicit conversion by users and setting wp in fclap; this is IMO not desirable.
• Add separately named conversion helpers (e.g. get_real_sp, get_real_dp, optional get_real_qp) while keeping generic get as wp-only; that would be a middle ground, but also IMO not very nice.
• Provide full multi-kind generic overloads (sp, dp, qp) across the API. This would allow every CLI argument to have its specific precision up to the wish of any user. Of course, at the cost of having to add interfaces for every real entry point in src/fclap/fclap_namespace.f90 which would make the API much larger, and test and maintenance more painful.

[chselz]

I agree with this issue. keeping reals throughout the entire code base the same precision is probably not desirable as a user might want to do his work entirely in single precision and thus resources will be wasted in the beginning. Or a large qp necessitating number is entered in the cli call (unlikely but possible) this could not be handled when wp = dp which would require the user to change the fclap code, which is bad and not intended.

I also am not a fan of the second option as the same problem would occur the user enters a qp number, internally everything is dp and this is then with the getter routine converted back to a qp but inbetween there is an unrecoverable precision loss.

Therefore i think that the third way is the way to go. so this would change the data_type argument of the add_argument() routine so that it does not accept anymore the following types int, float but rather now real_sp, real_dp, real_qp, with just real defaulting to real_dp and the same for ints. This is then propagated as the wp for this argument through each routine.

then the user must make sure that the variable provided for the get routine in the end is provided with a variable of the appropriate type and accuracy.

Do you agree with this?