Re: Is it time to legitimise REAL*8 etc?
- From: David Flower <DavJFlower@xxxxxxx>
- Date: Wed, 2 Jul 2008 06:58:33 -0700 (PDT)
On Jul 2, 12:33�pm, Brian Salter-Duke <b_d...@xxxxxxxxxxxxxxxxxxx>
wrote:
On Wed, 2 Jul 2008 02:23:08 -0700 (PDT), David Flower <DavJFlo...@xxxxxxx> wrote:
On Jun 27, 4:30?pm, Clive Page <j...@xxxxxxxxxxxx> wrote:
I whether anyone else would agree that it ?may be time to legitimise the
usage of data declarations of the form REAL*8, INTEGER*2 etc
I'm fully aware of the importance of making programs portable, as I have
written Fortran in the past on machines with word-lengths of 12-bits and
72-bits, and an awful lot of word lengths in between. ?Thus I can see
why the Fortran 90 Standard introduced the kind selection functions,
given the wide range of processors in the 1980s.
But the current situation is a bit different.
(1) There's a huge amount of Fortran still in active use which uses
REAL*8 etc, and in such programs this is the major (sometimes the only)
feature which makes the code non-Standard. ?I have sometimes pointed out
to programmers who still use this notation that they really ought to use
something more compatible with the Standard, but I don't think I have
got many converts. ?Unfortunately the simplest change: altering
? REAL*8 variable
to
? DOUBLE PRECISION variable
don't actually help much: it makes the code Standard-compliant, but the
two forms don't necessarily mean the same thing. ?Few programmers that I
know seem to be convinced that they ought to write something like
? REAL(KIND=SELECTED_REAL_KIND(15,99)) variable
because that is so cumbersome and hard to read. ?(Of course you can
simplify a bit by using a named constant for the kind, but that adds
extra statements, so programmers are still reluctant).
(2) Processors which are not byte-oriented seem to be extinct, and
IEEE-754 floating-point processing on 32-bit and 64-bit processors now
reigns supreme. ?I think it can be argued that on a byte-oriented
machine REAL*8 is a more concise and more accurate specification of
one's need for an IEEE-754 64-bit floating-point variable, than the
notation using SELECTED_REAL_KIND, where the arguments are often chosen
somewhat arbitrarily. ?The reader of code has to think "hmm, the first
argument is more than seven, so the programmer probably wants IEEE
double precision here". ?The notation really isn't very readable.
(3) All current compilers seem to accept REAL*8 and similar without
problems for obvious reasons of compatibility with existing code, though
a few emit warnings if you set the right switches. ?So there's obviously
no difficulty in writing compilers which can accept the notation
alongside the kind-oriented functions.
I don't know if it's too late to send in a comment suggesting an
appropriate amendment to the Fortran 2008 specification?
What do people think?
--
Clive Page
I think that there is a case here for a compromise.
How about:
A standard conforming compiler may either:
1) interpret REAL*8 as a declaration of a floating point variable
occupying 8 bytes.
or
2) Reject the statement as illegal.
Under no circumstances should any other meaning be allowed.
The purpose of this is to ensure that legacy code is never
misinterpreted.
David Flower
I have been wondering about commenting on this thread and this seems an
appropriate opportunity. I think the above makes a lot of sense,
although I would add the need to have a flag that overrides the
rejection if the user, having looked at the situation believes that
real*8 should still be used. I base this on the main point I want to
make.
That point is that there is a great deal of what people call legacy code
around. I'm a quantum chemist and the author of a valence bond progran
that we are still developing in F77. We are testing it on as many
machines as we can. It also interfaces to two massively used quantum
chemistry programs, Gaussian (last version Gaussian03, but Gaussian08
due out soon) and Gamess(US). Both of these are still F77 and run on
almost any machine you can think of. They are by no means old code.
Gamess(US) is free, but Gaussian cost something like US$2000. It is
important that READ*8 continues to work with current compilers. although
I think both of these programs use "DOUBLE PRECISION".
I woulkd not be surprised if the largest amount of cpu time used by
Fortran progranms is not by programs that are entirely in F77. It is not
just a question of people needing to get old code working for a small test.
Brian.
--
� � � Brian Salter-Duke � � � � �Melbourne, Australia
� � My real address is b_duke(AT)bigpond(DOT)net(DOT)au
� � � � � � � �Use this for reply or followup- Hide quoted text -
- Show quoted text -
I think that, in practice, most compilers accept REAL*8, and none have
an idiosyncratic interpretation. (Other posters please comment!). If
this is so, to add to the standard the restriction I suggested would
present no problems.
There are other areas (eg Names of intrinsics) where similar
restrictions would be appropriate.
Dave Flower
.
- References:
- Re: Is it time to legitimise REAL*8 etc?
- From: David Flower
- Re: Is it time to legitimise REAL*8 etc?
- From: Brian Salter-Duke
- Re: Is it time to legitimise REAL*8 etc?
- Prev by Date: Re: Block data in library
- Next by Date: Re: error during write
- Previous by thread: Re: Is it time to legitimise REAL*8 etc?
- Next by thread: Re: Is it time to legitimise REAL*8 etc?
- Index(es):
Relevant Pages
|
|
