Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28446 Discussions

Does "Extend Precison of Single-Precision Constants" apply to quad precision as well?

ferrad1
New Contributor I
761 Views

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?

0 Kudos
8 Replies
ferrad1
New Contributor I
753 Views

I think not.

I ran this:

program main

real(4):: x4 = 3.141592653589793238462643383279502884
real(8):: x8 = 3.141592653589793238462643383279502884
real(16):: x16a = 3.141592653589793238462643383279502884
real(16):: x16b = 3.141592653589793238462643383279502884q0
write(6,'(g42.34)') x4
write(6,'(g42.34)') x8
write(6,'(g42.34)') x16a
write(6,'(g42.34)') x16b
end program

compiled with:

ifort test.f90 -fpconstant

to get this output:

3.141592741012573242187500000000000
3.141592653589793115997963468544185
3.141592653589793115997963468544185
3.141592653589793238462643383279503

So the rhs constant for x16a is only extended to double not quad precision.

Is there a way to do this without appending q0 ?

0 Kudos
Steve_Lionel
Honored Contributor III
740 Views

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

 

0 Kudos
ferrad1
New Contributor I
737 Views

Yes I know I am non-standard...  but my question is more about what /fpconstant does. It seems it only extends single to double, not single or double to quad.

0 Kudos
Steve_Lionel
Honored Contributor III
716 Views

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.

0 Kudos
ferrad1
New Contributor I
694 Views

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.

0 Kudos
FortranFan
Honored Contributor II
686 Views

 

@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.

 

 

@ferrad1 ,

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.
0 Kudos
ferrad1
New Contributor I
682 Views
0 Kudos
Steve_Lionel
Honored Contributor III
666 Views

If there are specific constants you use a lot, define them as PARAMETERs.

0 Kudos
Reply