In the section Fortran -> Floating Point, there is an option "Extend Precision of Single-Precision Constants" or /fpconstant. I always use this for transforming constants into double precision. Does it also work for quad precision?
ie. if I have
real(16), parameter :: test = 3.1415926535897932384626433
will test get the correct value? ie. will the right hand side be converted to quad precision?
I think not.
I ran this:
real(4):: x4 = 3.141592653589793238462643383279502884
real(8):: x8 = 3.141592653589793238462643383279502884
real(16):: x16a = 3.141592653589793238462643383279502884
real(16):: x16b = 3.141592653589793238462643383279502884q0
ifort test.f90 -fpconstant
to get this output:
So the rhs constant for x16a is only extended to double not quad precision.
Is there a way to do this without appending q0 ?
The correct and standard-conforming way to do this, rather than relying on an extension (q0) or switch, is as follows:
program main implicit none integer, parameter :: sp = selected_real_kind(6) integer, parameter :: dp = selected_real_kind(15) integer, parameter :: qp = selected_real_kind(33) real(sp):: x4 = 3.141592653589793238462643383279502884_sp real(dp):: x8 = 3.141592653589793238462643383279502884_dp real(qp):: x16 = 3.141592653589793238462643383279502884_qp write(6,'(g42.34)') x4 write(6,'(g42.34)') x8 write(6,'(g42.34)') x16 end program main
3.141592741012573242187500000000000 3.141592653589793115997963468544185 3.141592653589793238462643383279503
I know that VAX FORTRAN-77 would evaluate all real constants as quad precision, and downconvert as necessary. However, the Intel Fortrtan documentation clearly states that /fpconstant "Tells the compiler that single-precision constants assigned to double-precision variables should be evaluated in double precision." Therefore, your expectation is unwarranted.
Please do it the standard-conforming way. My position is that relying on compiler options to change the semantics of a program just leads to trouble.
Having _dp after every constant in a math-rich piece of code make it a lot less readable in my view. Hence I would rather leave them out and use /fpconstant to make them double precision. I know this might be different with other compilers, but if we choose to change, that is part of the porting process, the cost of which should be weighed up against the legibility of the code and ease of debugging.
@ferrad1 wrote: Having _dp after every constant in a math-rich piece of code make it a lot less readable in my view. Hence I would rather leave them out and use /fpconstant to make them double precision. I know this might be different with other compilers, but if we choose to change, that is part of the porting process, the cost of which should be weighed up against the legibility of the code and ease of debugging.
Note that there are quite a few senior technical leads and directors including budget managers in computing and related areas elsewhere, particularly in industry, who have similar views as what you express and this is among the many nits that contribute to declining use of and support toward Fortran.
It may be a long time - if at all ever - the standard evolves enough to bring the language closer to the original vision of Formula Translation on this aspect.
If you remain interested in Fortran, note a couple of fairly recent advances:
- First is the site for open discourse for Fortran at https://fortran-lang.discourse.group/. Notice a thread on constants - fundamental, physical, and mathematical. And the link to some code at GitLab. The approach is one suggested here, the named constants are declared in the highest precision supported by a processor. Versions of it are defined in other precisions using the standard "casting" mechanism. This is a workaround you can consider for your constants. Perhaps you want to collaborate with that Community to refine or extend the solutions envisioned there.
- In terms of language evolvement, there is a site for proposals at https://github.com/j3-fortran/fortran_proposals. There is a thread there which appears a good fit for Fortran, in my opinion. You can provide your feedback there, or offer other proposals.