I think the mold approach is a good one, until Constant Expression Value Arguments for Generic Resolution · Issue #320 · j3-fortran/fortran_proposals · GitHub is implemented. Then we can change it, although we should figure out how to design it so that we change it in a backwards compatible way.
I have updated the PR with this proposal, so the user interface now looks like this:
i = to_num( s , mold=i ) !> int32
r = to_num( s , mold=r ) !> real32
d = to_num( s , mold=d ) !> real64
or if you use a pointer on a string
i = to_num_p( ptr_s , mold=i ) !> int32
r = to_num_p( ptr_s , mold=r ) !> real32
d = to_num_p( ptr_s , mold=d ) !> real64
Thanks to a test suite provided by Peter Klausler on the discussions, we saw that the current approach can guarantee for real32 only a precision up-to 10*epsilon(0.0) … this is because of the multiplications with the base 10 exponents which can be inexact.
If that becomes a reality, the interface could evolve by making mold optional for a transitional period, then remove it completely.
4 Likes
Good point.
But I want to add, that x=to_num(s) would simply become x=s. Additionally, it would be possible to offer overloaded operators for + - * / ** to allow <real> <operator> <string>. The problem which remains is <string> <operator> <string>. But in this case I would argue, that 1.0 * <int> / <int> is commonly used, so why not using it here, too?
1 Like