forums.silverfrost.com

[John-Silver]

wouldn't it be a good idea to have a compile option in ftn95 which makes all constants double precision by default ?

[JohnCampbell]

John,

The Fortran 90 standard says that you can't.
You could provide such an option, but it would not be portable and would be a bad approach for maintaining the code.
It is all a bit ridiculous. consider the following example:

[LitusSaxonicum]

Come on guys, be sensible. The default precision for a REAL constant is the default REAL type, which is REAL*4. There's no such thing as a DOUBLE PRECISION constant without the D part.

If you want to make the default for variables AND constants REAL*8, then you use the DREAL option in an OPTION statement.

It isn't a problem, the former is part of Fortran, the latter is part of FTN95. The selection of REAL*4 to be the default real precision is the fault of computer designers: on the UK-designed systems it was REAL*6 (2 x 24-bit words) before that line of thinking was forced out of the market.

The associated problem is that REAL*4 isn't much use for anything that is calculated, and often isn't for anything that is input as data. As an example, consider ground coordinates that need to be specified in mm on a national coordinate system. REAL*4 is OK in the SW of England (a small country) but coordinates become rounded as one passes Salford, and totally inaccurate in Scotland! However, for coordinates of points on a a car, they can be specified in hundreds of a mm with REAL*4. But for my purposes, REAL*4 is usually pointless.

It strikes me that if REAL*4 and INTEGER*4 are the defaults for 32-bit computing (where addressing is via INTEGER*4 length addresses), the REAL*8 and INTEGER*8 should be the defaults for 64-bit computing, even though one then has the problem that DOUBLE PRECISION ought to be 128 bits, and the x86 cpus don't seem to have got to that.

In any case, it seems to me that the OPTIONS statement needs the possibility of an INTx to go with INTL and INTS (perhaps there is, I haven't looked).

Eddie

[JohnCampbell]

Eddie,

You may be correct. The problem is the FTN compilers would treat the following differently to F90 (and I suspect F77)

[PaulLaidler]

Yes. The quick and easy way is to use /DREAL on the FTN95 command line and this feature was ported from FTN77.

[LitusSaxonicum]

It looks to me that /DREAL is the sensible way to go, as it basically says that REAL is REAL*8, and that DOUBLE PRECISION means the same as REAL. This is fine by me, as I don''t have any use for REAL*16 - if REAL*8 isn't enough, then I would look for a different algorithm. (REAL*16 being DOUBLE PRECISION if REAL*8 is the default REAL).

The compiler can't be a mind-reader, but it does seem logical that the assumed intent of a programmer assigning a more precise than REAL*4 constant to a REAL*8 variable should imply that it is a REAL*8 constant, standard conforming or not, so it depends on whether one wants strictness - which is available with /ISO - or a bit of mind-reading.

Whether the telepathic version should be implemented, it would be consistent wit the treatment of INTEGET constants - see FTN95.CHM description of INTS - which sets integer constants to INTEGER*2 UNLESS they exceed the range for INTEGER*2. The compiler options section notes that /DEFREAL_KIND behaves unlike DEFINT_KIND.

Incidentally, with the Win32 version, there is an /XREAL as well.

While one loses x87 80-bit registers and precision to use SSE etc, this is how Intel designed it, and as most processors are used for Facebook or downloading porn, arithmetic precision is presumably not high on their list of priorities.

Eddie

[DanRRight]

Leaving aside a hack with /DREAL or OPTIONS(DOUBLE PRECISION) which has little chance to be a common practice in the future I see no reason that in the code

[mecej4]

[DanRRight]

Yes, while integers get royal treatment, the obvious real*8 number gets unimaginable: the highway robbery treatment stripping it from extra digits. I have no clue how this got into the Standard.

[JohnCampbell]

I agree with Dan,

If you coded "X=3.4567890123456", it is very "harsh" of the compiler to strip it to a real*4 constant, but that is what was defined and caused a few unnecessary problems.
There is the case of what to do with SIN ( 3.4567890123456 ) or my_function ( 3.4567890123456 ), which is more of a problem.

The example "real*8 X ; X = 0.6" was also a problem for the unwary, as these types of constants often occurred in FE coding when converting from CDC to mini. F77 devilry !!

Then they introduced object oriented programming as that was supposed to lead to fewer coding errors !!

[PaulLaidler]

A new option [fmt=<format_specifier>] has been added to %rf in order to provide program control of the displayed REAL value. The <format_specifier> is analogous to one of %wf, %we and %wg. For example %rf[fmt=0.4e] is equivalent to %0.4we. In other words, we simply omit the '%' and the 'w'. The result in this case is an exponent form with 4 decimal places and 5 significant figures. See the help file on %wf etc. for detailed information on how to write the <format_specifier>.

Here is a simple example:

[John-Silver]

Remember, remember the 5th of November, Fireworks, Treacle Toffee and DLLs
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... "

[John-Silver]

I just noticed that on 28th nov last year JohnC wrote:

[JohnCampbell]

Answer to John S:

[mecej4]

John C.: I realise that the comment on the first executable statement of your illustrative code may be based on a vague recollection, but I do not know if you actually had a Fortran-77 compiler that treated the constant as a double precision constant. If you can name that compiler, and that compiler did that without any options such as /DREAL, that would be interesting, because the Fortran 77 Standard says ( https://www.fortran.com/F77_std/rjcnf0001-sh-4.html#sh-4.2.1 ):