forums.silverfrost.com

zeevBP · Joined: 27 Aug 2014 Posts: 3

I'm trying to compile an open source FORTRAN 90 program which uses REAL*16 precision.

FTN95 appears to recognize this (KIND=4) since:

for the command line real*16 arg1,c,darg,x1 there is no error/warning.

for maxint=lnum+3*ndec+iqint(c)+5 there is no warning.

and for a later IQINT(1.23E7) i get the message
warning 189 - In a previous call to IQINT, the first argument was of type REAL(KIND=4), it is now REAL(KIND=1).

BUT, the "q" format for KIND 4 constants is not recognized:

for api=pi/180.q0 i get the message
error 773 - Variable Q follows another operand (possible unexpected space?)

and if i try to change the constant to 180.0_4 i get the message
error 636 - KIND parameter out of range, permitted KINDs are 1, 2, or 3.

So, my questions are:

1) Is there any way to make the FTN95 support REAL KIND=4?

2) If not, can you recommend a FORTRAN 90 compiler (i am ready to pay for it) that does support REAL KIND=4. (For usage on a Windows 7 system).

Addition: I installed the gFortran and it recognizes REAL KIND=4 constants. However, when building the project i get a link error message

"undefined reference to `qcos'". (as well as to many other intrinsic functions such as qlog10 etc.).

so now my question is:

3) How to include the intrinsic "q"uadruple precision functions in the build of the gFortran program (in Plato).

Thank you.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

FTN95 does not support REAL*16.
However it does provide support for REAL*10, which is an extended precision.
While FTN95 might allow the syntax of REAL*16 (or possibly KIND=4) without an error message, as far as I know there is no support for this higher precision.

You might like to try the following program that shows what precision is supported.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

I have looked further and it appears that FTN95 does offer some compatibility support for REAL*16, but not the precision. I modified the second program above and ran it with FTN95 and gFortran 4.9.1

PaulLaidler · Posted: Fri Aug 29, 2014 7:29 am Post subject:

John's summary appears to be correct.
It looks like FTN95 should not accept real*16 and maybe it is being confused with complex*16 which is OK.

I will log this for investigation.

As far as I know, FTN95 is one of the few compilers that accept real*10.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

The real*16 does appear to act like a real*10, but with 16 bytes of memory. This is not what I would expect of complex.

I think there is a significant performance penalty with Real*10. I would guess it is emulated as I don't think the 8087(?) maths coprocessor capability is available on recent processors.

One of the advantages of the apparent support of real*16 is that it allows programs with real*16 to run with the expected exponent range, although the precision is not what is expected.

John

zeevBP · Joined: 27 Aug 2014 Posts: 3

John and Paul, thank you very much for your detailed and quick response.
you are fantastic.

John, from your demo gFortran program it looks like the atan function is equivalent to the qtan function. Is this correct? does it support the REAL*16 precision?

Also, can you help me with my third question - how can i tell the Plato linker to access the "libqmath..." libraries when linking a gFortran compiled program (in case the "axxx" functions do not give the required precision?

Thanks again.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

zeevBP,

I have not checked the values returned by gF real*16, but I would expect they achieve the correct precision.

I have not yet attempted to compile or link gFortran from in Plato. I'd like to know myself. I use batch files to define the appropriate path for gFortran.exe then other batch files for compile and load. With 4.9.1 I think that the library paths are defined internally relative to the bin\.. path.

John

ps: Here are comparisons of FTN95 (Ver 7.1) , gFortran (Ver 4.9.1) and LaheyFortran (Ver 5.55j). All appear to give reasonable precision for the KIND claimed. FTN95 provides fewer significant figures when writing with write (*,*) although the F30.25 indicates more precision might be available.

zeevBP · Joined: 27 Aug 2014 Posts: 3

John, thank you for your support.

We (my son) found out in the documentation of gFortran that although it accepts the quadruple precision functions (such as qcos) as a valid part of the program syntax, there is currently no implementation of these functions -
and that is why i get the error messages in the link phase.

Since i think i really need the REAL*16 precision, i am now looking at some commercial compilers which claim support for these function (specifically a Fortran compiler running under Intel Parallel Studio XE 2015).

Thanks again - if it turns out that REAL*10 support is good enough - i am sure i will come back to FTN95!

PaulLaidler · Posted: Sat Aug 30, 2014 12:50 pm Post subject:

FTN95 REAL*10 gives 18 significant figures and exponents up to + or - 4932.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

zeevBP,

I am not sure what your son was reading, but why do you need QCOS. Simply use the generic COS and provide a real*16 argument. The attached program uses ATAN and ACOS and provides the precision required.

I am also unsure of your need for 128 bit reals. I have always struggled to identify then confirm this precision. You are basically saying you can provide data inputs to the calculation to better than 18 significant figures, which is a big ask.
I would be looking at the numerical algorithm to see if there is a better way that doesn't loose so much precision and can work with real*8, or *10 for larger exponents.

John

PaulLaidler · Posted: Wed Jan 14, 2015 2:48 pm Post subject:

I have looked into this and FTN95 deliberately accepts REAL*16 (at least in many contexts) but goes on to treat it as REAL*10.

I am not sure if we need to do anything about this.
We could report a comment when compiling.

IanLambley · Joined: 17 Dec 2006 Posts: 490 Location: Sunderland

REAL*16 and COMPLEX*32 were perfectly acceptable in Digital VAX Fortran-77 but there were two versions of this that were switched on by compiler switches. These were:
"HUGE" which gave an huge range, i.e. the exponent and
"GRAND" wich restricted the exponent but increased the precision.

Sadly no longer easily available but I do have a Microvax 3200 hiding in a cupboard at home. I could look up the Fortran manual to provide the exact details.

As to whether it is needed, I remember one program that failed on REAL*8 and this was a transfer matrix analysis of the whirling and lateral vibration of shafts. A series of matrices were multiplied together as you progress along a shaft from one end to the other multiplying "point" matrices which contain lumped mass and inertia terms multiplied by a frequency in radians per sec squared and a "shaft" matrtix which added in the effect of the bending stiffness of the shaft and its own distributed mass and inertia. After doing this for the entire length of the shaft, the determination of whether the guessed frequency was in fact a natural frequency was by calculating the determinant which was a series of large figures multiplied together minus a second series of large numbers multiplied together. If this is zero the it is the natural frequency. This failed on REAL*8 and suceeded on REAL*16 due to precision. I have sucessfully operated this program on REAL*10 in FTN95. However, I think that there other ways to extract the eigenvalues of a system rather than transfer matrices which are only an step up from a Holzer frequency table.

Ian

LitusSaxonicum · Posted: Thu Jan 15, 2015 2:21 pm Post subject:

In the early days of finite elements, Brits were able to solve problems with ill-conditioned matrices and other numerically poor algorithms that our US cousins could not, because most British computers used two 24-bit words for REALs (e.g. Elliot 4120, ICL 1900) making in effect REAL*6, whereas standard precision at the time in many US computers was 32 bit (REAL*4). Whether or not this promoted the drive for double and quad precision is a moot point, but precise numbers of bytes instead of words certainly came later. The CDC 6000 and 7000 computers used 60-bit words.

The original design of the 8088/8086 chip with an 8087 numeric coprocessor implemented REAL*10 in the latter as a means to control roundoff in REAL*8 calculations as I understand it, rather than to implement a system using REAL*10 throughout.

As Ian points out, algorithms that demand extraordinary precision may not be the best ones to use. Indeed, extraordinary precision is not required for every variable - I doubt if the diameter and length of the shaft needed specifying in REAL*8 millimetres, let alone anything higher.

IanLambley · Joined: 17 Dec 2006 Posts: 490 Location: Sunderland

OK,
Now I'm home I've looked up the VAX REAL*16 and found that COMPLEX*32 did not exist.
The REAL*16 variables permitted the magnitude of values in the range of 0.84Q-4932 to 0.59Q+4932 where the Q replaces the E or D for REAL*4 and REAL*8 respectively.
It states that 33 decimal digit precision is provided.
The variation in precision of REAL*8 is actually referred to as "D_floating" and "G_floating". It states that the G_floating implementation offers a greater range but is less precise, having a smaller number of significant digits. D_floating is the default implementation of REAL*8 and COMPLEX*16, the "/G_floating" compilation switch was used to choose the optional lower precision.

The summary of the VAX Floating point number implementations is