- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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?

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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 ?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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
```

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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.

- Tags:
- yes

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

```
@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 **For**mula **Tran**slation 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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page