|
|
 Up |
|
|
  |
Author: Clive PageClive Page Date: Jun 27, 2008 08:30
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...
|
| Show full article (2.52Kb) |
|
| | 160 Comments |
|
|
Author: Herman D. KnobleHerman D. Knoble Date: Jun 27, 2008 09:18
On Fri, 27 Jun 2008 16:30:40 +0100, Clive Page 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...
|
| Show full article (2.72Kb) |
|
| | no comments |
|
|
Author: glen herrmannsfeldtglen herrmannsfeldt Date: Jun 27, 2008 10:27
Clive Page wrote:
(snip)
> (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
I suppose I agree, REAL*8 as a synonym for DOUBLE PRECISION
would be nice. In my early Fortran days I did it because it
was so much easier to type without mistakes. (That is, card
punch days, where correcting mistakes isn't just backspace.)
There are compilers now that accept REAL*8 but not REAL*4.
-- glen
|
| |
| no comments |
|
|
Author: Paul van DelstPaul van Delst Date: Jun 27, 2008 09:41
Clive Page 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 ...
|
| Show full article (4.19Kb) |
| no comments |
|
|
Author: nospamnospam Date: Jun 27, 2008 10:28
Clive Page 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
Nah. I don't like it for multiple reasons. I just don't think it is a
well-designed feature. It lacks flexibility and utility in many ways. I
also recall finding them awfully cryptic as a new programer.
Now I agree that the selected_real_kind thing is, as you say, cumbersome
and hard to read. But I think there are much better and simpler
solutions to that. F2008 adopted my suggestion to have the standard
define several named constants for the purpose in a standard module.
Those named constants cover the most common cases.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
|
| |
| no comments |
|
|
Author: dpbdpb Date: Jun 27, 2008 10:39
Clive Page 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 don't think that's the right solution to the SELECTED_REAL_KIND()
cumbersomeness, though, either; so I'd also vote "no".
I'll note I'm as guilty as any in using REAL*N as any when writing for
Windows platform code that has a obvious limited usage outside the
environment (essentially any and everything I tend to do).
OTOH, if I were writing code in an environment w/ a variety of platforms
or that was likely to be useful in a more general context (some
computational library or similar, say), I'd be far more concerned about
the portability issues and pay far more attention to write for that
environment.
--
|
| |
| no comments |
|
|
Author: Paul van DelstPaul van Delst Date: Jun 27, 2008 10:52
dpb wrote:
> Clive Page 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 don't think that's the right solution to the SELECTED_REAL_KIND()
> cumbersomeness, though, either; so I'd also vote "no".
Hello,
Could someone explain to me the cumbersomeness of SELECTED_REAL(INT)_KIND() ??
I agree the syntax is a bit wordy, but doesn't one define these things (i.e. different
kind types) once in a module and then use that module where I need anything other than
default REALs/INTs? And then forget about it?
Are people saying that they actually use the intrinsic SELECTED_REAL(INT)_KIND() directly
in every program/module they write when they need non-default reals or ints?
cheers,
paulv
|
| Show full article (1.33Kb) |
| no comments |
|
|
Author: glen herrmannsfeldtglen herrmannsfeldt Date: Jun 27, 2008 12:07
Richard Maine wrote:
> Clive Page 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
> Nah. I don't like it for multiple reasons. I just don't think it is a
> well-designed feature. It lacks flexibility and utility in many ways. I
> also recall finding them awfully cryptic as a new programer.
In the beginning he asks about REAL*8 and INTEGER*2, but
later it seems he just asks for REAL*8.
Assuming one has thousands or millions of lines of
old code with REAL*8, how hard is it to convert to
DOUBLE PRECISION? You also have to get functions right
(REAL FUNCTION F*8(X)), and get it right even when
blanks are not significant. (REALFUNCTIONF*8(X))
I thought he was only asking about old code, but even
for new code REAL*8 is much shorter to write than
DOUBLE PRECISION, not to mention how long it takes
using KINDs.
-- glen
|
| |
| no comments |
|
|
Author: Clive PageClive Page Date: Jun 27, 2008 11:11
In message <1ij6v99.1dtmkub1j3lfsmN%%nospam@see.signature>, Richard Maine
writes
>Now I agree that the selected_real_kind thing is, as you say, cumbersome
>and hard to read. But I think there are much better and simpler
>solutions to that. F2008 adopted my suggestion to have the standard
>define several named constants for the purpose in a standard module.
>Those named constants cover the most common cases.
Actually it was reading section 13.8.2.10 to 13.8.2.18 of the draft of
F2008, which defines constants like int32 and real64, which got me
thinking. So instead of
REAL*8 :: my_double
one will be able to use:
REAL(real64) :: my_double
That is a major simplification, I agree, and I would like to thank you
for having proposed these constants.
But once we admit that 64 bits is a valid size for a REAL, it doesn't
seem a very bit step to admit that 8 bytes is almost as good a way of
specifying the size. Then if we just allow the short-form notation like
REAL*8 we would standardize a whole lot of old code.
|
| Show full article (1.43Kb) |
| no comments |
|
|
|
|
|
Author: nospamnospam Date: Jun 27, 2008 11:18
Paul van Delst noaa.gov> wrote:
> Could someone explain to me the cumbersomeness of
SELECTED_REAL(INT)_KIND() ??
>
> I agree the syntax is a bit wordy,
Yes, that's one thing - one that I think is more important than you make
it out to be. Another is that it just doesn't match the way most people
want/need to specify things. Decimal digits of precision might seem fine
in theory, but that just isn't a good match the reality of programming.
When what you want to do is select between the 32-, 84- and 128-bit
options for real, it is cumbersome to translate that into numbers of
decimal digits.
Quick now, would 15 decimal digits be the 64-bit or 128-bit option?
Maybe you happen to know, but if so, that's an obscure piece of
knowledge... and one that is in danger of being wrong on machines that
use slightly different representations. And when you see two different
programs, where one asks for 12 decimal digits and the other asks for
13, what's the difference? Maybe they seem the same to you, but I've had
people ask.
|
| Show full article (2.17Kb) |
| no comments |
|
|
|
|
