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

On Fri, 27 Jun 2008 16:30:40 +0100, Clive Page <junk@main.machine> 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?
Bravo! Well stated.  I agree. 
 
Skip Knoble

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

Nope. I would not like to see the usage of REAL*8 legitimised. I find the kind type system 
makes for much more flexible code. I like being able to change a *single* parameter in my 
type kinds module and *all* my generically defined reals and complex's switch between 
single<->double precision. And, despite the lack of non-byte-oriented processors, I also 
like the genericity (is that a word? generality?) of kind types that doesn't require it. 
 From my limited personal experience, I've found it *extremely* difficult and 
time-consuming to produce really general code *and* have it simple and easy to use - we 
should be applauding the crafters of the type kinds methodology. (I should probably duck 
now to avoid incoming.... :o)

Your analysis "I don't think I have got many converts" is the more telling I reckon. If 
programmers aren't willing to embrace the current standard and still use non-standard 
extensions (even if they are common) then either a) they should quit complaining when 
things go awry, or b) their management should provide training and/or a prodding to pull 
their finger out of their proverbial. How readable does code have to be? Do we need to 
dumb things down so that every single code construct is understandable by people with zero 
experience? Personally, I'd rather spend my time doing interesting stuff *using* these 
features.

And anyway, Fortran90 is approaching its 20th anniversary as a standard. Are current 
Fortran90/95 programmers going to have the same issue with whatever is introduced in 
future standards? Sheesh.

cheers,

paulv

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

Clive Page <junk@main.machine> 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

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.

--

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

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

In message <1ij6v99.1dtmkub1j3lfsmN%nospam@see.signature>, Richard Maine 
<nospam@see.signature> 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.

I agree with you that I don't particularly like it (which is why I have 
tried for years to discourage its use), but the fact is that every 
modern compiler seems to support it as an extension, since if they 
didn't there would be a huge outcry.  Perhaps the notation could be 
introduced and deprecated all at the same time, so as to discourage 
future use?

-- 
Clive Page

Paul van Delst <Paul.vanDelst@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.

If selected_real_kind asked about binary instead of decimal precision,
that would be an improvement. (I've proposed an option for that, and I
think a variant of that might also be in, but I haven't kept up). But I
think the best option would be that which most closely matched the way
people most naturally ask. That's not in terms of digits of precision,
be they decimal or binary digits. People most commonly ask in terms of
the size of the representation - i.e. they might ask for the 64-bit (or
8-byte) option.

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

I would hope so, but I sure wish that people would stop giving examples
of the "wrong" way to do it. I think I've even seen those examples in
textbooks. Others see those examples and then think that's actually
normal practice.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

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

Difficulty of conversion is exactly one of the things I don't like about
the *N notation. If you ever find that you need to convert it to a
different precision, its a big PITA. Been there. Done that. If you use a
named constant for the kind (whether it is a named constant of your own
definition or one defined by the standard), then conversion is much
simpler.

Even if you decide to replace all the instances of the named constant in
the source code, instead of redefining the value of the constant, that's
a lot simpler to do safely and competely than it is to replace all the
*8 things, which can be tricky to parse right. Witness the fact that
multiple compilers parse some cases of *8 incorrectly (such as
real*8Henry).

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Richard Maine wrote:
> Paul van Delst <Paul.vanDelst@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.
 > ...[rest of most excellent post elided for brevity]...

Thanks for filling in what I would undoubtedly have tried to say far 
less distinctly... :)

I was wishing I had used (or added) "obtuseness" as opposed to simply 
cumbersome as it is what I find particularly the most difficult issue, 
indeed.

On a given set of hardware, one learns what it means rather quickly and 
there are a relatively limited number of options of practical 
application.  But, then one is back to the example I gave before where 
the shorthand route is probably just as effective for the purpose.

--

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
> 
<snip>
> What do people think?
> 

I think I agree with you Clive.   I never have liked KIND - I don't want 
to specify the precision as such - some clever compiler writer might 
give me *exactly* what I ask for - implemented in software.  I want a 
clear way to pick a amongst the types that are implemented in hardware, 
and the question I find myself asking is "how do I set the KIND 
parameters to be absolutely sure that I will get REAL*8 or INTEGER*1 or 
whatever?".  Where's the sense in that?

Despite that, I do use KIND, because, as Paul says, it allows me change 
the types in a program using a single parameter.  I generally define 
them in terms of constants with known type - R8=KIND(1D0) etc.

I think we should remember that most Fortran users have another life - 
if the language gets too obtuse, we'll lose them.
-- 
John Appleyard  - (send email to john!news@.. rather than spamtrap@..)
Polyhedron Software
Programs for Programmers - QA, Compilers, Graphics, Consultancy
********* Visit our Web site on http://www.polyhedron.co.uk/ *********

Richard Maine wrote:

> Clive Page <junk@main.machine> 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

dpb wrote:
....
> 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.

Like most here getting long in the tooth, I've been the route of 36, 
then 60, then 32/64 w/ varying fp models and migrated code from all of 
them.  But, I haven't done that kind of stuff w/ those kinds of codes 
for <a_long_time> now... :)

--

In article <1ij6y5g.18i2cujrtp1a8N%nospam@see.signature>,
Richard Maine <nospam@see.signature> wrote:

>Difficulty of conversion is exactly one of the things I don't like about
>the *N notation.

There's not much point in reciting all the things that people don't
like about the *N notation. It's all been said before. The argument
being advanced is not that *N is good, it's that it's de facto popular.

BTW, most compilers provide enough precision switches that I've only
had to convert a small amount of code.

-- greg

In article <4865341d$0$78078$bed64819@news.gradwell.net>,
John Appleyard  <spamtrap@polyhedron.com> wrote:

>I think I agree with you Clive.   I never have liked KIND - I don't want 
>to specify the precision as such - some clever compiler writer might 
>give me *exactly* what I ask for - implemented in software.  I want a 
>clear way to pick a amongst the types that are implemented in hardware, 
>and the question I find myself asking is "how do I set the KIND 
>parameters to be absolutely sure that I will get REAL*8 or INTEGER*1 or 
>whatever?".  Where's the sense in that?

And this was a known flaw -- PL/1 suffered from it.

-- greg

Hello,

On 2008-06-27 14:42:09 -0400, John Appleyard <spamtrap@polyhedron.com> said:
> 
> I think I agree with you Clive.   I never have liked KIND - I don't 
> want to specify the precision as such - some clever compiler writer 
> might give me *exactly* what I ask for - implemented in software.  I 
> want a clear way to pick a amongst the types that are implemented in 
> hardware, and the question I find myself asking is "how do I set the 
> KIND parameters to be absolutely sure that I will get REAL*8 or 
> INTEGER*1 or whatever?".

So how will *N notation select among different radixes,
even limiting the choice to what's available in hardware?

The new 754r has decimal and binary radix.  Who knows,
it may even be popular someday.

-- 
Cheers!

Dan Nagle

Richard Maine wrote:
> Paul van Delst <Paul.vanDelst@noaa.gov> wrote:

>>Could someone explain to me the cumbersomeness of

> SELECTED_REAL(INT)_KIND() ??

>>I agree the syntax is a bit wordy,

Not so wordy as

       INTEGER (SELECTED_INT_KIND(9)) :: I

compare to C's

       int i;

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

PL/I only has specifiers in terms of either binary or decimal
digits.  In most case, people specify the values for their
favorite system.  PL/I uses 3.32 as the conversion between
the two.  (Except that IBM compilers, given a request for
FLOAT DECIMAL(16), which comes out 53.12 bits, uses 53
instead of rounding up to 54.)

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

I agree, though if the values are significant digits then the
numbers you actual want are 24 and 53 in many cases.  Still,
I would like to see SELECTED_REAL_BIN_KIND() and SELECTED_BIN_INT_KIND()
(except that they are even longer).

So you would like ones that specify the total length, not just
the significant digits (in some base)?

Another PL/I feature is that some long names have shorter equivalents.
PROC for PROCEDURE,  BIN for BINARY, CHAR for CHARACTER.

I would vote for BINARY_REAL_KIND() and BINARY_INT_KIND().

> If selected_real_kind asked about binary instead of decimal precision,
> that would be an improvement. (I've proposed an option for that, and I
> think a variant of that might also be in, but I haven't kept up). But I
> think the best option would be that which most closely matched the way
> people most naturally ask. That's not in terms of digits of precision,
> be they decimal or binary digits. People most commonly ask in terms of
> the size of the representation - i.e. they might ask for the 64-bit (or
> 8-byte) option.

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

> I would hope so, but I sure wish that people would stop giving examples
> of the "wrong" way to do it. I think I've even seen those examples in
> textbooks. Others see those examples and then think that's actually
> normal practice.

When writing a quick, run once, example for the newsgroup,
one tends to use what is faster to write.  No excuse for
textbooks, though.

-- glen

Hello,

On 2008-06-27 16:48:40 -0400, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

> Dan Nagle wrote:
> (snip)
> 
>> So how will *N notation select among different radixes,
>> even limiting the choice to what's available in hardware?
> 
> It won't, but neither does "DOUBLE PRECISION".

But real( kind= dp10) can.
> 
> I read his post mostly as a request for "REAL*8" as
> a synonym for "DOUBLE PRECISION", (not counting the
> first sentence).

On 64-bit hardware?  or on 32-bit hardware only?
Really, this is the problem.
> 
> Also, not to remove the KIND mechanism but only legitimize
> the practice used in much old code and some quickly written
> new code.  (For a simple test, the declaration might be
> more than half the program!)

So you want to build into the language
a hardware dependency for the sake of the simplest of programs?
That strikes me as a big step backwards
for the very least gain.

-- 
Cheers!

Dan Nagle

Richard Maine wrote:
> Clive Page <junk@main.machine> 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.

In addition, a one-time run through a preprocessor can convert
star declarations to the new form.  I've never really been much
impressed with the appeal to legacy code as a reason to keep
bad old syntax.  It's not like such a preprocessor is hard to write
or does anything sophisticated.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

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


Which 8 byte REAL is to be the one supported?  The binary or
the new decimal.  Whichever is your answer, how would a user
select the other one?  If and when we ever get unsigned integer
KINDs, or bit-wise KINDs, what does the *2 mean?

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

Richard Maine wrote:
> Paul van Delst <Paul.vanDelst@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.

O.k., I understand what people take issue with. The interface to people's perceptions is 
ass-about, but you grapple with the strangeness up front and only once, right? I think the 
first piece of f90 code I wrote (back in '95) was my Type_Kinds.f90 module that contained 
definitions for these things (True, I have a test program that output my type kinds 
results). I've hardly thought about it since then... I just use it. If I want single 
precision (==real*4) I do
   REAL(Single) :: x
or
   REAL(sp) :: x
and if I want double (==real*8) I do
   REAL(Double) :: x
or
   REAL(dp) :: x

(similarly for ints)

It has worked on all platforms I've had access to so far: Sun Solaris, SGI-IRIX, IBM-AIX, 
HP-UX, PC(linux using pgi, intel, lahey, gfortran, g95), and Macs (intel,gfortran,g95). I 
definitely do not attribute that portability to my skill as a programmer but to the 
construct itself.

I mean, if you want to measure the length of various things, you don't construct a brand 
new measuring stick every time - you get a good one up front and reuse it until you wear 
it out.

cheers,

paulv

Dan Nagle wrote:
(snip)

> So how will *N notation select among different radixes,
> even limiting the choice to what's available in hardware?

It won't, but neither does "DOUBLE PRECISION".

I read his post mostly as a request for "REAL*8" as
a synonym for "DOUBLE PRECISION", (not counting the
first sentence).

Also, not to remove the KIND mechanism but only legitimize
the practice used in much old code and some quickly written
new code.  (For a simple test, the declaration might be
more than half the program!)

-- glen

In message <5ZudnSe45MNp3vjVnZ2dnUVZ_o7inZ2d@comcast.com>, glen 
herrmannsfeldt <gah@ugcs.caltech.edu> writes
>I read his post mostly as a request for "REAL*8" as
>a synonym for "DOUBLE PRECISION", (not counting the
>first sentence).

Just to clarify something: I don't think that DOUBLE PRECISION 
necessarily means REAL*8.  Suppose your native word-length is 64-bits, 
so that REAL means 8-bytes, won't DOUBLE PRECISION mean 16-bytes?  I 
think I've used a CDC machine in the past for which that was true.   If 
that's true, then the form "DOUBLE PRECISION" is too imprecise, it means 
just "at least twice as much precision as real", and it is obsolescent 
in the latest Standards for a good reason.

On the other hand REAL*8 means exactly the same as REAL(real64) in the 
proposed Fortran2008 notation.  So you can do global edit to convert old 
code to be consistent with Fortran2008.  Maybe that's good enough, but 
it still means there's a lot of old code out there which is currently 
non-standard for rather trivial reasons.

I was also proposing that the whole set of word-lengths be supported, 
i.e. INTEGER*1, INTEGER*2, INTEGER*4, INTEGER*8,
REAL*4, REAL*8, and LOGICAL*1, LOGICAL*2, LOGICAL*4, as these are all 
encountered in the wild.  I didn't mention all these because my original 
posting was already rather long.

-- 
Clive Page

In message <z%b9k.152304$SV4.91711@bgtnsc04-news.ops.worldnet.att.net>, 
James Giles <jamesgiles@worldnet.att.net> writes
>Which 8 byte REAL is to be the one supported?  The binary or
>the new decimal.  Whichever is your answer, how would a user
>select the other one?  If and when we ever get unsigned integer
>KINDs, or bit-wise KINDs, what does the *2 mean?

My proposal would be to make INTEGER*2 simply a synonym for 
INTEGER(int16) in the current Fortran2008 proposed syntax.  If we get 
unsigned integer kinds or bit-wise kinds, the same problems will beset 
both.


-- 
Clive Page

Clive Page wrote:
> In message
> <z%b9k.152304$SV4.91711@bgtnsc04-news.ops.worldnet.att.net>, James
> Giles <jamesgiles@worldnet.att.net> writes
>> Which 8 byte REAL is to be the one supported?  The binary or
>> the new decimal.  Whichever is your answer, how would a user
>> select the other one?  If and when we ever get unsigned integer
>> KINDs, or bit-wise KINDs, what does the *2 mean?
>
> My proposal would be to make INTEGER*2 simply a synonym for
> INTEGER(int16) in the current Fortran2008 proposed syntax.  If we get
> unsigned integer kinds or bit-wise kinds, the same problems will beset
> both.

So, in other words a simple preprocessor would handle those
old INTEGER starred declarations too.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

Paul van Delst <Paul.vanDelst@noaa.gov> wrote:

> Richard Maine wrote:
> > Paul van Delst <Paul.vanDelst@noaa.gov> wrote:
> > 
> >> Could someone explain to me the cumbersomeness of
> > SELECTED_REAL(INT)_KIND() ??

> O.k., I understand what people take issue with. The interface to people's
> perceptions is ass-about, but you grapple with the strangeness up front
> and only once, right?

As is taught in other contexts, first impressions matter. Selecting a
real kind one of the first things you need to do in writing code. If it
is obtuse and complicated, people new to it will either get turned off
to the whole language or choose a way that is simpler, even if worse in
the long run (such as hard-wiring kind numbers).

Or, to use another saying, simple things should be simple. Declaring a
real variable shouldn't require learning about this intrinsic function,
named constants, initialization expressions (in particular, the kinds of
functions that can be used in the declaration of a named constant) and
modules - all just to write your first program that does the most
trivial thing with floating point.

I bet it wasn't the first program you ever wrote where you did your
type_kinds.f90 module. Might have been your first f90 program, but you
had to have been already moderately sophisticated to start that way.
Otherwise... well let me just say that you must not be very typical.

No, when people do their first program, they will use some other
shortcut instead. And then they will get used to that shortcut and
continue using it. Anyway, an awful lot of people will do that. Evidence
from actual people and actual codes confirms this; that's wherefrom we
get a lot of the real*8 stuff still appearing in new codes.

So provide a shortcut that doesn't require such sophistication. But make
the shortcut indeed be a subset of the more general facility so that the
user and/or program can later grow into the full thing if the need
arises. Increasing sophistication should be a matter of extending the
simple case instead of forgetting the simple case and going things
completely differently. Jumping from real*8 to the kind facility is
doing something completely diferently. Going from a system-provided
named constant to one that you define using such things as the
selected_* intrinsics is extending a simple case.

We just don't (yet) have the simple case in place. But it is pretty
evident how to make a simple case that is an actual subset of the
current kind facility; see prior discussion.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

glen herrmannsfeldt wrote:
> James Giles wrote:
> (snip, someone wrote)
>
>>> My proposal would be to make INTEGER*2 simply a synonym for
>>> INTEGER(int16) in the current Fortran2008 proposed syntax.  If we
>>> get unsigned integer kinds or bit-wise kinds, the same problems
>>> will beset both.
>
>> So, in other words a simple preprocessor would handle those
>> old INTEGER starred declarations too.
>
> A preprocessor to properly parse both fixed and free form
> source isn't so simple.  Other than that, yes.

We've been through this before.  And yes, it is pretty simple.
In this case, we don't even need to parse the whole language,
just those statements that begin with a small set of keywords.
We then need to verify that they really are keywords (which
in this case isn't hard at all).  After that, it's just plain substitution.
The only remaining difficulty is making sure the substitution
doesn't extend the line past the limit (72 or 132, whichever
applies).

Or does the ACM not publish in your area?  Look up Sale's
algorithm.  Trimming it down to just handle declarations makes
it even easier.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Clive Page wrote:

> > Just to clarify something: I don't think that DOUBLE PRECISION 
> > necessarily means REAL*8.
....
> True, but in programs meant to be (somewhat) portable it usually did.

I'd say you have it exactly backwards. Either that, or I misunderstood
what your referent was for the "usually did". It looks like the referent
was a few paragraphs before, so perhaps I am misunderstanding it. Is
what I quoted above the intended referent? I can't find a closer one
that fits.

In programs meant to be somewhat portable, you did *NOT* assume that
double meant the same as real*8. You did one of three things.

1. You coded in such a way as to facilitate automated source code
modifications to switch between real and double precision declarations
as needed. I used to do this one in f77 days.

2. You used real*8. That did limit you to compilers that accepted this
syntax, which in turn tended to limit you to machines with power-of-two
word sizes. But at least it did the "right" thing regardless of whether
single precision was 32 or 64 bits.

3. If you were lucky enough to be coding after the introduction of f90,
you used its kind facility. 

Assuming that dounble precision meant real*8 was the opposite of being
somewhat portable. That meant you were just giving up on any machine
where that wasn't so.
 
> I did use CDC Fortran, but I don't remember what it did about this.

I do remember well. It did nothing. The "*" forms of declarations didn't
compile at all. Single precision was 60 bits, double was 120. The
120-bit double was quite slow. You did not want to just use double
precision code from other machines without changing the code - not if
you wanted it to run at a reasonable speed - not to speak of taking
reasonable space. Memory was precious; doubling the memory used by data
was painful.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

On Jun 28, 1:30=A0am, Clive Page <j...@main.machine> wrote:
> I whether anyone else would agree that it =A0may be time to legitimise th=
e
> 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. =A0Thus 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. =A0I have sometimes pointed ou=
t
> 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. =A0Unfortunately the simplest change: altering
> =A0 REAL*8 variable
> to
> =A0 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. =A0Few programmers that =
I
> know seem to be convinced that they ought to write something like
> =A0 REAL(KIND=3DSELECTED_REAL_KIND(15,99)) variable
> because that is so cumbersome and hard to read. =A0(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. =A0I 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. =A0The reader of code has to think "hmm, the first
> argument is more than seven, so the programmer probably wants IEEE
> double precision here". =A0The 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. =A0So there's obviousl=
y
> 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

Excellent proposal! I agree!
Code readability is as important an portability.

Hello,

On 2008-06-27 18:52:30 -0400, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

> Dan Nagle wrote:
> (snip)
> 
>> So you want to build into the language
>> a hardware dependency for the sake of the simplest of programs?
>> That strikes me as a big step backwards
>> for the very least gain.
> 
> OK, how about REAL*8 only means IEEE standard 64 bit binary
> floating point.  If a compiler doesn't support that, then
> don't support REAL*8.  (Fortran 77 compilers excepted.)

OK, now what does it mean to support 754?
Just the format, or all the exceptions,
or must support denorms, what??
> 
> Maybe new numbers for IEEE standard decimal float.

Please choose.  Is the radix to be 2 or 10?
(Or do you mean that a *new* real*<something-else>
is to reflect the radix?  BTW, Yuk!)  What older programs
are being supported now?
> 
> The kind system is nice and general.  It isn't easy to
> write algorithms so general, though.
> 
> For old programs, one has to verify what the programmer
> meant by REAL*8.

Yes, so why perpetuate it?  Surely, you've just admitted
that some kind of inquiry is necessary?

-- 
Cheers!

Dan Nagle

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Dan Nagle wrote:
> (snip)
> 
> > So you want to build into the language
> > a hardware dependency for the sake of the simplest of programs?
> > That strikes me as a big step backwards
> > for the very least gain.
> 
> OK, how about REAL*8 only means IEEE standard 64 bit binary
> floating point.
....
> For old programs, one has to verify what the programmer
> meant by REAL*8.

So you add something the only apparent benefit of which is to support
old programs, and then you make it so that it is incompatible with old
programs (very many of which were for systems that were not IEEE)? I
don't think so.

But then, I think my answer to the whole proposal to legitimize real*8
is "just say no". I don't think you are going to be able to come up with
a variant that I'll like or sufficient reason for me to support it. I
don't *WANT* to legitimize it. Sure, compilers tend to support it, which
is fine. That is already plenty enough to encourage some people to
continue using the practice on new code. Putting it in the standard,
even if you did simultaneously deprecate it (or make it obsolescent or
any of those other things) would just further encourage its use, which
I'm against. I would much rather it be quite evident to people that,
even though their compiler happens to accept it, this is not standard
Fortran code.

I see two arguments for the syntax.

1. Simplicity. I agree that a simple form is needed. There are better
solutions for that. See other posts.

2. Compatibility with old nonstandard code. I don't find that convincing
reason to put it in the standard. Either convert the code or depend on
vendors to continue supporting the form. If users can't convince the
vendors that it is important enough to do that, then I don't think that
they should try an end run by sticking it in the standard. And I find it
even less convincing if you stick it in the standard it in a way that
isn't actually compatible.

But I think that in the end, the short form is that my vote would just
be "no".

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

James Giles wrote:
(snip, someone wrote)

>>My proposal would be to make INTEGER*2 simply a synonym for
>>INTEGER(int16) in the current Fortran2008 proposed syntax.  If we get
>>unsigned integer kinds or bit-wise kinds, the same problems will beset
>>both.

> So, in other words a simple preprocessor would handle those
> old INTEGER starred declarations too.

A preprocessor to properly parse both fixed and free form
source isn't so simple.  Other than that, yes.

-- glen

Clive Page wrote:

> In message <5ZudnSe45MNp3vjVnZ2dnUVZ_o7inZ2d@comcast.com>, glen 
> herrmannsfeldt <gah@ugcs.caltech.edu> writes

>> I read his post mostly as a request for "REAL*8" as
>> a synonym for "DOUBLE PRECISION", (not counting the
>> first sentence).

> Just to clarify something: I don't think that DOUBLE PRECISION 
> necessarily means REAL*8.  Suppose your native word-length is 64-bits, 
> so that REAL means 8-bytes, won't DOUBLE PRECISION mean 16-bytes?  I 
> think I've used a CDC machine in the past for which that was true.   If 
> that's true, then the form "DOUBLE PRECISION" is too imprecise, it means 
> just "at least twice as much precision as real", and it is obsolescent 
> in the latest Standards for a good reason.

True, but in programs meant to be (somewhat) portable it usually did.

I did use CDC Fortran, but I don't remember what it did about this.
(The CDC machines had 60 bit REAL and, possibly in software emulation,
120 bit DOUBLE PRECISION.)

> On the other hand REAL*8 means exactly the same as REAL(real64) in the 
> proposed Fortran2008 notation.  So you can do global edit to convert old 
> code to be consistent with Fortran2008.  Maybe that's good enough, but 
> it still means there's a lot of old code out there which is currently 
> non-standard for rather trivial reasons.

On the 36 bit PDP-10, REAL*4 was 36 bits and REAL*8 72.
(Maybe only 71, I think both words have a sign bit.)

> I was also proposing that the whole set of word-lengths be supported, 
> i.e. INTEGER*1, INTEGER*2, INTEGER*4, INTEGER*8,
> REAL*4, REAL*8, and LOGICAL*1, LOGICAL*2, LOGICAL*4, as these are all 
> encountered in the wild.  I didn't mention all these because my original 
> posting was already rather long.

You don't find most of those in old code.  I don't remember IBM
compilers supporting INTEGER*1.  LOGICAL*1 yes, and often used
for character data.

-- glen

Dan Nagle wrote:
(snip)

> So you want to build into the language
> a hardware dependency for the sake of the simplest of programs?
> That strikes me as a big step backwards
> for the very least gain.

OK, how about REAL*8 only means IEEE standard 64 bit binary
floating point.  If a compiler doesn't support that, then
don't support REAL*8.  (Fortran 77 compilers excepted.)

Maybe new numbers for IEEE standard decimal float.

The kind system is nice and general.  It isn't easy to
write algorithms so general, though.

For old programs, one has to verify what the programmer
meant by REAL*8.

-- glen

James Giles wrote:
....
> We've been through this before.  And yes, it is pretty simple.
....

On reflection, it turns out to be easier that I thought.  In this
case, you only need to process those statements that begin
with a typename followed by an asterisk.  No legal statement
my begin so.  The only extensions I know of that begin with
such a pattern are the very declarations we want to filter out.
This works in either fixed form or free form.  Complications
might exist for lines containing multiple statements separated
by semicolons, and continued statements where the line
breaks in the middle of the typename or something.  Of course,
for most legacy code, there are no legal semicolons.  And who
breaks a line in the middle of the first token of the statement?

Still, finding the semicolons and dealing with continuations
is not hard.  So it's just as well to get the thing right.  You
don't even need to process those lines where the typename
is CHARACTER, since those have always permitted the starred
form.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

On Jun 27, 5:41=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Clive Page wrote:
> > In message <5ZudnSe45MNp3vjVnZ2dnUVZ_o7in...@comcast.com>, glen
> > herrmannsfeldt <g...@ugcs.caltech.edu> writes
> >> I read his post mostly as a request for "REAL*8" as
> >> a synonym for "DOUBLE PRECISION", (not counting the
> >> first sentence).
> > Just to clarify something: I don't think that DOUBLE PRECISION
> > necessarily means REAL*8. =A0Suppose your native word-length is 64-bits=
,
> > so that REAL means 8-bytes, won't DOUBLE PRECISION mean 16-bytes? =A0I
> > think I've used a CDC machine in the past for which that was true. =A0 =
If
> > that's true, then the form "DOUBLE PRECISION" is too imprecise, it mean=
s
> > just "at least twice as much precision as real", and it is obsolescent
> > in the latest Standards for a good reason.
>
> True, but in programs meant to be (somewhat) portable it usually did.
>
> I did use CDC Fortran, but I don't remember what it did about this.
> (The CDC machines had 60 bit REAL and, possibly in software emulation,
> 120 bit DOUBLE PRECISION.)
>
> > On the other hand REAL*8 means exactly the same as REAL(real64) in the
> > proposed Fortran2008 notation. =A0So you can do global edit to convert =
old
> > code to be consistent with Fortran2008. =A0Maybe that's good enough, bu=
t
> > it still means there's a lot of old code out there which is currently
> > non-standard for rather trivial reasons.
>
> On the 36 bit PDP-10, REAL*4 was 36 bits and REAL*8 72.
> (Maybe only 71, I think both words have a sign bit.)
>
> > I was also proposing that the whole set of word-lengths be supported,
> > i.e. INTEGER*1, INTEGER*2, INTEGER*4, INTEGER*8,
> > REAL*4, REAL*8, and LOGICAL*1, LOGICAL*2, LOGICAL*4, as these are all
> > encountered in the wild. =A0I didn't mention all these because my origi=
nal
> > posting was already rather long.
>
> You don't find most of those in old code. =A0I don't remember IBM
> compilers supporting INTEGER*1. =A0LOGICAL*1 yes, and often used
> for character data.

I've got billions (ok thousands) of lines of REAL*3, REAL*6, REAL*12,
INTEGER*3, INTEGER*6.  I want those supported too. (.not.)

>
> -- glen

On Jun 27, 5:17=A0pm, Dan Nagle <danna...@verizon.net> wrote:
> Hello,
>
> On 2008-06-27 18:52:30 -0400, glen herrmannsfeldt <g...@ugcs.caltech.edu>=
 said:
>
> > Dan Nagle wrote:
> > (snip)
>
> >> So you want to build into the language
> >> a hardware dependency for the sake of the simplest of programs?
> >> That strikes me as a big step backwards
> >> for the very least gain.
>
> > OK, how about REAL*8 only means IEEE standard 64 bit binary
> > floating point. =A0If a compiler doesn't support that, then
> > don't support REAL*8. =A0(Fortran 77 compilers excepted.)
>
> OK, now what does it mean to support 754?
> Just the format, or all the exceptions,
> or must support denorms, what??
>
>
>
> > Maybe new numbers for IEEE standard decimal float.
>
> Please choose. =A0Is the radix to be 2 or 10?
> (Or do you mean that a *new* real*<something-else>
> is to reflect the radix? =A0BTW, Yuk!) =A0What older programs
> are being supported now?

integer, radix=3D<2-36>, rangemin=3D<value>, rangemax=3D<value>, lsb=3D<val=
ue>
bitsize=3D<value>...

I want to be able to specify lots of attributes and have them done in
software if I define something non-native.  Let the simple kind system
live on, but I have more challenging requirements.

>
>
>
> > The kind system is nice and general. =A0It isn't easy to
> > write algorithms so general, though.
>
> > For old programs, one has to verify what the programmer
> > meant by REAL*8.
>
> Yes, so why perpetuate it? =A0Surely, you've just admitted
> that some kind of inquiry is necessary?
>
> --
> Cheers!
>
> Dan Nagle

Richard Maine wrote:
(snip)

>>True, but in programs meant to be (somewhat) portable it usually did.

> I'd say you have it exactly backwards. Either that, or I misunderstood
> what your referent was for the "usually did". It looks like the referent
> was a few paragraphs before, so perhaps I am misunderstanding it. Is
> what I quoted above the intended referent? I can't find a closer one
> that fits.

I meant somewhat portable.  If, for instance, one had available
IBM mainframes and VAX (both popular at about the same time)
REAL*8 would work on both.  The floating point range and
precision were a little different, but the size was the same.

> In programs meant to be somewhat portable, you did *NOT* assume that
> double meant the same as real*8. You did one of three things.

> 1. You coded in such a way as to facilitate automated source code
> modifications to switch between real and double precision declarations
> as needed. I used to do this one in f77 days.

I saw much of that.

> 2. You used real*8. That did limit you to compilers that accepted this
> syntax, which in turn tended to limit you to machines with power-of-two
> word sizes. But at least it did the "right" thing regardless of whether
> single precision was 32 or 64 bits.

I believe that IBM and DEC machines were often used at the
same facility.  IBM and CDC together much less often.

> 3. If you were lucky enough to be coding after the introduction of f90,
> you used its kind facility. 

> Assuming that dounble precision meant real*8 was the opposite of being
> somewhat portable. That meant you were just giving up on any machine
> where that wasn't so.

Yes.  But that was most in the later days of Fortran 66, as
(except CDC) companies tried to stay IBM compatible.
(Plus adding their own extensions.)

>>I did use CDC Fortran, but I don't remember what it did about this.

> I do remember well. It did nothing. The "*" forms of declarations didn't
> compile at all. Single precision was 60 bits, double was 120. The
> 120-bit double was quite slow. You did not want to just use double
> precision code from other machines without changing the code - not if
> you wanted it to run at a reasonable speed - not to speak of taking
> reasonable space. Memory was precious; doubling the memory used by data
> was painful.

I thought someone was suggesting that CDC might have accepted
REAL*8 for single precision (60 bit).  I presume that the 120
bit was required, as the standard requires a DOUBLE PRECISION,
even if you never want to use it.  (Thought it might be good
for accumulating sums.)

-- glen

GaryScott wrote:
....
>> Please choose. Is the radix to be 2 or 10?
>> (Or do you mean that a *new* real*<something-else>
>> is to reflect the radix? BTW, Yuk!) What older programs
>> are being supported now?
>
> integer, radix=<2-36>, rangemin=<value>, rangemax=<value>, lsb=<value>
> bitsize=<value>...
>
> I want to be able to specify lots of attributes and have them done in
> software if I define something non-native.  Let the simple kind system
> live on, but I have more challenging requirements.

What you want is a derived type with all those things as type
parameters.  Attributes are things that are independent of base
type.  So, unless your claiming that RADIX is a property of
LOGICAL or CHARACTER, I don't see how RADIX (or any of
the other things above) can be attributes.

In fact, it's not clear that a derived type with all those properties
couldn't already be written in Fortran 2003.  The problem is that
they decided to limit non-KIND type parameters to only be lengths.
There was no reason for that decision that I could discover.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

In article <2008062716090875249-dannagle@verizonnet>,
Dan Nagle  <dannagle@verizon.net> wrote:

>So you want to build into the language
>a hardware dependency for the sake of the simplest of programs?
>That strikes me as a big step backwards
>for the very least gain.

Note that the scheme that Fortran now uses was proven by PL/I to be
capable of building in hardware dependencies for no reason --
programmers asked for what ended up being 36 bit variables when 32
would have worked most of the time. This code wasn't portable when
32-bit hardware became the standard.

-- greg

On Jun 27, 12:32 pm, Dan Nagle <danna...@verizon.net> wrote:
> Hello,
>
> On 2008-06-27 14:42:09 -0400, John Appleyard <spamt...@polyhedron.com> said:
>
>
>
> > I think I agree with you Clive.   I never have liked KIND - I don't
> > want to specify the precision as such - some clever compiler writer
> > might give me *exactly* what I ask for - implemented in software.  I
> > want a clear way to pick a amongst the types that are implemented in
> > hardware, and the question I find myself asking is "how do I set the
> > KIND parameters to be absolutely sure that I will get REAL*8 or
> > INTEGER*1 or whatever?".
>
> So how will *N notation select among different radixes,
> even limiting the choice to what's available in hardware?

Any compiler implementor with a scintilla of good sense is not
going to use the current kind type parameter to distinguish
between radices.  Anyone who has seen the complicated
expressions involving SELECTED_REAL_KIND that some programmers
use to get the type sizes they want in what they think is a
portable way and understood that those expressions will break
with the new of the KIND= parameter will avoid it.

My preference is to add a new kind type parameter value
RADIX=.  Thus, a user could write

      REAL(RADIX=10, KIND=8) DX

to declare an 8-byte long decimal variable named DX.  I suppose
I would allow

      REAL(RADIX=10) DX*8

or even

      REAL (RADIX=10)*8 DX

Bob Corbett

James Giles <jamesgiles@worldnet.att.net> wrote:

> they decided to limit non-KIND type parameters to only be lengths.
> There was no reason for that decision that I could discover.

If I understood what you meant, perhaps I could answer. What do you mean
by "only be lengths?" Have you just been confused by the terminology
used? If so that wouldn't be surprising. Yes, type parameters are
categorized as kind or length. If they aren't kind parameters, they are
called length ones. But that doesn't actually mean that they have to
have anything in particular to do with lengths. Lengths is a common use
for them - thus the name, but that's not a restriction. I think there
was once a time when I objected to the term "length" since they don't
actually hav eto be lengths. I finally gave in on that, but I'm
suspicious that you are illustrating the original reasons for my
reluctance. Is your objection to anything other than the term?

The actual restrictions tend to have pretty concrete reasons... which
isn't to say that things couldn't be different, but they at least don't
tend to be arbitrary.

Perhaps the most fundamental distinction is that kind type parameters
are always known at compile time. Length type parameters need not be. Of
course, the standard doesn't say it in those words, but that's the crux
of it. From that distinction, many other things follow. For example,
kind type parameters play a role in generic disambiguation, but length
type parameters don't. That's because generic disambiguation is designed
to be done at compile time. There are a bunch of other things like that,
but they mostly follow in pretty "obvious" manner from the basic
distinction. For example, you can't use a length type parameter value to
specify a kind... because the length parameter value isn't necessarily
known at compile time. I can't think of any of the related restrictions
that I'd consider arbitrary.

Also note that there can be multiple kind type parameters. A type
parameter isn't necessarily a non-kind one just because its name isn't
KIND. I suppose that point might also be confusing. I'm stretching a bit
here, looking for possible things that you might be confused about
because I just can't figure out what your concrete complaint is here
(unless your complaint is about confusing terminology, in which case I
can't argue with it).

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Hello,

On 2008-06-27 20:07:56 -0400, lindahl@pbm.com (Greg Lindahl) said:

> programmers asked for what ended up being 36 bit variables when 32
> would have worked most of the time.

Pray please explain how the kind system
allows the requirement of bit-sizes.

-- 
Cheers!

Dan Nagle

robert.corbett@sun.com wrote:
....
> Any compiler implementor with a scintilla of good sense is not
> going to use the current kind type parameter to distinguish
> between radices.  [...]

Won't have any choice since that's what the standard will
mandate.

> [...]        Anyone who has seen the complicated
> expressions involving SELECTED_REAL_KIND that some programmers
> use to get the type sizes they want in what they think is a
> portable way and understood that those expressions will break
> with the new of the KIND= parameter will avoid it.

Yes, people abuse it.  It's their problem, not the implementor's
Tell them not to do that.  There are, what, say 3 or 4 different
KINDs of REALs?  Most people select some, assign some named
constants for the ones they want to use, and when they port to
a new platform they go throught the same 5 minute ritual.

> My preference is to add a new kind type parameter value
> RADIX=.  Thus, a user could write
>
>      REAL(RADIX=10, KIND=8) DX
>
> to declare an 8-byte long decimal variable named DX.  I suppose
> I would allow
>
>      REAL(RADIX=10) DX*8
>
> or even
>
>      REAL (RADIX=10)*8 DX

I can't express it text how thoroughly and completely I disagree
with that "solution" to the "problem".  It would take the average
user longer to work out the consequences of yet another KIND
type parameter than to just set some named constants for the
KINDs needed and move on.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

Richard Maine wrote:
> James Giles <jamesgiles@worldnet.att.net> wrote:
>
>> they decided to limit non-KIND type parameters to only be lengths.
>> There was no reason for that decision that I could discover.
>
> If I understood what you meant, perhaps I could answer. What do you
> mean by "only be lengths?" Have you just been confused by the
> terminology used? If so that wouldn't be surprising. Yes, type
> parameters are categorized as kind or length. If they aren't kind
> parameters, they are called length ones. But that doesn't actually
> mean that they have to have anything in particular to do with
> lengths. [...]

Well this is exacly the opposite of what Van Snyder told me
back when NON_KIND was removed as the keyword and LEN
was put in its place.  He insisted that LEN type parameter were
only for string lengths and array sizes.  If a user ever wanted non-
KIND type parameters to do anything else, the committee would
have to separately consider that and add yet another attribute name,
he said.  He claimed this was the advantage of the change - it
allowed the committee to extend to more type parameters in the
future. I claimed that implementors could already have extended
the set without the change of name (and that NON_KIND captured
the whole of any distinction that was needed).

If you're now saying that LEN type parameters *aren't* limited to
sizes and lengths of things, great.  But you people need to get
your stories straight.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra

On Jun 27, 5:51 pm, "James Giles" <jamesgi...@worldnet.att.net> wrote:
> robert.corb...@sun.com wrote:
>
> ...
>
> > Any compiler implementor with a scintilla of good sense is not
> > going to use the current kind type parameter to distinguish
> > between radices.  [...]
>
> Won't have any choice since that's what the standard will
> mandate.

That is silly.  The Fortran standard is not about to "mandate"
that implementations support decimal floating-point.  There
is nothing to prevent implementors from choosing to use
syntax that is not standard-conforming to support a feature
not required by the standard.

Bob Corbett

James Giles <jamesgiles@worldnet.att.net> wrote:

> Well this is exacly the opposite of what Van Snyder told me
> back when NON_KIND was removed as the keyword and LEN
> was put in its place.  He insisted that LEN type parameter were
> only for string lengths and array sizes.

Sorry, but he was just wrong. Or maybe that was what he proposed. But it
sure is not what passed into the standard.

> But you people need to get your stories straight.

Van and I have disagreed about more than a few things (though I have
much respect for him, including the fact that he is a *VERY* hard and
dilligent worker - makes disagreeing with him hard because he is really
persistent and will bury you in lots of material). That kind of thing is
why it is sometimes hard to explain the reasons why some things are so
other than that it is what got enough votes. What got enough votes to
get into the standard does not limit length parameters to lengths. To
the extent that you might get different answers from Van and me, the
definitive answer is in reading the standard itself. I don't think
you'll find any such restriction.

You will find that length type parameters can be used for lengths. But
you won't find that they can't be used for anything else. You will find
specific other things that they can't be used for - such as
initialization expressions (which in turn limits lots of places). But
you certainly won't find anything like "can only be used for string
lengths and array sizes".

It turns out that there aren't many places where you can usefully use
them, but that's just a lack of places that fit rthaer than any explicit
restriction. One "interesting" form of use is as a readonly component.
You can define a length type parameter value when you create an object,
perhaps by allocation. You can then "read" the value much like a
component (indeed even using notation like that for a component), but as
it isn't actually a component,you can't change its value without
destroying and recreating the object.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

robert.corbett@sun.com wrote:
> On Jun 27, 5:51 pm, "James Giles" <jamesgi...@worldnet.att.net> wrote:
>> robert.corb...@sun.com wrote:
>>
>> ...
>>
>>> Any compiler implementor with a scintilla of good sense is not
>>> going to use the current kind type parameter to distinguish
>>> between radices.  [...]
>>
>> Won't have any choice since that's what the standard will
>> mandate.
>
> That is silly.  The Fortran standard is not about to "mandate"
> that implementations support decimal floating-point.  There
> is nothing to prevent implementors from choosing to use
> syntax that is not standard-conforming to support a feature
> not required by the standard.

Other than the fact that users will demand it.  I'm glad I no longer
have a Sun workstation... :-(

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

On Jun 27, 1:23 pm, "James Giles" <jamesgi...@worldnet.att.net> 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
>
> Which 8 byte REAL is to be the one supported?  The binary or
> the new decimal.  Whichever is your answer, how would a user
> select the other one?  If and when we ever get unsigned integer
> KINDs, or bit-wise KINDs, what does the *2 mean?

The solution in Sun Fortran is to introduce a new intrinsic
type UNSIGNED.  It avoids all the nasty problems that arise
from the model sets (see Section 13.4 of the Fortran 2003
standard) not matching the set of representable values.

Bob Corbett

Richard Maine wrote:
> James Giles <jamesgiles@worldnet.att.net> wrote:
>
>> Well this is exacly the opposite of what Van Snyder told me
>> back when NON_KIND was removed as the keyword and LEN
>> was put in its place.  He insisted that LEN type parameter were
>> only for string lengths and array sizes.
>
> Sorry, but he was just wrong. Or maybe that was what he proposed. But
> it sure is not what passed into the standard.

In that case, everything Scott asked for can be done except the
BIT_SIZE property (for which he would still need bit-resolution
KINDs).

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

glen herrmannsfeldt wrote:
> James Giles wrote:
>
>> On reflection, it turns out to be easier that I thought.  In this
>> case, you only need to process those statements that begin
>> with a typename followed by an asterisk.  No legal statement
>> my begin so.
>
> There is also
>
>       REALFUNCTIONF*8(X)


REALFUNCTIONF isn't a type name.  Even if it was, the above
isn't valid.  I can't think even of an exended compiler that would
accept it.  Were there such beasts?  Somewone earlier mentioned
something like:

   real x*8

Are there extended implementations where that's the same as

   real*8 x

Bletch.  I'm betting there's not a lot of legacy code that does that.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

James Giles wrote:

> On reflection, it turns out to be easier that I thought.  In this
> case, you only need to process those statements that begin
> with a typename followed by an asterisk.  No legal statement
> my begin so.  

There is also

       REALFUNCTIONF*8(X)

but I agree, that isn't so much harder.

-- glen

"James Giles" <jamesgiles@worldnet.att.net> wrote in message 
news:oie9k.77898$102.45062@bgtnsc05-news.ops.worldnet.att.net...

> On reflection, it turns out to be easier that I thought.  In this
> case, you only need to process those statements that begin
> with a typename followed by an asterisk.

C:\gfortran\clf\realstar8>type realstar8.f90
module mykinds
   implicit none
   real*8, private, parameter :: r8p = 0
   integer, parameter :: r8 = kind(r8p)
end module mykinds

program test
   use mykinds
   implicit none
   write(*,*) [real(r8) :: 1, 2, 3]
   write(*,*) [real*8 :: 1, 2, 3]
end program test

C:\gfortran\clf\realstar8>gfortran realstar8.f90 -orealstar8

C:\gfortran\clf\realstar8>realstar8
  1.00000000000000000        2.0000000000000000        3.0000000000000000
  1.00000000000000000        2.0000000000000000        3.0000000000000000

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

James Van Buskirk wrote:
....
>   write(*,*) [real*8 :: 1, 2, 3]

You've got *legacy* code that does that.  I wouldn't
have thought most compilers would accept the standard
form of that yet.  It's not at all relevant to this discussion.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

Followup up to myself. I know...

Richard Maine <nospam@see.signature> wrote:

> James Giles <jamesgiles@worldnet.att.net> wrote:
> 
> > Well this is exacly the opposite of what Van Snyder told me
> > back when NON_KIND was removed as the keyword and LEN
> > was put in its place.  He insisted that LEN type parameter were
> > only for string lengths and array sizes.
> 
> Sorry, but he was just wrong. Or maybe that was what he proposed. But it
> sure is not what passed into the standard.

It occurs to me that I think I know what was being referred to. The
statement of it above isn't accurate, but that could have been either
Van misdescribing it, you misunderstanding what he said, a reflection of
an unpassed proposal, or whatever.

I do recall a somewhat related discussion, now that you prompt my
memory, of why some people (presumably including Van) disliked the term
nonkind and wanted it called length instead. The argument was that if
some other sort (have to choose the word carefully to avoid ones that
already have technical Fortran meanings - fortunately English has a lot
of synonyms for it) of type parameter came along later, the terms "kind"
and "nonkind" would more or less force us to categorize it as one or the
other of those, while the terms "kind" and "length" would not be so
restrictive.

But that was mostly just a debate about the terminology. I'm not
recalling whether someone might have wanted to actually restrict length
parameters to being lengths or sizes. The proposal might have been made,
and possibly even in conjunction with the proposal to use the term
"length" instead of "nonkind". While I don't recall it for certain, that
does bring twinges of familliarity. If so, the restrictive part of the
proposal didn't "fly", but the name choice did.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

On Jun 27, 6:47 pm, "James Giles" <jamesgi...@worldnet.att.net> wrote:
> robert.corb...@sun.com wrote:
> > On Jun 27, 5:51 pm, "James Giles" <jamesgi...@worldnet.att.net> wrote:
> >> robert.corb...@sun.com wrote:
>
> >> ...
>
> >>> Any compiler implementor with a scintilla of good sense is not
> >>> going to use the current kind type parameter to distinguish
> >>> between radices.  [...]
>
> >> Won't have any choice since that's what the standard will
> >> mandate.
>
> > That is silly.  The Fortran standard is not about to "mandate"
> > that implementations support decimal floating-point.  There
> > is nothing to prevent implementors from choosing to use
> > syntax that is not standard-conforming to support a feature
> > not required by the standard.
>
> Other than the fact that users will demand it.  I'm glad I no longer
> have a Sun workstation... :-(

Sun Fortran is now available for Linux PCs.  It can be downloaded
at no cost from Sun's website.

Bob Corbett

"James Van Buskirk" <not_valid@comcast.net> wrote in message 
news:HbSdnUe_9o32LfjVnZ2dnUVZ_uqdnZ2d@comcast.com...

> module mykinds
>   implicit none
>   real*8, private, parameter :: r8p = 0
>   integer, parameter :: r8 = kind(r8p)
> end module mykinds

Dang!  I missed the opportunity to eliminate that ugly r8p named
constant:

C:\gfortran\clf\realstar8>type r8.f90
program x
   implicit none
   integer, parameter :: r8 = kind([real*8 :: ])

   write(*,*) real(1,r8)
end program x

C:\gfortran\clf\realstar8>gfortran r8.f90 -or8

C:\gfortran\clf\realstar8>r8
  1.00000000000000000

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

On Jun 27, 8:30 am, Clive Page <j...@main.machine> wrote:

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

It is not too late to send in a comment to J3 for the public
review of Fortran 2008, but there is not much time left.
There is a small but positive chance they will accept your
proposal.  The Sun is more likely to turn into a supernova
tomorrow, but it could happen.  Were I in your place, I would
file the comment.  I voted for George McGovern in 1972.

Bob Corbett

In message 
<01610bb3-e8d0-4e24-93cf-38d3e67dbc92@z16g2000prn.googlegroups.com>, 
robert.corbett@sun.com writes
>It is not too late to send in a comment to J3 for the public
>review of Fortran 2008, but there is not much time left.
>There is a small but positive chance they will accept your
>proposal.  The Sun is more likely to turn into a supernova
>tomorrow, but it could happen.  Were I in your place, I would
>file the comment.  I voted for George McGovern in 1972.

Bob

Thanks for your comment.  As an astronomer I have a rough idea of the 
probability that the Sun will turn into a supernova tomorrow, and I 
think that even a SELECTED_REAL_KIND(15,200) variable won't distinguish 
the value from zero.  So maybe it's a waste of time.


-- 
Clive Page

James Giles wrote:
(snip, I wrote)

>>There is also

>>      REALFUNCTIONF*8(X)

> REALFUNCTIONF isn't a type name.  Even if it was, the above
> isn't valid.  

As far as I know, the *8 form originated in IBM compilers,
and this is the form that they used for functions.
That is, it is the only form IBM allowed.

It seems that some DEC compilers accept either form
for functions. (I just tried it on a DECSystem-20.)

  g95 accepts only the prefix form for functions.

> I can't think even of an exended compiler that would
> accept it.  Were there such beasts?  Somewone earlier mentioned
> something like:

>    real x*8

> Are there extended implementations where that's the same as

>    real*8 x

Yes, the IBM compilers accept both forms.

Also, both forms are currently allowed for CHARACTER declarations.
(The suffix form overrides the length.)

       real*8 x,y,z*4

> Bletch.  I'm betting there's not a lot of legacy code that does that.

No idea on that one.

-- glen

On 2008-06-28, Clive Page <junk@main.machine> wrote:
> As an astronomer I have a rough idea of the 
> probability that the Sun will turn into a supernova tomorrow, and I 
> think that even a SELECTED_REAL_KIND(15,200) variable won't distinguish 
> the value from zero.

Makes a good SF story, though (Niven's "Inconstant Moon").

In article <1ij77ub.847j731wf21x3N%nospam@see.signature>,
 nospam@see.signature (Richard Maine) wrote:

> 2. You used real*8. That did limit you to compilers that accepted this
> syntax, which in turn tended to limit you to machines with power-of-two
> word sizes. But at least it did the "right" thing regardless of whether
> single precision was 32 or 64 bits.

This isn't exactly the way I remember it.  Of course, my memory 
could be wrong.  I typically used "real*8" in my code because that 
was the *most* portable way to write the code.  On some machines it 
meant the equivalent to "real" and on other machines it meant the 
equivalent to "double precision", and that de facto feature is what 
made it the most portable way to write code.  Nonstandard, but 
portable.  I used several machines that did not use power-of-two 
word sizes that supported "real*8" declarations nonetheless.  
Typically, they mapped them to what their hardware supported that 
was close, and that was exactly what I wanted them to do.  These 
non-power-of-two machines included univac (36/72 bit floating 
point), PDP-10 (36/72), DecSystem 20 (36/72), harris (24/48), and, 
if my memory is right, CDC (60/120).  Of course, this also worked on 
power-of-two machines that did not have byte addressing, such as 
Cray and FPS (64-bit words, with 64/128 floating point).

However, this syntax was both limiting and confusing.  Now that we 
have parameterized kinds, which support every possible precision 
that some combination of hardware and software might enable, I see 
no need to go backward.  Remember, it isn't just declarations of 
variables that are important, it is also literal constants and the 
ability to support several floating point formats of the same length 
in the same code (e.g. to match argument types with external 
libraries).  F90 kinds solves these problems in a straightforward, 
clear, and open-ended way.

$.02 -Ron Shepard

Ron Shepard wrote:
> In article <1ij77ub.847j731wf21x3N%nospam@see.signature>,
>  nospam@see.signature (Richard Maine) wrote:
> 
> 
>>2. You used real*8. That did limit you to compilers that accepted this
>>syntax, which in turn tended to limit you to machines with power-of-two
>>word sizes. But at least it did the "right" thing regardless of whether
>>single precision was 32 or 64 bits.
> 
> 
> This isn't exactly the way I remember it.  Of course, my memory 
> could be wrong.  I typically used "real*8" in my code because that 
> was the *most* portable way to write the code.  On some machines it 
> meant the equivalent to "real" and on other machines it meant the 
> equivalent to "double precision", and that de facto feature is what 
> made it the most portable way to write code.  Nonstandard, but 
> portable.  I used several machines that did not use power-of-two 
> word sizes that supported "real*8" declarations nonetheless.  
> Typically, they mapped them to what their hardware supported that 
> was close, and that was exactly what I wanted them to do.  These 
> non-power-of-two machines included univac (36/72 bit floating 
> point), PDP-10 (36/72), DecSystem 20 (36/72), harris (24/48

/96)

<snip>
> $.02 -Ron Shepard


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Ron Shepard wrote:
> In article <1ij77ub.847j731wf21x3N%nospam@see.signature>,
>  nospam@see.signature (Richard Maine) wrote:
> 
>> 2. You used real*8. That did limit you to compilers that accepted this
>> syntax, which in turn tended to limit you to machines with power-of-two
>> word sizes. But at least it did the "right" thing regardless of whether
>> single precision was 32 or 64 bits.
> 
....
> non-power-of-two machines included univac (36/72 bit floating 
> point), PDP-10 (36/72), DecSystem 20 (36/72), harris (24/48), and, 
> if my memory is right, CDC (60/120).  ...

I don't recall *8 on CDC...or Philco 2000, either, for that matter :)

--

Ron Shepard <ron-shepard@NOSPAM.comcast.net> wrote:

> In article <1ij77ub.847j731wf21x3N%nospam@see.signature>,
>  nospam@see.signature (Richard Maine) wrote:
> 
> > 2. You used real*8. That did limit you to compilers that accepted this
> > syntax, which in turn tended to limit you to machines with power-of-two
> > word sizes. But at least it did the "right" thing regardless of whether
> > single precision was 32 or 64 bits.
> 
> I typically used "real*8" in my code because that 
> was the *most* portable way to write the code.

That's partly what I was saying - that it was more portable than double
precision in that it did the "right thing" if the compiler supported it
at all. But there were major compilers that did not support it. In
particular...

> if my memory is right, CDC (60/120).

I'm (pretty) sure it did not work with the CDC machines. Since Dryden's
central computer was a CDC from 1973 through 1984, and since that was
the era where "central computer" also tended to translate into "pretty
much the only computer one had ready access to", this made the CDC case
rather a big dea for me.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Thomas Koenig <tkoenig@netcologne.de> wrote:

> On 2008-06-28, Clive Page <junk@main.machine> wrote:
> > As an astronomer I have a rough idea of the 
> > probability that the Sun will turn into a supernova tomorrow, and I
> > think that even a SELECTED_REAL_KIND(15,200) variable won't distinguish
> > the value from zero.
> 
> Makes a good SF story, though (Niven's "Inconstant Moon").

Indeed. Back when I was at UCLA, I used to frequent the coffee shop
where much of that story was placed. I think it got torn down a few
decades ago, though.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

In article <1ij8ks5.1g7ylz31v43oymN%nospam@see.signature>,
 nospam@see.signature (Richard Maine) wrote:

> > if my memory is right, CDC (60/120).
> 
> I'm (pretty) sure it did not work with the CDC machines. Since Dryden's
> central computer was a CDC from 1973 through 1984, and since that was
> the era where "central computer" also tended to translate into "pretty
> much the only computer one had ready access to", this made the CDC case
> rather a big dea for me.

Yes, I read this before I posted, so that is why I said that my 
memory could be off for that one.  I used a CDC 6600 for about a 
year in 1980 and 1981, and I don't recall having to change my code 
(which had real*8 declarations) in order to get it to run.  But, I 
also remember that I carefully wrote my codes so that I could easily 
change between real/double precision/real*8 if necessary just with 
text substitution.  In fact, I had a fortran program that would do 
this.  So I might have done one of the substitutions on the CDC and 
just forgot about it.

$.02 -Ron Shepard

Ron Shepard wrote:
....
> ... So I might have done one of the substitutions on the CDC and 
> just forgot about it.

I'm virtually positive this must be the case.

I left the CDC shop environment a little earlier ('78) so some later 
compiler could possibly have picked up the extension (although for the 
machine it would seem _really_ silly so I would think if it were ever 
done it would have been an on-site customization for some specific 
customer who wasn't so careful as you :) ).

--

Ron Shepard wrote:
(snip)

 > I used several machines that did not use power-of-two
> word sizes that supported "real*8" declarations nonetheless.  
> Typically, they mapped them to what their hardware supported that 
> was close, and that was exactly what I wanted them to do.  These 
> non-power-of-two machines included univac (36/72 bit floating 
> point), PDP-10 (36/72), DecSystem 20 (36/72), harris (24/48), and, 
> if my memory is right, CDC (60/120).  Of course, this also worked on 
> power-of-two machines that did not have byte addressing, such as 
> Cray and FPS (64-bit words, with 64/128 floating point).

I now have an account on an actual PDP-10 (that is, not emulated).
On  DECsystem-20, REAL*8 works, including both forms for the
FUNCTION statement.  (Both the IBM REAL FUNCTION F*8(X) form
and the more obvious REAL*8 FUNCTION F(X) form.)

I believe there is someone running a real CDC machine, though
maybe only one day a week.

-- glen

glen herrmannsfeldt wrote:
....
> I now have an account on an actual PDP-10 (that is, not emulated).
> On  DECsystem-20, ...
> 
> I believe there is someone running a real CDC machine, though
> maybe only one day a week.

Anyone know if a Philco-2000 class machine even exist anywhere? :)

--

In article <2008062720414243658-dannagle@verizonnet>,
Dan Nagle  <dannagle@verizon.net> wrote:
>Hello,
>
>On 2008-06-27 20:07:56 -0400, lindahl@pbm.com (Greg Lindahl) said:
>
>> programmers asked for what ended up being 36 bit variables when 32
>> would have worked most of the time.
>
>Pray please explain how the kind system
>allows the requirement of bit-sizes.

Your computer is binary, not decimal, right? So if you ask for a kind
which doesn't fit into 32 bits, you have a requirement that your type
won't fit into 32 bits. If we're talking about an integer, then this is
extremely inefficient on a processor which doesn't have any integer
type in hardware bigger than 32 bits.

-- greg

Hello,

On 2008-06-29 18:34:23 -0400, lindahl@pbm.com (Greg Lindahl) said:

> In article <2008062720414243658-dannagle@verizonnet>,
> Dan Nagle  <dannagle@verizon.net> wrote:
>> Hello,
>> 
>> On 2008-06-27 20:07:56 -0400, lindahl@pbm.com (Greg Lindahl) said:
>> 
>>> programmers asked for what ended up being 36 bit variables when 32
>>> would have worked most of the time.
>> 
>> Pray please explain how the kind system
>> allows the requirement of bit-sizes.
> 
> Your computer is binary, not decimal, right?

My _current_ computers, yes.  What say you of my future computers?
BTW, if my calculators count as computers (programmable, but no Fortran),
then not all are binary.  You're dancing on a slippery slope.

>  So if you ask for a kind
> which doesn't fit into 32 bits, you have a requirement that your type
> won't fit into 32 bits. If we're talking about an integer, then this is
> extremely inefficient on a processor which doesn't have any integer
> type in hardware bigger than 32 bits.

One of the few requirements (in f08) of kinds is that
at least one kind of integer must support
about 18 decimal digits (that is, 64 bits).

The proposal is/was well-supported among vendors.
Addresses and file sizes lead the way.

-- 
Cheers!

Dan Nagle

In article <200806291902548930-dannagle@verizonnet>,
Dan Nagle  <dannagle@verizon.net> wrote:

>My _current_ computers, yes.  What say you of my future computers?

That they're irrelevant to the historical point I'm making?

>BTW, if my calculators count as computers (programmable, but no Fortran),
>then not all are binary.  You're dancing on a slippery slope.

I owned HP calculators too. That's irrelevant to the point, which was
about actual historical people using PL/I on actual computers screwing
up the 36- to 32-bit transition thanks to a Fortran-like KIND
specifier.

>>  So if you ask for a kind
>> which doesn't fit into 32 bits, you have a requirement that your type
>> won't fit into 32 bits. If we're talking about an integer, then this is
>> extremely inefficient on a processor which doesn't have any integer
>> type in hardware bigger than 32 bits.
>
>One of the few requirements (in f08) of kinds is that
>at least one kind of integer must support
>about 18 decimal digits (that is, 64 bits).

Even then, you have the further problem of programs getting much
slower thanks to using overly-long data types.

Now, I'll admit that it's unlikely that we'll have another 36- to
32-bit transition any time soon. But I'm pretty sure you're completely
missing the historical lesson to be learned, while you quibble away.
Suit yourself.

-- greg

Hello,

On 2008-06-29 21:07:25 -0400, lindahl@pbm.com (Greg Lindahl) said:

>  But I'm pretty sure you're completely
> missing the historical lesson to be learned, while you quibble away.
> Suit yourself.

No, I'm making the simple point that
the more general kind mechanism, rather than the simpler
"*N" notation, has the _possibility_ of treating
future hardware.  As you say, suit yourself.
And quibble about history as you will.

That is, future kinds will involve more than
a one-dimensional space (size) to be searched.

-- 
Cheers!

Dan Nagle

In article <2008062921240411272-dannagle@verizonnet>,
Dan Nagle  <dannagle@verizon.net> wrote:

>No, I'm making the simple point that
>the more general kind mechanism, rather than the simpler
>"*N" notation, has the _possibility_ of treating
>future hardware.  As you say, suit yourself.

Uh, the point you're making is an obvious one -- and I agree with
it. I was just showing an example of how it went wrong in the
past.

-- g

Dan Nagle <dannagle@verizon.net> wrote:

> Hello,
> 
> On 2008-06-27 20:07:56 -0400, lindahl@pbm.com (Greg Lindahl) said:
> 
> > programmers asked for what ended up being 36 bit variables when 32
> > would have worked most of the time.
> 
> Pray please explain how the kind system
> allows the requirement of bit-sizes.
You know the algorithm works for 36 bit integers, but have not checked
for 32 bit fit during the coding. To be on the safe side you ask for an
integer kind that in decimal can hold values up to 10^10. Transfer to a
32 bit machine and you end up asking for 64 bit integers doubling the
memory required for integer values, and perhaps aking for something that
is not available. Similar problems can occur for floating point.

<robert.corbett@sun.com> wrote:

> On Jun 27, 12:32 pm, Dan Nagle <danna...@verizon.net> wrote:
> > Hello,
> >
> > On 2008-06-27 14:42:09 -0400, John Appleyard <spamt...@polyhedron.com> said:
> >
> >
> >
> > > I think I agree with you Clive.   I never have liked KIND - I don't
> > > want to specify the precision as such - some clever compiler writer
> > > might give me *exactly* what I ask for - implemented in software.  I
> > > want a clear way to pick a amongst the types that are implemented in
> > > hardware, and the question I find myself asking is "how do I set the
> > > KIND parameters to be absolutely sure that I will get REAL*8 or
> > > INTEGER*1 or whatever?".
> >
> > So how will *N notation select among different radixes,
> > even limiting the choice to what's available in hardware?
> 
> Any compiler implementor with a scintilla of good sense is not
> going to use the current kind type parameter to distinguish
> between radices.  Anyone who has seen the complicated
> expressions involving SELECTED_REAL_KIND that some programmers
> use to get the type sizes they want in what they think is a
> portable way and understood that those expressions will break
> with the new of the KIND= parameter will avoid it.
> 
> My preference is to add a new kind type parameter value
> RADIX=.  Thus, a user could write
> 
>       REAL(RADIX=10, KIND=8) DX
> 
> to declare an 8-byte long decimal variable named DX.  I suppose
> I would allow
> 
>       REAL(RADIX=10) DX*8
> 
> or even
> 
>       REAL (RADIX=10)*8 DX
> 
> Bob Corbett

Given the computational complexity required to convert between radices,
anyone who tries to (explicitly) use different radices in the same code
will be painfully surprised. I would expect most compiler writers (if
the machine allows different radices) will have a compile time switch to
choose he radix external to the code.

On Jun 29, 7:07 pm, wclod...@los-alamos.net (William Clodius) wrote:

> Given the computational complexity required to convert between radices,
> anyone who tries to (explicitly) use different radices in the same code
> will be painfully surprised. I would expect most compiler writers (if
> the machine allows different radices) will have a compile time switch to
> choose he radix external to the code.

You are correct about the cost of the conversions.  One of the
members of J3 pointed out this issue.  If I were king, I would
ban implicit radix conversions of floating-point values.

Bob Corbett

Hello,

On 2008-06-29 22:07:51 -0400, wclodius@los-alamos.net (William Clodius) said:

> You know the algorithm works for 36 bit integers, but have not checked
> for 32 bit fit during the coding.

OK.  And I've lost my test cases?

>  To be on the safe side you ask for an
> integer kind that in decimal can hold values up to 10^10. Transfer to a
> 32 bit machine and you end up asking for 64 bit integers doubling the
> memory required for integer values, and perhaps aking for something that
> is not available. Similar problems can occur for floating point.

And how would using integer*4 (on the 36-bit system)
leave me any better off?  Indeed, I think I'm hurting badly
with the *N approach.

The way I get similar problems with floating point
is to try to transfer real and double precision declarations
between 32-bit systems and 64-bit systems.

-- 
Cheers!

Dan Nagle

In article <2008063018072927544-dannagle@verizonnet>,
Dan Nagle  <dannagle@verizon.net> wrote:

>And how would using integer*4 (on the 36-bit system)
>leave me any better off?  Indeed, I think I'm hurting badly
>with the *N approach.

Why are you reading so many things into the argument? No one said that
using FOO*4 was any better.

-- greg

Dan Nagle wrote:
(snip)

> And how would using integer*4 (on the 36-bit system)
> leave me any better off?  Indeed, I think I'm hurting badly
> with the *N approach.

The DEC 36 bit compilers accept INTEGER*4, REAL*4, and REAL*8.
(See http://www.pdpplanet.com/ to try them.)

If you know where a running 7090 is I would try that.

I know *4 from OS/360 Fortran IV, I don't know if it
existed for the 7090 Fortran IV compilers.

-- glen

Paul van Delst wrote in message ...

>Nope. I would not like to see the usage of REAL*8 legitimised. I find the kind type system
>makes for much more flexible code. I like being able to change a *single* parameter in my
>type kinds module and *all* my generically defined reals and complex's switch between
>single<->double precision.

hear hear!

In two words, N  O.

glen herrmannsfeldt wrote in message ...
>Richard Maine wrote:
>
>> Clive Page <junk@main.machine> 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)),

What?
REAL*8 FUNCTION F(X)
was how it was written.

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

You have to be joking.

> not to mention how long it takes using KINDs.

It's actually shorter for KINDs (non-trivial programs, that is).

Richard Maine wrote in message <1ij6xc1.d2a6ijuchhqeN%nospam@see.signature>...

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

Whether a user specifies 12 or 13 digits or whatever, it's because he wants
at least that accuracy.

>If selected_real_kind asked about binary instead of decimal precision,
>that would be an improvement. (I've proposed an option for that, and I
>think a variant of that might also be in, but I haven't kept up). But I
>think the best option would be that which most closely matched the way
>people most naturally ask. That's not in terms of digits of precision,
>be they decimal or binary digits. People most commonly ask in terms of
>the size of the representation - i.e. they might ask for the 64-bit (or
>8-byte) option.

Do they?
It's typically in terms of single and double precision.

Richard Maine wrote in message <1ij6xc1.d2a6ijuchhqeN%nospam@see.signature>...
>Paul van Delst <Paul.vanDelst@noaa.gov> wrote:

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

Let's not forget 64-bit and 80-bit.

glen herrmannsfeldt wrote in message ...
>Richard Maine wrote:
>> Paul van Delst <Paul.vanDelst@noaa.gov> wrote:
>
>>>Could someone explain to me the cumbersomeness of
>
>> SELECTED_REAL(INT)_KIND() ??
>
>>>I agree the syntax is a bit wordy,
>
>Not so wordy as
>
>       INTEGER (SELECTED_INT_KIND(9)) :: I
>
>compare to C's
>
>       int i;
>
>> 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.
>
>PL/I only has specifiers in terms of either binary or decimal
>digits.  In most case, people specify the values for their
>favorite system.  PL/I uses 3.32 as the conversion between
>the two.  (Except that IBM compilers, given a request for
>FLOAT DECIMAL(16), which comes out 53.12 bits, uses 53
>instead of rounding up to 54.)

For non IEEE and double words, IBM hardware allowed
for hex float with 53 maximum guaranteed binary bits, hence
it could not "round up" to 54 because the hardware
could not support it.

But in any case PL/I compilers use whatever hardware
is available.  And if decimal float is available, the compiler
uses decimal hardware when FLOAT DECIMAL (16) is
specified, and binary hardware (if available) when FLOAT BINARY
is specified.

robin wrote:
(snip, I wrote)

>> You also have to get functions right
>> (REAL FUNCTION F*8(X)),

> What?
> REAL*8 FUNCTION F(X)
> was how it was written.

I don't suppose you thought about actually looking it up?

I have GC28-6515-10, and it looks just like the one I wrote.

-- glen

On 27 Jun., 21:58, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
[snip]

> I agree, though if the values are significant digits then the
> numbers you actual want are 24 and 53 in many cases.  Still,
> I would like to see SELECTED_REAL_BIN_KIND() and SELECTED_BIN_INT_KIND()
> (except that they are even longer).

[snip]

> I would vote for BINARY_REAL_KIND() and BINARY_INT_KIND().

If Fortran 2008 were to introduce precision specification in terms of
binary digits, I'd suggest extending SELECTED_bla_KIND by optional
parameters to

  SELECTED_bla_KIND(DEC=3Ddec_digits, BIN=3Dbin_digits)

which does not introduce new keywords and (more importantly) is
compatible with the existing standard.

Just my 0.02=80

dlw

robin wrote:
(snip)

> For non IEEE and double words, IBM hardware allowed
> for hex float with 53 maximum guaranteed binary bits, hence
> it could not "round up" to 54 because the hardware
> could not support it.

Extended precision hardware has existed since the
360/85, and all 370 and later processors.
Software emulation is used for other S/360 processors.

> But in any case PL/I compilers use whatever hardware
> is available.  And if decimal float is available, the compiler
> uses decimal hardware when FLOAT DECIMAL (16) is
> specified, and binary hardware (if available) when FLOAT BINARY
> is specified.

See:

http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/ibmol004/4.1.5

http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/ibmol004/4.1.6

http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/ibmol004/A.0

-- glen

On Jul 1, 10:45=A0am, Dennis Wassel <dennis.was...@googlemail.com>
wrote:
> On 27 Jun., 21:58, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> [snip]
>
> > I agree, though if the values are significant digits then the
> > numbers you actual want are 24 and 53 in many cases. =A0Still,
> > I would like to see SELECTED_REAL_BIN_KIND() and SELECTED_BIN_INT_KIND()=

> > (except that they are even longer).
>
> [snip]
>
> > I would vote for BINARY_REAL_KIND() and BINARY_INT_KIND().
>
> If Fortran 2008 were to introduce precision specification in terms of
> binary digits, I'd suggest extending SELECTED_bla_KIND by optional
> parameters to
>
> =A0 SELECTED_bla_KIND(DEC=3Ddec_digits, BIN=3Dbin_digits)
>
> which does not introduce new keywords and (more importantly) is
> compatible with the existing standard.

:quibble.

Isn't the common definition of a keyword "name=3Dvalue"?  So "DEC=3D" and
"BIN=3D" are "keywords".

:equibble.

>
> Just my 0.02=80
>
> dlw

GaryScott <garylscott@sbcglobal.net> wrote:

> On Jul 1, 10:45 am, Dennis Wassel <dennis.was...@googlemail.com>
> wrote:
> > On 27 Jun., 21:58, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> > [snip]

> > > I would vote for BINARY_REAL_KIND() and BINARY_INT_KIND().
> >
> > If Fortran 2008 were to introduce precision specification in terms of
> > binary digits, I'd suggest extending SELECTED_bla_KIND by optional
> > parameters to
> >
> >   SELECTED_bla_KIND(DEC=dec_digits, BIN=bin_digits)
> >
> > which does not introduce new keywords and (more importantly) is
> > compatible with the existing standard.

> Isn't the common definition of a keyword "name=value"?  So "DEC=" and
> "BIN=" are "keywords".

Yes, there are several different usages of the term "keyword" in the
language.  Things like argument names are one of them, while procedure
names are not. So that's not the right term here... but I do agree with
the concept. I think he is talking about the global namespace instead of
about keywords. I'd prefer new optional arguments for the existing
intrinsics rather than whole new intrinsics. I'd probably factor the
arguments differently (something more like keeping the existing
precision argument and adding one to specify the units of measure), but
that's a lower-level detail.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

GaryScott wrote:
(snip)

>>>I would vote for BINARY_REAL_KIND() and BINARY_INT_KIND().

>>If Fortran 2008 were to introduce precision specification in terms of
>>binary digits, I'd suggest extending SELECTED_bla_KIND by optional
>>parameters to

>>  SELECTED_bla_KIND(DEC=dec_digits, BIN=bin_digits)

I suppose I like those.  There is also the question
of choice of base for machines with both binary and
decimal floating point.  Would you add another for
selecting BASE?   Allow both BIN= and DEC=, and take
the most restrictive value?

>>which does not introduce new keywords and (more importantly) is
>>compatible with the existing standard.

> :quibble.

> Isn't the common definition of a keyword "name=value"? 
> So "DEC=" and "BIN=" are "keywords".

> :equibble.

Maybe so, but they are in a different name space.
It seems they are called 'argument keywords.'

Richard Maine wrote:
(snip, someone wrote)

>>>  SELECTED_bla_KIND(DEC=dec_digits, BIN=bin_digits)
(snip)

> I'd prefer new optional arguments for the existing
> intrinsics rather than whole new intrinsics. I'd probably factor the
> arguments differently (something more like keeping the existing
> precision argument and adding one to specify the units of measure), but
> that's a lower-level detail.

Having separate arguments allows for one to specify both, such
that the system uses the more restrictive value.  Especially when
multiple bases are allowed, that would be useful.

(Though that requires a new keyword argument for each allowed
base.  While the standard allows it, would you expect anything
other than two and ten? )

-- glen

glen herrmannsfeldt wrote:
> robin wrote:
> (snip)
> 
>> For non IEEE and double words, IBM hardware allowed
>> for hex float with 53 maximum guaranteed binary bits, hence
>> it could not "round up" to 54 because the hardware
>> could not support it.
> 
> Extended precision hardware has existed since the
> 360/85, and all 370 and later processors.
> Software emulation is used for other S/360 processors.

There was also a different extended-precision offering for the 67. It 
may have been an RPQ, and it may have been withdrawn without being 
shipped, but it did appear in at least one manual ca. 1967 (TSS/360 
Assembler Language Reference, I think).
-- 
John W. Kennedy
  "Though a Rothschild you may be
In your own capacity,
     As a Company you've come to utter sorrow--
But the Liquidators say,
'Never mind--you needn't pay,'
     So you start another company to-morrow!"
   -- Sir William S. Gilbert.  "Utopia Limited"

glen herrmannsfeldt wrote:
> Richard Maine wrote:
> (snip, someone wrote)
> 
>>>>  SELECTED_bla_KIND(DEC=dec_digits, BIN=bin_digits)
> 
> (snip)
> 
>> I'd prefer new optional arguments for the existing
>> intrinsics rather than whole new intrinsics. I'd probably factor the
>> arguments differently (something more like keeping the existing
>> precision argument and adding one to specify the units of measure), but
>> that's a lower-level detail.
> 
> 
> Having separate arguments allows for one to specify both, such
> that the system uses the more restrictive value.  Especially when
> multiple bases are allowed, that would be useful.
> 
> (Though that requires a new keyword argument for each allowed
> base.  While the standard allows it, would you expect anything
> other than two and ten? )

2 through 36 with other bases supported in software.

> 
> -- glen
> 
> 


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

glen herrmannsfeldt wrote in message ...
>robin wrote:
>(snip, I wrote)
>
>>> You also have to get functions right
>>> (REAL FUNCTION F*8(X)),
>
>> What?
>> REAL*8 FUNCTION F(X)
>> was how it was written.
>
>I don't suppose you thought about actually looking it up?

I don't suppose that you ever tried using it that way?

0005)       REAL FUNCTION G*8(X)
*** G must be followed by a dummy argument list or "()"

glen herrmannsfeldt wrote in message ...
>robin wrote:
>(snip)
>
>> For non IEEE and double words, IBM hardware allowed
>> for hex float with 53 maximum guaranteed binary bits, hence
>> it could not "round up" to 54 because the hardware
>> could not support it.
>
>Extended precision hardware has existed since the
>360/85,

But not on the S/360 series generally.

> and all 370 and later processors.

Not for division.
That was implemented in software.

>Software emulation is used for other S/360 processors.


That's not so.  And how many S/360 processors are still running?

>> But in any case PL/I compilers use whatever hardware
>> is available.  And if decimal float is available, the compiler
>> uses decimal hardware when FLOAT DECIMAL (16) is
>> specified, and binary hardware (if available) when FLOAT BINARY
>> is specified.

glen herrmannsfeldt wrote in message <5ZudnSe45MNp3vjVnZ2dnUVZ_o7inZ2d@comcast.com>...

>I read his post mostly as a request for "REAL*8" as
>a synonym for "DOUBLE PRECISION", (not counting the
>first sentence).
>
>Also, not to remove the KIND mechanism but only legitimize
>the practice used in much old code and some quickly written
>new code.  (For a simple test, the declaration might be
>more than half the program!)

It's simple enough to convert old programs.
Its easy to type DOUBLE PRECISION

glen herrmannsfeldt wrote in message ...
>Dan Nagle wrote:
>(snip)
>
>> So you want to build into the language
>> a hardware dependency for the sake of the simplest of programs?
>> That strikes me as a big step backwards
>> for the very least gain.
>
>OK, how about REAL*8 only means IEEE standard 64 bit binary
>floating point.  If a compiler doesn't support that, then
>don't support REAL*8.  (Fortran 77 compilers excepted.)

You have to be joking.

>Maybe new numbers for IEEE standard decimal float.
>
>The kind system is nice and general.  It isn't easy to
>write algorithms so general, though.
>
>For old programs, one has to verify what the programmer
>meant by REAL*8.

He meant double precision.

glen herrmannsfeldt wrote in message ...

>I meant somewhat portable.  If, for instance, one had available
>IBM mainframes and VAX (both popular at about the same time)
>REAL*8 would work on both.  The floating point range and
>precision were a little different, but the size was the same.

Why on earth would you do that, when REAL and DOUBLE PRECISION
rendered the codes completely portable.

Greg Lindahl wrote in message <486580dc$1@news.meer.net>...

>Note that the scheme that Fortran now uses was proven by PL/I to be
>capable of building in hardware dependencies for no reason --
>programmers asked for what ended up being 36 bit variables when 32
>would have worked most of the time. This code wasn't portable when
>32-bit hardware became the standard.

32-bit words were never a standard.
And even on machines having 32-bit words, one could never
specify 32-bit variables unless they were bit strings,
in which case anything from 1 to 32767 bits was typically acceptable.

Such PL/I programs as you suggest worked fine on computers having
48 and 60-bit words.
If one wanted a program to be portable, one specified
either the default precision, or specified a bit size that was
common to all or most processors.

And as for your example, PL/I runs fine with 64-bit integers.

glen herrmannsfeldt wrote in message <1aWdna1ZEL26_fTVnZ2dnUVZ_rDinZ2d@comcast.com>...
>Dan Nagle wrote:
>(snip)
>
>> And how would using integer*4 (on the 36-bit system)
>> leave me any better off?  Indeed, I think I'm hurting badly
>> with the *N approach.
>
>The DEC 36 bit compilers accept INTEGER*4, REAL*4, and REAL*8.
>(See http://www.pdpplanet.com/ to try them.)
>
>If you know where a running 7090 is I would try that.
>
>I know *4 from OS/360 Fortran IV, I don't know if it
>existed for the 7090 Fortran IV compilers.

Why not try ruinning on a present-day machine
with REAL (without the *4) and it will work fine.

And you can run the double precision things with
DOUBLE PRECISION statements
or what's appropriate.

Clive Page wrote in message ...

>Suppose your native word-length is 64-bits,
>so that REAL means 8-bytes, won't DOUBLE PRECISION mean 16-bytes?  I
>think I've used a CDC machine in the past for which that was true.   If
>that's true, then the form "DOUBLE PRECISION" is too imprecise, it means
>just "at least twice as much precision as real",

That's precisel;y what it was meant to mean, and still does.
It's not imprecise.

>I was also proposing that the whole set of word-lengths be supported,
>i.e. INTEGER*1, INTEGER*2, INTEGER*4, INTEGER*8,
>REAL*4, REAL*8, and LOGICAL*1, LOGICAL*2, LOGICAL*4, as these are all
>encountered in the wild.  I didn't mention all these because my original
>posting was already rather long.

Those are obsolete notations.

Greg Lindahl wrote in message <48653e11$1@news.meer.net>...

>In article <4865341d$0$78078$bed64819@news.gradwell.net>,
>John Appleyard  <spamtrap@polyhedron.com> wrote:
>
>>I think I agree with you Clive.   I never have liked KIND - I don't want
>>to specify the precision as such - some clever compiler writer might
>>give me *exactly* what I ask for - implemented in software.  I want a
>>clear way to pick a amongst the types that are implemented in hardware,
>>and the question I find myself asking is "how do I set the KIND
>>parameters to be absolutely sure that I will get REAL*8 or INTEGER*1 or
>>whatever?".  Where's the sense in that?
>
>And this was a known flaw -- PL/1 suffered from it.

PL/I didn't not "suffer" from it.
PL/I provides a default precision (like REAL in Fortran)
with the use of the keyword FLOAT --
that gives what is generally known as single precision.

When a declaration gives an actual precision, the hardware data type
actually used is one that exactly matches that precision, or (if there is
not one that exactly matches it) the minimum precision that exceeds that
precision is used, just as Fortran does.

In particular, if single-byte integers are requred, PL/I will give it.

If you want exactly 3-decimal digit computations, PL/I will give it.

In general, the precision can be given in terms of the number of
decimal digits desired for the calculation, e.g.,
     declare x float decimal (10);
This has some convenient properties, in that when you print the
value of X using free-format, you get exactly 10 decimal digits printed.

Richard Maine wrote in message <1ij78j4.1dfhk0x1vr8hggN%nospam@see.signature>...
>glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>
>> Dan Nagle wrote:
>> (snip)
>>
>> > So you want to build into the language
>> > a hardware dependency for the sake of the simplest of programs?
>> > That strikes me as a big step backwards
>> > for the very least gain.
>>
>> OK, how about REAL*8 only means IEEE standard 64 bit binary
>> floating point.
>...
>> For old programs, one has to verify what the programmer
>> meant by REAL*8.
>
>So you add something the only apparent benefit of which is to support
>old programs, and then you make it so that it is incompatible with old
>programs (very many of which were for systems that were not IEEE)? I
>don't think so.

It's not only just that.
It's to add something to support something that was never standard anyway.

That seems to be retrograde.

It's simple to change old programs.
REAL*8 is easily converted to "DOUBLE PRECISION"
or whatever else is appropriate.

John Appleyard wrote in message <4865341d$0$78078$bed64819@news.gradwell.net>...

>I think I agree with you Clive.   I never have liked KIND - I don't want
>to specify the precision as such - some clever compiler writer might
>give me *exactly* what I ask for - implemented in software.  I want a
>clear way to pick a amongst the types that are implemented in hardware,
>and the question I find myself asking is "how do I set the KIND
>parameters to be absolutely sure that I will get REAL*8 or INTEGER*1 or
>whatever?".

You can't.
There's no guarantee that a processor will have available
a one-byte integer.
In a word addressible machine, it's not possible.
In the past, processors have come in all shapes and sizes,
with word sizes from 12 through 60 at least.
On a 60-bit word machine, REAL*8 was meaningless.
On those machines, DOUBLE PRECISION had some meaning.

On Jun 27, 4:30=EF=BF=BDpm, Clive Page <j...@main.machine> wrote:
> I whether anyone else would agree that it =EF=BF=BDmay be time to legitimi=
se 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. =EF=BF=BDThus 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. =EF=BF=BDI have sometimes point=
ed 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. =EF=BF=BDUnfortunately the simplest change: altering
> =EF=BF=BD REAL*8 variable
> to
> =EF=BF=BD 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. =EF=BF=BDFew programmers =
that I
> know seem to be convinced that they ought to write something like
> =EF=BF=BD REAL(KIND=3DSELECTED_REAL_KIND(15,99)) variable
> because that is so cumbersome and hard to read. =EF=BF=BD(Of course you ca=
n
> 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. =EF=BF=BDI 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. =EF=BF=BDThe reader of code has to think "hmm, the f=
irst
> argument is more than seven, so the programmer probably wants IEEE
> double precision here". =EF=BF=BDThe 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. =EF=BF=BDSo there's obv=
iously
> 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

On Wed, 2 Jul 2008 02:23:08 -0700 (PDT), David Flower <DavJFlower@aol.com> wrote:
> On Jun 27, 4:30?pm, Clive Page <j...@main.machine> 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

On Jul 2, 12:33=EF=BF=BDpm, Brian Salter-Duke <b_d...@bigpond.net.invalid>
wrote:
> On Wed, 2 Jul 2008 02:23:08 -0700 (PDT), David Flower <DavJFlo...@aol.com=
> wrote:
> > On Jun 27, 4:30?pm, Clive Page <j...@main.machine> wrote:
> >> I whether anyone else would agree that it ?may be time to legitimise t=
he
> >> 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 ha=
ve
> >> written Fortran in the past on machines with word-lengths of 12-bits a=
nd
> >> 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 o=
ut
> >> to programmers who still use this notation that they really ought to u=
se
> >> 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 th=
e
> >> 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=3DSELECTED_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 chose=
n
> >> 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, thou=
gh
> >> a few emit warnings if you set the right switches. ?So there's obvious=
ly
> >> 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 tes=
t.
>
> Brian.
>
> --
> =EF=BF=BD =EF=BF=BD =EF=BF=BD Brian Salter-Duke =EF=BF=BD =EF=BF=BD =EF=
=BF=BD =EF=BF=BD =EF=BF=BDMelbourne, Australia
> =EF=BF=BD =EF=BF=BD My real address is b_duke(AT)bigpond(DOT)net(DOT)au
> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=
=BF=BDUse 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

"Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
news:HIJak.16544$IK1.4319@news-server.bigpond.net.au...

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

I see no point in perpetuating something that was non-standard.
In any case, F77 is obsolete, has been superseded by three
changes of the standard (F90, F95, and F2003).

It is trivial to change "REAL*8" to DOUBLE PRECISION
or something else.

Using a modern compiler and free source form may well show up bugs
in the code.

As well, it's possible to have dynamic arrays which make
an algorithm general.

On Fri, 04 Jul 2008 02:25:26 GMT, robin <robin_v@bigpond.com> wrote:
> "Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
> news:HIJak.16544$IK1.4319@news-server.bigpond.net.au...
>
>> 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.
>
> I see no point in perpetuating something that was non-standard.
> In any case, F77 is obsolete, has been superseded by three
> changes of the standard (F90, F95, and F2003).
>
> It is trivial to change "REAL*8" to DOUBLE PRECISION
> or something else.
>
> Using a modern compiler and free source form may well show up bugs
> in the code.
>
> As well, it's possible to have dynamic arrays which make
> an algorithm general.
>

All of this is true, but REAL*8 persists. The program Gaussian98 has
just under 6000 uses of it. I expect that the next version, which I do
not have access to, Gaussian03, has much the same or more. I do not
think that someone who is not an expert programmer is going to change
all of these to 'DOUBLE PRECISION' after paying $2000 for the code. This
program is very widely used by chemists. Some other codes are similar.
The people who support this code are too busy adding new chemistry to it
to bother with making this change.

Don't blame me. I'm just the messenger, but I do not want my fellow
chemists to find that they can not use these codes (or worse waste my
time by asking me to fix the problem).

I do not support adding it to the standard, but I do support keeping it
in all the compilers. It is still usefull.

Brian.

-- 
      Brian Salter-Duke          Melbourne, Australia
    My real address is b_duke(AT)bigpond(DOT)net(DOT)au
               Use this for reply or followup

> Not so wordy as
> 
>       INTEGER (SELECTED_INT_KIND(9)) :: I
> 
> compare to C's
> 
>       int i;

AFAICT, those two don't mean the same thing.

	Jan

On Fri, 04 Jul 2008 13:56:30 +0200, Jan Vorbr�ggen posted:

>> Not so wordy as
>> 
>>       INTEGER (SELECTED_INT_KIND(9)) :: I
>> 
>> compare to C's
>> 
>>       int i;
> 
> AFAICT, those two don't mean the same thing.

There's a case difference, but the first would declare a single precision
integer, which, I thought, had the same width as an int in C.

-- 
I never lecture, not because I am shy or a bad speaker, but simply because
I detest the sort of people who go to lectures and don't want to meet them.
H. L. Mencken

Ron Ford wrote:
> On Fri, 04 Jul 2008 13:56:30 +0200, Jan Vorbr�ggen posted:
>
>>> Not so wordy as
>>>
>>>       INTEGER (SELECTED_INT_KIND(9)) :: I
>>>
>>> compare to C's
>>>
>>>       int i;
>>
>> AFAICT, those two don't mean the same thing.
>
> There's a case difference, but the first would declare a single
> precision integer, which, I thought, had the same width as an int in
> C.

A default INTEGER is simpler to write:

   INTEGER :: I

And yes, it is usually the same as an int in C. There's a lot of
leeway in that word "usually". The correct new way to write
an INTEGER declaration in Fortran so that it's the same as C's
int is to USE the proper module and declare with the proper
KIND:

   USE ISO C BINDING, only: C_INT
   INTEGER(C_INT) :: I

On most implementations, you might just want to check whether
C_INT is the default KIND and then avoid using it.  But, that
would make you prone to portability problems.


-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

Ron Ford <ron@nowhere.net> wrote:

> On Fri, 04 Jul 2008 13:56:30 +0200, Jan Vorbr�ggen posted:
> 
> >> Not so wordy as
> >> 
> >>       INTEGER (SELECTED_INT_KIND(9)) :: I
> >> 
> >> compare to C's
> >> 
> >>       int i;
> > 
> > AFAICT, those two don't mean the same thing.
> 
> There's a case difference, but the first would declare a single precision
> integer, which, I thought, had the same width as an int in C.

No, the first does not declare a single precision integer. It declares
an integer with a range of at least 9 decimal digits. That might or
might not be a single precision one. There have been compilers where it
is (a lot of them), compilers where it isn't, and compilers where it
depends on a compiler options. As for the second, well, I refer you to
the appropriate section of the C standard (which I don't even feel like
looking up), but I assure you that it says nothing about either decimal
digits of precision or about Fortran single precision. There have been C
compilers where it does hold 9 digits of precision and C compilers where
it does not.

There is a big difference between "meaning the same thing" versus
"happening to get an equivalent result on some particular compilers, or
even a lot of compilers." The sum 2+2 gets the same result as the
product 2*2; that does not imply that multiplication and addition mean
the same thing. No, the Fortran and C forms above do not mean the same
thing. Yes, they are reasonably likely to have an equivalent result with
some compilers.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

On Fri, 4 Jul 2008 14:39:24 -0700, Richard Maine posted:

> Ron Ford <ron@nowhere.net> wrote:
> 
>> On Fri, 04 Jul 2008 13:56:30 +0200, Jan Vorbrüggen posted:
>> 
>>>> Not so wordy as
>>>> 
>>>>       INTEGER (SELECTED_INT_KIND(9)) :: I
>>>> 
>>>> compare to C's
>>>> 
>>>>       int i;
>>> 
>>> AFAICT, those two don't mean the same thing.
>> 
>> There's a case difference, but the first would declare a single precision
>> integer, which, I thought, had the same width as an int in C.
> 
> No, the first does not declare a single precision integer. It declares
> an integer with a range of at least 9 decimal digits. That might or
> might not be a single precision one. There have been compilers where it
> is (a lot of them), compilers where it isn't, and compilers where it
> depends on a compiler options. 

I find a new way to make mistakes with this material with depressing
regularity.  Usually, Glen doesn't get an assist, but I suspect he may have
fallen prey to the same mistake I did.

I was thinking of a s.r.k. that had to accomodate a billion.  Anyways, for
my machine I get with:

! from Dick Hendrickson
       program list_kinds
       do i = 1,50
         print *, i, selected_int_kind(i), selected_real_kind(i), &
& selected_real_kind(i,100)
       enddo
       end program

            1           1           1           2
            2           1           1           2
            3           2           1           2
            4           2           1           2
            5           3           1           2
            6           3           1           2
            7           3           2           2
            8           3           2           2
            9           3           2           2
           10           4           2           2
           11           4           2           2
           12           4           2           2
           13           4           2           2
           14           4           2           2
           15           4           2           2
           16           4           3           3
           17           4           3           3
           18           4           3           3
           19          -1          -1          -1
           20          -1          -1          -1
           21          -1          -1          -1


> As for the second, well, I refer you to
> the appropriate section of the C standard (which I don't even feel like
> looking up), but I assure you that it says nothing about either decimal
> digits of precision or about Fortran single precision. There have been C
> compilers where it does hold 9 digits of precision and C compilers where
> it does not.


I'm downloading FX's gfortran and have time to look at standards.  The
*only* mention of fortran in the C standard is that it is a common
extension.  I pulled this out of n1256.pdf:

A ‘‘plain’’ int object has the natural size suggested by the
architecture of the execution environment (large enough to contain any
value in the range
INT_MIN to INT_MAX as defined in the header <limits.h>).

and

—minimum value for an object of type int
INT_MIN -32767 // -(2 15
- 1)
—maximum value for an object of type int
INT_MAX +32767 // 2 15
- 1

I would say this is highly suggestive that C ints would be at least 16
bits.  I don't doubt that they could also be 47 bits.  Much of the
flexibility in C is lost on my 2**n-bit self.

> There is a big difference between "meaning the same thing" versus
> "happening to get an equivalent result on some particular compilers, or
> even a lot of compilers." The sum 2+2 gets the same result as the
> product 2*2; that does not imply that multiplication and addition mean
> the same thing. No, the Fortran and C forms above do not mean the same
> thing. Yes, they are reasonably likely to have an equivalent result with
> some compilers.

I sometimes exhibit the myopia that comes from having had only one machine.
I'm pleased now to have a fortran capability that runs off a memory stick.
We'll see how results differ when I use my girlfriend's laptop.
-- 
Alimony - the ransom that the happy pay to the devil.
H. L. Mencken

"Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
news:ynlbk.16969$IK1.5922@news-server.bigpond.net.au...
> On Fri, 04 Jul 2008 02:25:26 GMT, robin <robin_v@bigpond.com> wrote:
> > "Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
> > news:HIJak.16544$IK1.4319@news-server.bigpond.net.au...
> >
> >> 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.
> >
> > I see no point in perpetuating something that was non-standard.
> > In any case, F77 is obsolete, has been superseded by three
> > changes of the standard (F90, F95, and F2003).
> >
> > It is trivial to change "REAL*8" to DOUBLE PRECISION
> > or something else.
> >
> > Using a modern compiler and free source form may well show up bugs
> > in the code.
> >
> > As well, it's possible to have dynamic arrays which make
> > an algorithm general.
>
> All of this is true, but REAL*8 persists. The program Gaussian98 has
> just under 6000 uses of it. I expect that the next version, which I do
> not have access to, Gaussian03, has much the same or more. I do not
> think that someone who is not an expert programmer is going to change
> all of these to 'DOUBLE PRECISION' after paying $2000 for the code.

It  seems that the distribution of Gaussian03 is by EXE code only.

On Fri, 04 Jul 2008 21:18:17 GMT, James Giles posted:

> Ron Ford wrote:
>> On Fri, 04 Jul 2008 13:56:30 +0200, Jan Vorbr�ggen posted:
>>
>>>> Not so wordy as
>>>>
>>>>       INTEGER (SELECTED_INT_KIND(9)) :: I
>>>>
>>>> compare to C's
>>>>
>>>>       int i;
>>>
>>> AFAICT, those two don't mean the same thing.
>>
>> There's a case difference, but the first would declare a single
>> precision integer, which, I thought, had the same width as an int in
>> C.
> 
> A default INTEGER is simpler to write:
> 
>    INTEGER :: I
> 
> And yes, it is usually the same as an int in C. There's a lot of
> leeway in that word "usually". The correct new way to write
> an INTEGER declaration in Fortran so that it's the same as C's
> int is to USE the proper module and declare with the proper
> KIND:
> 
>    USE ISO C BINDING, only: C_INT
>    INTEGER(C_INT) :: I
> 

Of course, you need the underscores for the module:

program debug1   
USE ISO_C_BINDING, only: C_INT

INTEGER(C_INT) :: I

INTEGER :: J

I = 41
J = 42

PRINT *, I, J

end program debug1
! gfortran -o debug1 debug1.f03

> On most implementations, you might just want to check whether
> C_INT is the default KIND and then avoid using it.  But, that
> would make you prone to portability problems.

How do you do that?  What I usually do to see what a machine gives me is to
step through something like the above.  Now that the interesting programs
are beyond f95, I find myself without my usual debuggers.  Can a person
walk through the above with gdb?

Happy fourth.  I'm overdue for a beer.
-- 
Every election is a sort of advance auction sale of stolen goods.
H. L. Mencken

On Fri, 04 Jul 2008 23:23:36 GMT, robin <robin_v@bigpond.com> wrote:
> "Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
> news:ynlbk.16969$IK1.5922@news-server.bigpond.net.au...
>> On Fri, 04 Jul 2008 02:25:26 GMT, robin <robin_v@bigpond.com> wrote:
>> > "Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
>> > news:HIJak.16544$IK1.4319@news-server.bigpond.net.au...
>> >
>> >> 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.
>> >
>> > I see no point in perpetuating something that was non-standard.
>> > In any case, F77 is obsolete, has been superseded by three
>> > changes of the standard (F90, F95, and F2003).
>> >
>> > It is trivial to change "REAL*8" to DOUBLE PRECISION
>> > or something else.
>> >
>> > Using a modern compiler and free source form may well show up bugs
>> > in the code.
>> >
>> > As well, it's possible to have dynamic arrays which make
>> > an algorithm general.
>>
>> All of this is true, but REAL*8 persists. The program Gaussian98 has
>> just under 6000 uses of it. I expect that the next version, which I do
>> not have access to, Gaussian03, has much the same or more. I do not
>> think that someone who is not an expert programmer is going to change
>> all of these to 'DOUBLE PRECISION' after paying $2000 for the code.
>
> It  seems that the distribution of Gaussian03 is by EXE code only.

No, source code is available. An academic site license is $4500. A
single machine license is $2000. See:-

http://www.gaussian.com/g_pricing/g03p_a.htm

They will not distribute source code to anybody who they deem to be a
competitor or even someone who works at a university that has a
competitor on staff. That is another story. Search for "banned by
Gaussian".

I have written a new module that interfaces to Gaussian. I get it
compiled at our Supecomputer Centre but I can not see the source code. I
still have the source code for Gaussian98.

Back with Gaussian98, they only distributed source code. I would not be
surprised to find that you are right for the next release and that only
exes are released. 

Brian.

-- 
      Brian Salter-Duke          Melbourne, Australia
    My real address is b_duke(AT)bigpond(DOT)net(DOT)au
               Use this for reply or followup

Hello,

On 2008-07-04 19:25:29 -0400, Ron Ford <ron@nowhere.net> said:

> 
> How do you do that?

kind( foo) == kind( bar)

or print them.

-- 
Cheers!

Dan Nagle

On Fri, 04 Jul 2008 23:48:40 GMT, Dan Nagle posted:

> Hello,
> 
> On 2008-07-04 19:25:29 -0400, Ron Ford <ron@nowhere.net> said:
> 
>> 
>> How do you do that?
> 
> kind( foo) == kind( bar)
> 
> or print them.

Nuts, Dan.  I've been trying to look at the objects you describe above
without success.  You use metasyntactics, and me, I'm trying to walk
through the world's easiest fortran program:

program debug1   
USE ISO_C_BINDING, only: C_INT

INTEGER(C_INT) :: I

INTEGER :: J

I = 41
J = 42

PRINT *, I, J

end program debug1
! gfortran -o debug1 -g debug1.f03

The site I was looking at for this endeavor:
http://infohost.nmt.edu/tcc/help/lang/fortran/gdb.html , where I took 
 f77 -g foo.f -o foo
to be my goocher comment that follows main.

I can't step through with any of of the following: 
 break main
        run

step

quit

With Dan being a very popular guy in the fortran community right now, I
thought he might want to comment on a problem *in* fortran as opposed to
one *with* fortran.
-- 
The only cure for contempt is counter-contempt.
H. L. Mencken

On 2008-07-06 01:51:45 -0400, Ron Ford <ron@nowhere.net> said:

> Nuts, Dan.  I've been trying to look at the objects you describe above
> without success.  You use metasyntactics, and me, I'm trying to walk
> through the world's easiest fortran program:
> 
> program debug1
> USE ISO_C_BINDING, only: C_INT
> 
> INTEGER(C_INT) :: I
> 
> INTEGER :: J
> 
> I = 41
> J = 42
> 
> PRINT *, I, J

why not print kind(0), c_int ?

> 
> end program debug1

> -- 
Cheers!

Dan Nagle

robin wrote:
> glen herrmannsfeldt wrote in message ...

>>robin wrote:
>>(snip)

>>>For non IEEE and double words, IBM hardware allowed
>>>for hex float with 53 maximum guaranteed binary bits, hence
>>>it could not "round up" to 54 because the hardware
>>>could not support it.

>>Extended precision hardware has existed since the
>>360/85,

> But not on the S/360 series generally.

No, but they supplied an emulator.

The original comment applies to the Optimizing compiler
and later ones.  (F) didn't support extended precision.

The rule for precision is supposed to be CEIL(3.32*p) but
in the case I mentioned, they modified it slightly.

>>and all 370 and later processors.

> Not for division.
> That was implemented in software.

There is an IBM Systems Journal article on extended
precision.  IBM did the study showing that the demand
for DXR was low enough that software was the best way.

Somewhat late in ESA/390 it was finally added.

>>Software emulation is used for other S/360 processors.

> That's not so.  And how many S/360 processors are still running?

Are you complaining about my use of the present tense?

I usually use present tense describing an architecture, which
exists whether or not any implementations of it exist.  Support
for instructions exist even when the machine isn't running.

>>>But in any case PL/I compilers use whatever hardware
>>>is available.  And if decimal float is available, the compiler
>>>uses decimal hardware when FLOAT DECIMAL (16) is
>>>specified, and binary hardware (if available) when FLOAT BINARY
>>>is specified.

It seems to me that, especially for floating point, the
DECIMAL attribute is meant more to indicate specifying
precision in decimal digits than to specify float decimal
hardware.  That is less true in fixed point, where scaling may
require multiply or divide by powers of ten, which is easier
in decimal arithmetic.   I do know at least one IBM compiler
that implements FIXED DECIMAL in binary.

-- glen

robin wrote:
(snip)

>>>REAL*8 FUNCTION F(X)
>>>was how it was written.

>>I don't suppose you thought about actually looking it up?

> I don't suppose that you ever tried using it that way?

> 0005)       REAL FUNCTION G*8(X)
> *** G must be followed by a dummy argument list or "()"

Try it on TOPS-10 Fortran, as I did before posting that.
Or on an IBM compiler, where the notation originated.

-- glen

"Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
news:Nxybk.17180$IK1.4437@news-server.bigpond.net.au...
> On Fri, 04 Jul 2008 23:23:36 GMT, robin <robin_v@bigpond.com> wrote:
> > "Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
> > news:ynlbk.16969$IK1.5922@news-server.bigpond.net.au...
> >> On Fri, 04 Jul 2008 02:25:26 GMT, robin <robin_v@bigpond.com> wrote:
> >> > "Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
> >> > news:HIJak.16544$IK1.4319@news-server.bigpond.net.au...
> >> >
> >> >> 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.
> >> >
> >> > I see no point in perpetuating something that was non-standard.
> >> > In any case, F77 is obsolete, has been superseded by three
> >> > changes of the standard (F90, F95, and F2003).
> >> >
> >> > It is trivial to change "REAL*8" to DOUBLE PRECISION
> >> > or something else.
> >> >
> >> > Using a modern compiler and free source form may well show up bugs
> >> > in the code.
> >> >
> >> > As well, it's possible to have dynamic arrays which make
> >> > an algorithm general.
> >>
> >> All of this is true, but REAL*8 persists. The program Gaussian98 has
> >> just under 6000 uses of it. I expect that the next version, which I do
> >> not have access to, Gaussian03, has much the same or more. I do not
> >> think that someone who is not an expert programmer is going to change
> >> all of these to 'DOUBLE PRECISION' after paying $2000 for the code.
> >
> > It  seems that the distribution of Gaussian03 is by EXE code only.
>
> No, source code is available. An academic site license is $4500. A
> single machine license is $2000. See:-
>
> http://www.gaussian.com/g_pricing/g03p_a.htm
>
> They will not distribute source code to anybody who they deem to be a
> competitor or even someone who works at a university that has a
> competitor on staff. That is another story. Search for "banned by
> Gaussian".
>
> I have written a new module that interfaces to Gaussian. I get it
> compiled at our Supecomputer Centre but I can not see the source code. I
> still have the source code for Gaussian98.
>
> Back with Gaussian98, they only distributed source code. I would not be
> surprised to find that you are right for the next release and that only
> exes are released.

Only EXE code was listed as available on the home site.

Regardless of whether it is or is not available,
it's trivial to change REAL*8 to DOUBLE PRECISION
or some other equivalent form that's standard.

glen herrmannsfeldt wrote:
> robin wrote:
>> glen herrmannsfeldt wrote in message ...
> 
>>> robin wrote:
>>> (snip)
> 
>>>> For non IEEE and double words, IBM hardware allowed
>>>> for hex float with 53 maximum guaranteed binary bits, hence
>>>> it could not "round up" to 54 because the hardware
>>>> could not support it.
> 
>>> Extended precision hardware has existed since the
>>> 360/85,
> 
>> But not on the S/360 series generally.
> 
> No, but they supplied an emulator.
> 
> The original comment applies to the Optimizing compiler
> and later ones.  (F) didn't support extended precision.
> 
> The rule for precision is supposed to be CEIL(3.32*p) but
> in the case I mentioned, they modified it slightly.
> 
>>> and all 370 and later processors.
> 
>> Not for division.
>> That was implemented in software.
> 
> There is an IBM Systems Journal article on extended
> precision.  IBM did the study showing that the demand
> for DXR was low enough that software was the best way.
> 
> Somewhat late in ESA/390 it was finally added.
> 
>>> Software emulation is used for other S/360 processors.
> 
>> That's not so.  And how many S/360 processors are still running?
> 
> Are you complaining about my use of the present tense?
> 
> I usually use present tense describing an architecture, which
> exists whether or not any implementations of it exist.  Support
> for instructions exist even when the machine isn't running.
> 
>>>> But in any case PL/I compilers use whatever hardware
>>>> is available.  And if decimal float is available, the compiler
>>>> uses decimal hardware when FLOAT DECIMAL (16) is
>>>> specified, and binary hardware (if available) when FLOAT BINARY
>>>> is specified.
> 
> It seems to me that, especially for floating point, the
> DECIMAL attribute is meant more to indicate specifying
> precision in decimal digits than to specify float decimal
> hardware.  That is less true in fixed point, where scaling may
> require multiply or divide by powers of ten, which is easier
> in decimal arithmetic.   I do know at least one IBM compiler
> that implements FIXED DECIMAL in binary.

But it is only very recently that hardware implementing both float 
binary and float decimal came into existence. It's putting pressure on 
/all/ languages, although it will probably not become critical until 
Intel does it, which they seem disinclined to do at present. In the 
meantime, in what is probably the most important hardware that does both 
and that also has an important PL/I compiler, IBM /is/ implementing 
FLOAT DECIMAL and FLOAT BINARY as separate hardware types.

-- 
John W. Kennedy
  "There are those who argue that everything breaks even in this old 
dump of a world of ours. I suppose these ginks who argue that way hold 
that because the rich man gets ice in the summer and the poor man gets 
it in the winter things are breaking even for both. Maybe so, but I'll 
swear I can't see it that way."
   -- The last words of Bat Masterson

robin wrote:
(snip)

> Regardless of whether it is or is not available,
> it's trivial to change REAL*8 to DOUBLE PRECISION
> or some other equivalent form that's standard.

Not quite trivial, but not so hard, either.

-- glen

On Fri, 18 Jul 2008 11:54:30 GMT, robin <robin_v@bigpond.com> wrote:
> "Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
> news:Nxybk.17180$IK1.4437@news-server.bigpond.net.au...
>> On Fri, 04 Jul 2008 23:23:36 GMT, robin <robin_v@bigpond.com> wrote:
>> > "Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
>> > news:ynlbk.16969$IK1.5922@news-server.bigpond.net.au...
>> >> On Fri, 04 Jul 2008 02:25:26 GMT, robin <robin_v@bigpond.com> wrote:
>> >> > "Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
>> >> > news:HIJak.16544$IK1.4319@news-server.bigpond.net.au...
>> >> >
>> >> >> 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.
>> >> >
>> >> > I see no point in perpetuating something that was non-standard.
>> >> > In any case, F77 is obsolete, has been superseded by three
>> >> > changes of the standard (F90, F95, and F2003).
>> >> >
>> >> > It is trivial to change "REAL*8" to DOUBLE PRECISION
>> >> > or something else.
>> >> >
>> >> > Using a modern compiler and free source form may well show up bugs
>> >> > in the code.
>> >> >
>> >> > As well, it's possible to have dynamic arrays which make
>> >> > an algorithm general.
>> >>
>> >> All of this is true, but REAL*8 persists. The program Gaussian98 has
>> >> just under 6000 uses of it. I expect that the next version, which I do
>> >> not have access to, Gaussian03, has much the same or more. I do not
>> >> think that someone who is not an expert programmer is going to change
>> >> all of these to 'DOUBLE PRECISION' after paying $2000 for the code.
>> >
>> > It  seems that the distribution of Gaussian03 is by EXE code only.
>>
>> No, source code is available. An academic site license is $4500. A
>> single machine license is $2000. See:-
>>
>> http://www.gaussian.com/g_pricing/g03p_a.htm
>>
>> They will not distribute source code to anybody who they deem to be a
>> competitor or even someone who works at a university that has a
>> competitor on staff. That is another story. Search for "banned by
>> Gaussian".
>>
>> I have written a new module that interfaces to Gaussian. I get it
>> compiled at our Supecomputer Centre but I can not see the source code. I
>> still have the source code for Gaussian98.
>>
>> Back with Gaussian98, they only distributed source code. I would not be
>> surprised to find that you are right for the next release and that only
>> exes are released.
>
> Only EXE code was listed as available on the home site.

Eh? I gave you the Gaussian home site page above that says source code
is available.

> Regardless of whether it is or is not available,
> it's trivial to change REAL*8 to DOUBLE PRECISION
> or some other equivalent form that's standard.

It is not that trivial for a program the size of Gaussian and one that
is split into several dozen separate source files. It would be tedious
to check that making that change has not extended a line beyond 72
characters, Remember it is still f77 code even if it is compliled these
days by more modern compilers. Indeed I am quite sure it would extend
the line to be too long in hundreds of cases. Actually it might well do
it in all 6000 cases of REAL*8 occuring.  The change has already been
made in some codes such as GAMESS(US), but there are lots of other very
long f77 scientific programs out there still in very wide use.

As I indicated earlier I do not support changing the standard, but I do
support keeping compilers backwardly compatable with F77 and allowing
REAL*8.

I get the impression that those who are developing new versions of
Fortran, while doing a great and necessary job, do not fully understand
the problems of maintaining very large scientific programs.

Brian.

-- 
      Brian Salter-Duke          Melbourne, Australia
    My real address is b_duke(AT)bigpond(DOT)net(DOT)au
               Use this for reply or followup
   "A good programmer can write Fortran in any language"

Brian Salter-Duke wrote:
....
> It is not that trivial for a program the size of Gaussian and one that
> is split into several dozen separate source files. It would be tedious
> to check that making that change has not extended a line beyond 72
> characters, Remember it is still f77 code even if it is compliled
> these days by more modern compilers. Indeed I am quite sure it would
> extend the line to be too long in hundreds of cases. Actually it
> might well do it in all 6000 cases of REAL*8 occuring.  The change
> has already been made in some codes such as GAMESS(US), but there are
> lots of other very long f77 scientific programs out there still in
> very wide use.

Any line that such processing causes to extend beyond the 72
column limit may be made into a continuation:

      REAL*8 abc, def, ..., xyz

becomes:

      REAL(dp) :: abc, def, ... pqr,
     & stu, vw, xyz

If the line was already continued, this doesn't change the meaning
of any of the following continuation lines.  Nor does it send you
past the continuation limit: prior to F2003, the limit was 19 continuations
(for a maximum of 20 lines in a statement), since then the limit
has been 255 continuations (for a maximum of 256 lines in a
statement).  The automatic conversion leaves code that still
conforms - even under fixed source form rules.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

Brian Salter-Duke wrote:
> ...
> I get the impression that those who are developing new versions of
> Fortran, while doing a great and necessary job, do not fully understand
> the problems of maintaining very large scientific programs.

What is amazing to me is that some folks remain so mired in F77 that
they cannot see the light.  Many of the improvements in F90 are directed
specifically at those who have to maintain, and enhance, very large
scientific programs.  REAL*8 is a nit compared to other issues.

W.

Ron Ford wrote:
(snip, I wrote)

>>>>>      INTEGER (SELECTED_INT_KIND(9)) :: I

>>>>>compare to C's

>>>>>      int i;
(snip)

> I find a new way to make mistakes with this material with depressing
> regularity.  Usually, Glen doesn't get an assist, but I suspect he may have
> fallen prey to the same mistake I did.

There is a fair amount of C code that assumes a 32 bit int, and
much that assumes a 32 bit long.  In any case, yes, they are not
equivalent, but the point that I was trying to make was that one
was much more verbose than the other.   I suppose I should have
said Java, which defines int as 32 bits.

-- glen

John W Kennedy wrote:
(snip)

> But it is only very recently that hardware implementing both float 
> binary and float decimal came into existence. It's putting pressure on 
> /all/ languages, although it will probably not become critical until 
> Intel does it, which they seem disinclined to do at present. In the 
> meantime, in what is probably the most important hardware that does both 
> and that also has an important PL/I compiler, IBM /is/ implementing 
> FLOAT DECIMAL and FLOAT BINARY as separate hardware types.

Yes, it is very convenient of PL/I to have this distinction.

It might be that IBM was planning 40 years ahead for z/Architecture
and float decimal hardware.  I have old versions of the language
reference.  (The one that is supposed to be compiler independent.)

Around 1977 I was told that the CDC STAR-100 had float decimal, but
that turned out to be wrong.

-- glen

James Giles wrote:
(snip)

> Any line that such processing causes to extend beyond the 72
> column limit may be made into a continuation:

>       REAL*8 abc, def, ..., xyz

> becomes:

>       REAL(dp) :: abc, def, ... pqr,
>      & stu, vw, xyz

> If the line was already continued, this doesn't change the meaning
> of any of the following continuation lines.  Nor does it send you
> past the continuation limit: prior to F2003, the limit was 19 continuations
> (for a maximum of 20 lines in a statement), since then the limit
> has been 255 continuations (for a maximum of 256 lines in a
> statement).  The automatic conversion leaves code that still
> conforms - even under fixed source form rules.

As previously discussed there are also

       REAL A, B, C*8

and

       REAL FUNCTION F*8(X)

forms.

Most likely less common than ordinary REAL*8, though.
Still, a conversion program should get them right.

Also, the IBM compilers allow initialization:

       REAL*8 A,B,C/1.,2.,3./

-- glen

On Fri, 18 Jul 2008 17:35:03 -0700, 
Walter Spector <w6ws_xthisoutx@earthlink.net> wrote:
> Brian Salter-Duke wrote:
>> ...
>> I get the impression that those who are developing new versions of
>> Fortran, while doing a great and necessary job, do not fully understand
>> the problems of maintaining very large scientific programs.
>
> What is amazing to me is that some folks remain so mired in F77 that
> they cannot see the light.  Many of the improvements in F90 are directed
> specifically at those who have to maintain, and enhance, very large
> scientific programs.  REAL*8 is a nit compared to other issues.

Well you could be right. However, I think those people who look after
large scientific codes are mostly trying to add new features while
ensuring they can be compiled with all existing compilers that have been
used previously. These code writers have many other responsibilities in
most cases. My own involvement is with a relatively small computational
chemistry code that can either stand alone or interface to GAMESS(US) or
Gaussian. So I see some of the issues from outside but close and some
from a smaller piece of code. I am far too busy to work on upgrading the
code to F90 or more recent. I also think it would cause more problems
than it would solve. I also find it interesting that when people do
decide to write a new piece of code in my area, they do not choose
Fortran. They choose C and/or C++.

Brian.

> W.


-- 
      Brian Salter-Duke          Melbourne, Australia
    My real address is b_duke(AT)bigpond(DOT)net(DOT)au
               Use this for reply or followup
   "A good programmer can write Fortran in any language"

glen herrmannsfeldt wrote:
....
> As previously discussed there are also
>
>       REAL A, B, C*8
>
> and
>
>       REAL FUNCTION F*8(X)
>
> forms.
>
> Most likely less common than ordinary REAL*8, though.
> Still, a conversion program should get them right.

It wouldn't be hard.  But I'd rather see evidence that anyone
still has *real* legacy code that uses them.  They wouldn't
have ever been portable.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

Brian Salter-Duke wrote:
> ... I think those people who look after
> large scientific codes are mostly trying to add new features while
> ensuring they can be compiled with all existing compilers that have been
> used previously.

It is now mid-2008.  Any modern compiler supports F95, and has for
some years.  Some vendors phased out their F77 compilers over 10
years ago.  No need to support a seperate F77 compiler as, modulo
a very few minor issues, F77 is a subset of F90.

 > These code writers have many other responsibilities in
> most cases. My own involvement is with a relatively small computational
> chemistry code that can either stand alone or interface to GAMESS(US) or
> Gaussian. So I see some of the issues from outside but close and some
> from a smaller piece of code. I am far too busy to work on upgrading the
> code to F90 or more recent. I also think it would cause more problems
> than it would solve.

Why would it cause more problems that it would solve?

> I also find it interesting that when people do
> decide to write a new piece of code in my area, they do not choose
> Fortran. They choose C and/or C++.

Given the choice of F77 or C++, I would take C++ any day.

W.

Walter Spector <w6ws_xthisoutx@earthlink.net> wrote:

> Brian Salter-Duke wrote:

> > I also find it interesting that when people do
> > decide to write a new piece of code in my area, they do not choose
> > Fortran. They choose C and/or C++.
> 
> Given the choice of F77 or C++, I would take C++ any day.

Which might also explain Brian's observation, if "Fortran" to the people
in his area means f77. I suppose that was exactly your point. I know
that I was in a simillar quandry in about 1990 when I started on a major
new project and concluded that, in spite of my extensive experience with
f77, it just wasn't going to be an acceptable choice for the new
project.

The two big drivers to me were data structures and dynamic allocation.
The new project was going to involve a lot of both of those. Yes, I know
you can "fake it" in f77, particularly if you aren't too picky about
sticking to the standard, but those hacks just weren't going to be
acceptable to me. It didn't take too much for me to conclude that the
other language choices readily available to me weren't going to be
acceptable either. That's when I took the risk of starting the project
in f90, even though I didn't yet have an f90 compiler (nor did anyone
else). I concluded that the choices were either that or for me to
abandon the project. I just wasn't willing to do it in f77 or C (or Ada,
which I also looked at).

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

On Fri, 18 Jul 2008 20:06:21 -0700, Walter Spector <w6ws_xthisoutx@earthlink.net> wrote:
> Brian Salter-Duke wrote:
>> ... I think those people who look after
>> large scientific codes are mostly trying to add new features while
>> ensuring they can be compiled with all existing compilers that have been
>> used previously.
>
> It is now mid-2008.  Any modern compiler supports F95, and has for
> some years.  Some vendors phased out their F77 compilers over 10
> years ago.  No need to support a seperate F77 compiler as, modulo
> a very few minor issues, F77 is a subset of F90.
>
> > These code writers have many other responsibilities in
>> most cases. My own involvement is with a relatively small computational
>> chemistry code that can either stand alone or interface to GAMESS(US) or
>> Gaussian. So I see some of the issues from outside but close and some
>> from a smaller piece of code. I am far too busy to work on upgrading the
>> code to F90 or more recent. I also think it would cause more problems
>> than it would solve.
>
> Why would it cause more problems that it would solve?

First, it is highly likely that in doing the upgrade I would introduce
bugs, given that my experience with F77 is so much greater than that of
F90 and more recent. Second, since my code has to interface with other
codes and they are not likely to move away from f77 for a while, this
would likely introduce bugs or problems. A lot of the code is COMMON
areas in my code being the same as those in say GAMESS.

>> I also find it interesting that when people do decide to write a new
>> piece of code in my area, they do not choose Fortran. They choose C
>> and/or C++.

> Given the choice of F77 or C++, I would take C++ any day.

But the choice is between F90 or F95 or whatever and C++ as Richard
points out in his comment. Authors are not chosing more recent Fortran
versions for computational chemistry code as far as I can see. They are
doing that for a reason.

Brian.

> W.
>


-- 
      Brian Salter-Duke          Melbourne, Australia
    My real address is b_duke(AT)bigpond(DOT)net(DOT)au
               Use this for reply or followup
   "A good programmer can write Fortran in any language"

On 19 juil, 06:34, Brian Salter-Duke <b_d...@bigpond.net.invalid>
wrote:
> On Fri, 18 Jul 2008 20:06:21 -0700, Walter Spector <w6ws_xthiso...@earthlink.net> wrote:
> > Brian Salter-Duke wrote:
> >> ... I think those people who look after
> >> large scientific codes are mostly trying to add new features while
> >> ensuring they can be compiled with all existing compilers that have been
> >> used previously.
>
> > It is now mid-2008.  Any modern compiler supports F95, and has for
> > some years.  Some vendors phased out their F77 compilers over 10
> > years ago.  No need to support a seperate F77 compiler as, modulo
> > a very few minor issues, F77 is a subset of F90.
>
> > > These code writers have many other responsibilities in
> >> most cases. My own involvement is with a relatively small computational
> >> chemistry code that can either stand alone or interface to GAMESS(US) or
> >> Gaussian. So I see some of the issues from outside but close and some
> >> from a smaller piece of code. I am far too busy to work on upgrading the
> >> code to F90 or more recent. I also think it would cause more problems
> >> than it would solve.
>
> > Why would it cause more problems that it would solve?
>
> First, it is highly likely that in doing the upgrade I would introduce
> bugs, given that my experience with F77 is so much greater than that of
> F90 and more recent.

No : this is wrong. My experience shows (and like you I had a large
experience with F77) that the F95 programming is safer than the F77
one if you apply the F95 style (routines within modules and accessible
only via a USE statement). This is simply because the F95 compilers
are able to check the programming in a much more efficient way.

If you impose in addition F2003 rules (trying to allocate only
allocatable arrays and to use pointer just to point to a memory area
already allocated), then you also avoid most of the bugs connected to
dynamic allocation and, for instance, very difficult to find in C or C+
+ programming.

> Second, since my code has to interface with other
> codes and they are not likely to move away from f77 for a while, this
> would likely introduce bugs or problems. A lot of the code is COMMON
> areas in my code being the same as those in say GAMESS.

COMMONs remain available with any FORTRAN version. And the "rules" I
proposed before do not concern data management.

>
> >> I also find it interesting that when people do decide to write a new
> >> piece of code in my area, they do not choose Fortran. They choose C
> >> and/or C++.
> > Given the choice of F77 or C++, I would take C++ any day.
>
> But the choice is between F90 or F95 or whatever and C++ as Richard
> points out in his comment. Authors are not chosing more recent Fortran
> versions for computational chemistry code as far as I can see. They are
> doing that for a reason.

The only reason I see is the school ! Young people do not learn
FORTRAN at school anymore. And the C syntax is the norm today (C, C++,
JAVA, C#).

>
> Brian.
>
> > W.
>
> --
>       Brian Salter-Duke          Melbourne, Australia
>     My real address is b_duke(AT)bigpond(DOT)net(DOT)au
>                Use this for reply or followup
>    "A good programmer can write Fortran in any language"

On Sat, 19 Jul 2008 01:30:48 -0700 (PDT), fj <francois.jacq@irsn.fr> wrote:
> On 19 juil, 06:34, Brian Salter-Duke <b_d...@bigpond.net.invalid>
> wrote:
>> On Fri, 18 Jul 2008 20:06:21 -0700, Walter Spector <w6ws_xthiso...@earthlink.net> wrote:
>> > Brian Salter-Duke wrote:
>> >> ... I think those people who look after
>> >> large scientific codes are mostly trying to add new features while
>> >> ensuring they can be compiled with all existing compilers that have been
>> >> used previously.
>>
>> > It is now mid-2008.  Any modern compiler supports F95, and has for
>> > some years.  Some vendors phased out their F77 compilers over 10
>> > years ago.  No need to support a seperate F77 compiler as, modulo
>> > a very few minor issues, F77 is a subset of F90.
>>
>> > > These code writers have many other responsibilities in
>> >> most cases. My own involvement is with a relatively small computational
>> >> chemistry code that can either stand alone or interface to GAMESS(US) or
>> >> Gaussian. So I see some of the issues from outside but close and some
>> >> from a smaller piece of code. I am far too busy to work on upgrading the
>> >> code to F90 or more recent. I also think it would cause more problems
>> >> than it would solve.
>>
>> > Why would it cause more problems that it would solve?
>>
>> First, it is highly likely that in doing the upgrade I would introduce
>> bugs, given that my experience with F77 is so much greater than that of
>> F90 and more recent.
>
> No : this is wrong. My experience shows (and like you I had a large
> experience with F77) that the F95 programming is safer than the F77
> one if you apply the F95 style (routines within modules and accessible
> only via a USE statement). This is simply because the F95 compilers
> are able to check the programming in a much more efficient way.

You could well be right in what you say, but I was not talking about
writing code from scratch. I was talking about rewriting existing code.
Then "if it ain't broke, don't fix it". If it works, any change has the
chance of stopping it working.

> If you impose in addition F2003 rules (trying to allocate only
> allocatable arrays and to use pointer just to point to a memory area
> already allocated), then you also avoid most of the bugs connected to
> dynamic allocation and, for instance, very difficult to find in C or C+
> + programming.
>
>> Second, since my code has to interface with other
>> codes and they are not likely to move away from f77 for a while, this
>> would likely introduce bugs or problems. A lot of the code is COMMON
>> areas in my code being the same as those in say GAMESS.
>
> COMMONs remain available with any FORTRAN version. And the "rules" I
> proposed before do not concern data management.
>
>>
>> >> I also find it interesting that when people do decide to write a new
>> >> piece of code in my area, they do not choose Fortran. They choose C
>> >> and/or C++.
>> > Given the choice of F77 or C++, I would take C++ any day.
>>
>> But the choice is between F90 or F95 or whatever and C++ as Richard
>> points out in his comment. Authors are not chosing more recent Fortran
>> versions for computational chemistry code as far as I can see. They are
>> doing that for a reason.
>
> The only reason I see is the school ! Young people do not learn
> FORTRAN at school anymore. And the C syntax is the norm today (C, C++,
> JAVA, C#).

No, the authors of at least two major comp chem codes in C/C++ were well
versed in Fortran 77 to my knowledge.

I did not learn Fortran at uni. It was my 4th language after Mercury
autocode, Elliot autocode and Algol60. I moved over to Fortran because of
the mass of existing code and that remains the situation.

>>
>> Brian.
>>
>> > W.
>>
>> --
>>       Brian Salter-Duke          Melbourne, Australia
>>     My real address is b_duke(AT)bigpond(DOT)net(DOT)au
>>                Use this for reply or followup
>>    "A good programmer can write Fortran in any language"
>


-- 
      Brian Salter-Duke          Melbourne, Australia
    My real address is b_duke(AT)bigpond(DOT)net(DOT)au
               Use this for reply or followup
   "A good programmer can write Fortran in any language"

On 2008-07-19, Brian Salter-Duke <b_duke@bigpond.net.invalid> wrote:
> On Sat, 19 Jul 2008 01:30:48 -0700 (PDT), fj <francois.jacq@irsn.fr> wrote:
>> No : this is wrong. My experience shows (and like you I had a large
>> experience with F77) that the F95 programming is safer than the F77
>> one if you apply the F95 style (routines within modules and accessible
>> only via a USE statement). This is simply because the F95 compilers
>> are able to check the programming in a much more efficient way.
>
> You could well be right in what you say, but I was not talking about
> writing code from scratch. I was talking about rewriting existing code.
> Then "if it ain't broke, don't fix it". If it works, any change has the
> chance of stopping it working.

I'm sure fj didn't mean that you should scrap your current code and
rewrite it. E.g. converting from fixed to free source form with one of
the freely available converters would be very little work, and would fix
many issues with F77 syntax. Converting (not rewriting) to a "modern
Fortran" style would bring many other improvements, but it would
certainly be a fair amount of work. 

In the end, IMHO "if it ain't broke, don't fix it" is a bit too black
and white. Sure, it compiles, it runs, but does it produce correct
results? How much do you trust it? Now obviously I'm not claiming that a
modern Fortran style would fix all such bugs (far from it!), but it does
plug SOME of the common F77 bug-prone features.


-- 
JayBee

glen herrmannsfeldt wrote:
> John W Kennedy wrote:
> (snip)
> 
>> But it is only very recently that hardware implementing both float 
>> binary and float decimal came into existence. It's putting pressure on 
>> /all/ languages, although it will probably not become critical until 
>> Intel does it, which they seem disinclined to do at present. In the 
>> meantime, in what is probably the most important hardware that does 
>> both and that also has an important PL/I compiler, IBM /is/ 
>> implementing FLOAT DECIMAL and FLOAT BINARY as separate hardware types.
> 
> 
> Yes, it is very convenient of PL/I to have this distinction.
> 
> It might be that IBM was planning 40 years ahead for z/Architecture
> and float decimal hardware.  I have old versions of the language
> reference.  (The one that is supposed to be compiler independent.)
> 
> Around 1977 I was told that the CDC STAR-100 had float decimal, but
> that turned out to be wrong.
> 

Or looking back at the 70xx systems that had float decimal.
-- 
prf

** Posted from http://www.teranews.com **

Brian Salter-Duke wrote:
> On Sat, 19 Jul 2008 01:30:48 -0700 (PDT), fj <francois.jacq@irsn.fr> wrote:
> 
>>On 19 juil, 06:34, Brian Salter-Duke <b_d...@bigpond.net.invalid>
>>wrote:
>>
>>>On Fri, 18 Jul 2008 20:06:21 -0700, Walter Spector <w6ws_xthiso...@earthlink.net> wrote:
>>>
>>>>Brian Salter-Duke wrote:
>>>>
>>>>>... I think those people who look after
>>>>>large scientific codes are mostly trying to add new features while
>>>>>ensuring they can be compiled with all existing compilers that have been
>>>>>used previously.
>>>
>>>>It is now mid-2008.  Any modern compiler supports F95, and has for
>>>>some years.  Some vendors phased out their F77 compilers over 10
>>>>years ago.  No need to support a seperate F77 compiler as, modulo
>>>>a very few minor issues, F77 is a subset of F90.
>>>
>>>>>These code writers have many other responsibilities in
>>>>>most cases. My own involvement is with a relatively small computational
>>>>>chemistry code that can either stand alone or interface to GAMESS(US) or
>>>>>Gaussian. So I see some of the issues from outside but close and some
>>>>>from a smaller piece of code. I am far too busy to work on upgrading the
>>>>>code to F90 or more recent. I also think it would cause more problems
>>>>>than it would solve.
>>>
>>>>Why would it cause more problems that it would solve?
>>>
>>>First, it is highly likely that in doing the upgrade I would introduce
>>>bugs, given that my experience with F77 is so much greater than that of
>>>F90 and more recent.
>>
>>No : this is wrong. My experience shows (and like you I had a large
>>experience with F77) that the F95 programming is safer than the F77
>>one if you apply the F95 style (routines within modules and accessible
>>only via a USE statement). This is simply because the F95 compilers
>>are able to check the programming in a much more efficient way.
> 
> 
> You could well be right in what you say, but I was not talking about
> writing code from scratch. I was talking about rewriting existing code.
> Then "if it ain't broke, don't fix it". If it works, any change has the
> chance of stopping it working.

Depending on what F90/95 compiler you chose, you might not notice a 
difference at all.  You would likely be able to seemlessly merge F90 and 
F77 code with few or no problems at all.  I do it all the time.  This 
sounds a little like a bit of paranoia.


> 
> 
>>If you impose in addition F2003 rules (trying to allocate only
>>allocatable arrays and to use pointer just to point to a memory area
>>already allocated), then you also avoid most of the bugs connected to
>>dynamic allocation and, for instance, very difficult to find in C or C+
>>+ programming.
>>
>>
>>>Second, since my code has to interface with other
>>>codes and they are not likely to move away from f77 for a while, this
>>>would likely introduce bugs or problems. A lot of the code is COMMON
>>>areas in my code being the same as those in say GAMESS.
>>
>>COMMONs remain available with any FORTRAN version. And the "rules" I
>>proposed before do not concern data management.
>>
>>
>>>>>I also find it interesting that when people do decide to write a new
>>>>>piece of code in my area, they do not choose Fortran. They choose C
>>>>>and/or C++.
>>>>
>>>>Given the choice of F77 or C++, I would take C++ any day.
>>>
>>>But the choice is between F90 or F95 or whatever and C++ as Richard
>>>points out in his comment. Authors are not chosing more recent Fortran
>>>versions for computational chemistry code as far as I can see. They are
>>>doing that for a reason.
>>
>>The only reason I see is the school ! Young people do not learn
>>FORTRAN at school anymore. And the C syntax is the norm today (C, C++,
>>JAVA, C#).
> 
> 
> No, the authors of at least two major comp chem codes in C/C++ were well
> versed in Fortran 77 to my knowledge.
> 
> I did not learn Fortran at uni. It was my 4th language after Mercury
> autocode, Elliot autocode and Algol60. I moved over to Fortran because of
> the mass of existing code and that remains the situation.
> 
> 
>>>Brian.
>>>
>>>
>>>>W.
>>>
>>>--
>>>      Brian Salter-Duke          Melbourne, Australia
>>>    My real address is b_duke(AT)bigpond(DOT)net(DOT)au
>>>               Use this for reply or followup
>>>   "A good programmer can write Fortran in any language"
>>
> 
> 


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Brian Salter-Duke wrote:
....
> You could well be right in what you say, but I was not talking about
> writing code from scratch. I was talking about rewriting existing code.
> Then "if it ain't broke, don't fix it". If it works, any change has the
> chance of stopping it working.
....
That's true independent of the underlying language features -- the same 
could be said if you added an interlanguage routine library in C++.

Using features of F95 in conjunction w/ existing F77 code would (imo) 
likely minimize many errors.  The only real drawback I would see would 
be if the source must be distributed to some site that has proscription 
against using anything past strict F77.  (And, ime, it's very rare to 
find anybody who uses F77 who doesn't use a fair number of extensions 
anyway).

--

Brian Salter-Duke <b_duke@bigpond.net.invalid> wrote:

> You could well be right in what you say, but I was not talking about
> writing code from scratch. I was talking about rewriting existing code.
> Then "if it ain't broke, don't fix it". If it works, any change has the
> chance of stopping it working.

Quite so. But you appear to be assuming that such a rewrite is involved
in "converting" f77 code to f90. That is simply *NOT* so.

That is, in fact, quite a major point. One of the most important design
criterion for f90 was to make sure that this would not be so. There are
many things in f90 that would not be the way they were except for that
criterion. "Nobody" (well, not enough to be a significant influence)
would have done the features that way were things starting from scratch,
but they were already in f77, so they stayed there.

If the existing code in question is f77, then with a very few small
exceptions, it is also already f90/f95/f2003 code. No "conversion" is
necessary. The few exceptions in theory tend to be even fewer in
practice, because most compilers tend to support the f77 features in
question anyway, as well as supporting many of the nonstandard features
that were common in much f77+extensions code.

A "conversion" of f77 code to f90 does not need to involve anything more
than the same kind of work involved in converting the code to work with
some other f77 compiler. Which is to say that if the code already worked
on a wide variety of f77 compilers with minimal conversion, then it will
also work on an f90 compiler with minimal conversion. I've done ths kind
of conversion myself. A lot. On large legacy scientific programs. (Quite
a lot of the people involved in Fortran standards work have experience
with such programs and regularly call on that experience in the standard
development work, contrary to your prior implication.)

To the extent that the existing code needs extension or improvement in
some way, one can bring f90 features tio bear as appropriate. That is to
say, if there are "broken" parts, you can work on fixing them. You don't
have to rewrite the whole thing. If anyone is telling you that a rewrite
is required to convert to f90, then either you are listening to the
wrong peope, or you aren't hearing them correctly. (It is at least
possible that they are arguing that you ought to rewrite the code in
f90, but that isn't at all the same thing as saying that you have to
rewrite the code to use f90).

Now if you want to convert the code to C or C+, then you *DO* need to
rewrite the whole thing. In fact, you may well need to redesign its
whole architecture, particularly for C++, unless you want to end up with
C++ code that looks like it was written by a Fortran programmer trying
to write Fortran code with C++ syntax.

I realize that it wasn't quite what you were saying (I heard you saying
more that the f77 code was remaining f77, presumably plus extensions -
both because almost all large "f77" codes do use extensions and because
of th specific mention of real*8), but I have run into other people who
have tried to maintain that they could not afford to rewrite their f77
code, which is why they were converting it to C or C++ instead of
f90/f95. I have a little trouble figuring out how they maintain a
straight face while saying that. :-)

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Brian Salter-Duke wrote:
> ...
> You could well be right in what you say, but I was not talking about
> writing code from scratch. I was talking about rewriting existing code.
> Then "if it ain't broke, don't fix it". If it works, any change has the
> chance of stopping it working.

As fj, Richard Maine, and others continue to point out, it is far
easier to recompile an older F77 code with an F95 compiler than it
is to totally recode from scratch to C or C++.  Orders of magnitude.

Once the application is working with a modern compiler, you can start
to integrate some newer features.  Modules are a good first step.
Create a module, then 'include' all the files containing your subroutines
and functions in it.  (Taking care to change all the END statements into
END SUBROUTINE or END FUNCTION.  Takes a few seconds with a modern text
editor.)  You will be amazed at all the interface errors the compiler will
find in supposedly "ain't broke" code.

Same goes for COMMON blocks.

>> The only reason I see is the school ! Young people do not learn
>> FORTRAN at school anymore. And the C syntax is the norm today (C, C++,
>> JAVA, C#).
> 
> No, the authors of at least two major comp chem codes in C/C++ were well
> versed in Fortran 77 to my knowledge.

But it sounds like they were totally ignorant of F90.

> I did not learn Fortran at uni. It was my 4th language after Mercury
> autocode, Elliot autocode and Algol60. I moved over to Fortran because of
> the mass of existing code and that remains the situation.

If you liked Algol 60, you should be a fan of F95!  (No call-by-name
in F95 though.)

W.

On Sat, 19 Jul 2008 09:21:03 -0700, Richard Maine <nospam@see.signature> wrote:
> Brian Salter-Duke <b_duke@bigpond.net.invalid> wrote:
>
>> You could well be right in what you say, but I was not talking about
>> writing code from scratch. I was talking about rewriting existing code.
>> Then "if it ain't broke, don't fix it". If it works, any change has the
>> chance of stopping it working.
>
> Quite so. But you appear to be assuming that such a rewrite is involved
> in "converting" f77 code to f90. That is simply *NOT* so.

No, I am not assuming that in any way. I use modern compilers such as
gfortran, and ifort to test our code. I was responding to people who
were saying that if I did convert it to f90 it would be more robust nad
have less bugs, or at least it would be easier to fix bugs. Of course the
modern compilers compile f77 code and so they should,

> That is, in fact, quite a major point. One of the most important design
> criterion for f90 was to make sure that this would not be so. There are
> many things in f90 that would not be the way they were except for that
> criterion. "Nobody" (well, not enough to be a significant influence)
> would have done the features that way were things starting from scratch,
> but they were already in f77, so they stayed there.
>
> If the existing code in question is f77, then with a very few small
> exceptions, it is also already f90/f95/f2003 code. No "conversion" is
> necessary. The few exceptions in theory tend to be even fewer in
> practice, because most compilers tend to support the f77 features in
> question anyway, as well as supporting many of the nonstandard features
> that were common in much f77+extensions code.
>
> A "conversion" of f77 code to f90 does not need to involve anything more
> than the same kind of work involved in converting the code to work with
> some other f77 compiler. Which is to say that if the code already worked
> on a wide variety of f77 compilers with minimal conversion, then it will
> also work on an f90 compiler with minimal conversion. I've done ths kind
> of conversion myself. A lot. On large legacy scientific programs. (Quite
> a lot of the people involved in Fortran standards work have experience
> with such programs and regularly call on that experience in the standard
> development work, contrary to your prior implication.)

Apologies for the implication. It was just my impression. The codes I am
talking about already have in place procedures to compile them on a very
large range of compilers, and they are constantly updated to work with
new compilers. GAMESS(US) for example at one time recommended f2c/gcc
for linux, then it recommended g77 and now it recommends gfortran, but
it still has the ability to use the older methods and ifort and pgf77.
These codes are legacy only in that they are old. They are still in
active development and use.

At least for now, I would hesitate about changing any code so it did
not work with g77, as I know that some users only have access to g77. Of
course this is changing and will soon be quite unnecessary.

> To the extent that the existing code needs extension or improvement in
> some way, one can bring f90 features tio bear as appropriate. That is to
> say, if there are "broken" parts, you can work on fixing them. You don't
> have to rewrite the whole thing. If anyone is telling you that a rewrite
> is required to convert to f90, then either you are listening to the
> wrong peope, or you aren't hearing them correctly. (It is at least
> possible that they are arguing that you ought to rewrite the code in
> f90, but that isn't at all the same thing as saying that you have to
> rewrite the code to use f90).

Exactly - they are saying that I ought.

> Now if you want to convert the code to C or C+, then you *DO* need to
> rewrite the whole thing. In fact, you may well need to redesign its
> whole architecture, particularly for C++, unless you want to end up with
> C++ code that looks like it was written by a Fortran programmer trying
> to write Fortran code with C++ syntax.

I would not even think of converting the code to C or C++. I was merely
commenting that some people who started writing a computational
chemistry program from scratch used C or C++, not f90 or f95.

> I realize that it wasn't quite what you were saying (I heard you saying
> more that the f77 code was remaining f77, presumably plus extensions -
> both because almost all large "f77" codes do use extensions and because
> of th specific mention of real*8), but I have run into other people who
> have tried to maintain that they could not afford to rewrite their f77
> code, which is why they were converting it to C or C++ instead of
> f90/f95. I have a little trouble figuring out how they maintain a
> straight face while saying that. :-)

Thanks as always for your thoughtful and helpful comments.

Brian.

-- 
      Brian Salter-Duke          Melbourne, Australia
    My real address is b_duke(AT)bigpond(DOT)net(DOT)au
               Use this for reply or followup
   "A good programmer can write Fortran in any language"

glen herrmannsfeldt wrote:
> John W Kennedy wrote:
> (snip)
> 
>> But it is only very recently that hardware implementing both float 
>> binary and float decimal came into existence. It's putting pressure on 
>> /all/ languages, although it will probably not become critical until 
>> Intel does it, which they seem disinclined to do at present. In the 
>> meantime, in what is probably the most important hardware that does 
>> both and that also has an important PL/I compiler, IBM /is/ 
>> implementing FLOAT DECIMAL and FLOAT BINARY as separate hardware types.
> 
> Yes, it is very convenient of PL/I to have this distinction.
> 
> It might be that IBM was planning 40 years ahead for z/Architecture
> and float decimal hardware.  I have old versions of the language
> reference.  (The one that is supposed to be compiler independent.)

Yeah, but they were sloppy about the definition of ROUND, which assumed 
that all floating-point was binary (or approximately binary, as the 
S/360 was); to literally implement it on some hardware (like the old 
707x family) would have caused the equivalent of a parity check.

Allen-Babcock's RUSH PL/I-based time-sharing system had hardware float 
decimal (it ran on 360/50s with massively altered microcode), and I seem 
to remember that CALL/360 PL/I may have used software float decimal, as 
BASIC/370 (not at all compatible with VS BASIC) did.

I hear that Mike Cowlishaw was of great importance in the creation of 
IEEE-754R -- it certainly makes sense that the creator of REXX would 
have an interest. But I see that he joined IBM in 1974, too late to have 
had any significant involvement in PL/I.
-- 
John W. Kennedy
  "You can, if you wish, class all science-fiction together; but it is 
about as perceptive as classing the works of Ballantyne, Conrad and W. 
W. Jacobs together as the 'sea-story' and then criticizing _that_."
   -- C. S. Lewis.  "An Experiment in Criticism"

Peter Flass wrote:
> glen herrmannsfeldt wrote:
>> John W Kennedy wrote:
>> (snip)
>>
>>> But it is only very recently that hardware implementing both float 
>>> binary and float decimal came into existence. It's putting pressure 
>>> on /all/ languages, although it will probably not become critical 
>>> until Intel does it, which they seem disinclined to do at present. In 
>>> the meantime, in what is probably the most important hardware that 
>>> does both and that also has an important PL/I compiler, IBM /is/ 
>>> implementing FLOAT DECIMAL and FLOAT BINARY as separate hardware types.
>>
>>
>> Yes, it is very convenient of PL/I to have this distinction.
>>
>> It might be that IBM was planning 40 years ahead for z/Architecture
>> and float decimal hardware.  I have old versions of the language
>> reference.  (The one that is supposed to be compiler independent.)
>>
>> Around 1977 I was told that the CDC STAR-100 had float decimal, but
>> that turned out to be wrong.
>>
> 
> Or looking back at the 70xx systems that had float decimal.

And the 1620.


-- 
John W. Kennedy
  "The poor have sometimes objected to being governed badly; the rich 
have always objected to being governed at all."
   -- G. K. Chesterton.  "The Man Who Was Thursday"

John W Kennedy wrote:
(snip)

> Allen-Babcock's RUSH PL/I-based time-sharing system had hardware float 
> decimal (it ran on 360/50s with massively altered microcode), and I seem 
> to remember that CALL/360 PL/I may have used software float decimal, as 
> BASIC/370 (not at all compatible with VS BASIC) did.

CALL/OS PL/I uses binary arithmetic for FIXED DECIMAL, such
that FIXED DEC(9,9) will overflow at 2.147483647.  (I tried
it once to be sure.)   I think CALL/OS is related to CALL/360,
but I am not sure exactly how.  (I used it in high school,
after using PL/I (F).  I only had (F) manuals, and tried to
figure out what it could and couldn't do from them.)

I did find an interesting bug in CALL/OS Fortran, in that
there is one character that, if printed, will crash the
whole system.  I was trying to figure out all the punch
tape combinations on an ASR-33 terminal by printing all
256 EBCDIC characters, and the system crashed.  When it
came back up, I tried again with the same result.

-- glen

> You could well be right in what you say, but I was not talking about
> writing code from scratch. I was talking about rewriting existing code.
> Then "if it ain't broke, don't fix it". If it works, any change has the
> chance of stopping it working.

If it's seperately-compiled F77 fixed-form source code, you could lay a 
bet that it _is_ already broken in various ways - you and your customers 
just haven't noticed that yet. As suggested elsewhere, just putting 
everything into modules in appropriate ways will usually point out lots 
of potential problems. Converting long argument lists of single items 
into shorter arguments lists using derived types will make maintenance 
easier and less error prone. And so on.

	Jan

In <4880ce70$0$5011$607ed4bc@cv.net>, on 07/18/2008
   at 01:10 PM, John W Kennedy <jwkenne@attglobal.net> said:

>But it is only very recently that hardware implementing both float 
>binary and float decimal came into existence.

If you consider 4 decades to be recent.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

On 2008-07-19, Brian Salter-Duke <b_duke@bigpond.net.invalid> wrote:

> I am far too busy to work on upgrading the
> code to F90 or more recent. I also think it would cause more problems
> than it would solve.

A first step would be to convert COMMON blocks into modules.  This would
likely uncover some problems which have been present all the time.

On Sun, 20 Jul 2008 22:14:11 +0000 (UTC), Thomas Koenig <tkoenig@netcologne.de> wrote:
> On 2008-07-19, Brian Salter-Duke <b_duke@bigpond.net.invalid> wrote:
>
>> I am far too busy to work on upgrading the
>> code to F90 or more recent. I also think it would cause more problems
>> than it would solve.
>
> A first step would be to convert COMMON blocks into modules.  This would
> likely uncover some problems which have been present all the time.

I can not do that because the people who own the code I interface our
code to are not going to do it. Even if I could it would be a massive
job. There are other ways of checking COMMON statements.

The one weakness of computational chemistry codes is their size. In most
cases new code is written by a graduate student. If the group is lucky
it has a permanant research officer who checks and then includes such
code in the next release. Nothing is changed unless it has to be
changed. There are not the resources. In the potentially better cases
where the code is commercial and brings in a solid income, it might be
expected that changes to the code between releases could be extensive.
If Gauusian Inc is anything to go by, that does not happen because again
the best commercial solution is to expand the scope of the code with new
methods and new features. 

The kind of change that people are suggesting here are just not going to
happen. New people will write new programs from scratch and get some new
users or customers, but the old codes, if they keep adding new features,
do not go away. 

Even for the code I am involved with which is much smaller and benefits
greatly for being incorporated into other people's code, change is not
occurring. There are only two of us and we both have other things to do.
So again only new features are added. We even have a long list of new
features that are not happening.

Let us leave this discussion now.

Brian.

-- 
      Brian Salter-Duke          Melbourne, Australia
    My real address is b_duke(AT)bigpond(DOT)net(DOT)au
               Use this for reply or followup
   "A good programmer can write Fortran in any language"

In article <zQ8gk.20756$IK1.8032@news-server.bigpond.net.au>,
Brian Salter-Duke  <b_duke@bigpond.net.invalid> wrote:

>It is not that trivial for a program the size of Gaussian and one that
>is split into several dozen separate source files. It would be tedious
>to check that making that change has not extended a line beyond 72
>characters,

Compilers typically have a flag to help you check that, in addition to
a flag that lets you compile lines longer than 72 characters.

>As I indicated earlier I do not support changing the standard, but I do
>support keeping compilers backwardly compatable with F77 and allowing
>REAL*8.

I can't figure out what the alarm is about; when's the last time any
compiler removed such a feature, or a new compiler failed to get flack
for not compiling important crufty codes?

-- greg

Brian Salter-Duke wrote:
> On Sun, 20 Jul 2008 22:14:11 +0000 (UTC), Thomas Koenig <tkoenig@netcologne.de> wrote:
>> A first step would be to convert COMMON blocks into modules.  This would
>> likely uncover some problems which have been present all the time.
> 
> I can not do that because the people who own the code I interface our
> code to are not going to do it. Even if I could it would be a massive
> job.

This is where education on F90 comes into play.  Modules can hold COMMON
blocks too.  For example:

   module xyzzy_mod
     implicit none

     real :: a, b, c
     common /xyzzy/ a, b, c

   end module

Old code can remain unchanged, and new code can use the much more reliable
and much more flexible module approach.

Eventually, the old code can be migrated to 'use' the module.  This
is trivial if the old code actually used INCLUDE files for the blocks.
Somewhat harder if the names change from routine to routine.  (But if it
becomes too tedious, one can use renaming on the USE statement to deal
with the problem.)

> There are other ways of checking COMMON statements.

Perhaps.  But given that the Standard allows their definitions to vary
from routine to routine means that it is not likely to happen.

> Let us leave this discussion now.

Ok.

W.

In article <CdOdncoynei1aB7VnZ2dnUVZ_vadnZ2d@earthlink.com>,
Walter Spector  <w6ws_xthisoutx@earthlink.net> wrote:

>> There are other ways of checking COMMON statements.
>
>Perhaps.  But given that the Standard allows their definitions to vary
>from routine to routine means that it is not likely to happen.

I'm not sure what "it" is, but the "it" of "for the case where the
common blocks are the same in all the routines" has been checkable
using f2c since f2c learned about ANSI C. Not to mention debugging
compilers that have this sort of check.

-- greg

robin wrote:
> Greg Lindahl wrote:

>>And this was a known flaw -- PL/1 suffered from it.

> PL/I didn't not "suffer" from it.
> PL/I provides a default precision (like REAL in Fortran)
> with the use of the keyword FLOAT --
> that gives what is generally known as single precision.

But that doesn't help for double precision.  Also, FIXED
point would seem to have more problem with this.  It is
find when you do know the needed precision, but namny times
you don't.

-- glen


> When a declaration gives an actual precision, the hardware data type
> actually used is one that exactly matches that precision, or (if there is
> not one that exactly matches it) the minimum precision that exceeds that
> precision is used, just as Fortran does.
> 
> In particular, if single-byte integers are requred, PL/I will give it.
> 
> If you want exactly 3-decimal digit computations, PL/I will give it.
> 
> In general, the precision can be given in terms of the number of
> decimal digits desired for the calculation, e.g.,
>      declare x float decimal (10);
> This has some convenient properties, in that when you print the
> value of X using free-format, you get exactly 10 decimal digits printed.
> 
> 

On Jul 20, 7:44 am, Jan Vorbr=FCggen <Jan.Vorbrueg...@not-thomson.net>
wrote:
> > You could well be right in what you say, but I was not talking about
> > writing code from scratch. I was talking about rewriting existing code.
> > Then "if it ain't broke, don't fix it". If it works, any change has the
> > chance of stopping it working.
>
> If it's seperately-compiled F77 fixed-form source code, you could lay a
> bet that it _is_ already broken in various ways - you and your customers
> just haven't noticed that yet. As suggested elsewhere, just putting
> everything into modules in appropriate ways will usually point out lots
> of potential problems. Converting long argument lists of single items
> into shorter arguments lists using derived types will make maintenance
> easier and less error prone. And so on.
>
>         Jan

On that note, it might be interesting to mention a study that found an
average of 12 statically detectable faults per 1000 lines in
*commercially released* Fortran 77 projects.  A statically detectable
fault was defined as "a misuse of the language which will very likely
fail in some context."  Examples include interface inconsistencies and
using uninitialized variables -- things that would likely be caught
with the use of Fortran 90 constructs such as modules and implicit
none.

See HATTON, L. 1997. The T experiments: Errors in scientific software.
IEEE Computat. Scien. Eng. 4, 27=9638.

Damian

Greg Lindahl wrote:
> In article <CdOdncoynei1aB7VnZ2dnUVZ_vadnZ2d@earthlink.com>,
> Walter Spector  <w6ws_xthisoutx@earthlink.net> wrote:
> 
>>> There are other ways of checking COMMON statements.
>> Perhaps.  But given that the Standard allows their definitions to vary
>>from routine to routine means that it is not likely to happen.
> 
> I'm not sure what "it" is, but the "it" of "for the case where the
> common blocks are the same in all the routines" has been checkable
> using f2c since f2c learned about ANSI C.

And long before that.

> Not to mention debugging
> compilers that have this sort of check.

Perhaps.  But as you well know, a common block may vary in different
routines for many reasons - ranging from very accidental to very
deliberate.  Automated tools have a hard time telling the difference.
Separate compilation also throws a wrench into any such checks.

And many of the tools of the past were either not available on platforms
of interest, buggy in themselves, poorly documented, expensive, not well
matched to the compiler on the target system, etc.  Bottom line is that
they were simply not as highly used as some would like to think.

W.

Damian wrote:
....
> On that note, it might be interesting to mention a study that found an
> average of 12 statically detectable faults per 1000 lines in
> *commercially released* Fortran 77 projects.  A statically detectable
> fault was defined as "a misuse of the language which will very likely
> fail in some context."  Examples include interface inconsistencies and
> using uninitialized variables -- things that would likely be caught
> with the use of Fortran 90 constructs such as modules and implicit
> none.

I agree with what you're saying except for the part about
unitialized variables.  It's true that *some* of this testing
can be static.  That is, the compiler is sometimes able to
detect places where no paths to a reference contain an
initialization or it's sometimes able to detect that all paths
to a reference contain an initialization.  In the (often wide)
middle ground, the compiler can't statically tell and
some form of run-time test is needed.

Then, of course, there's the problem of people "initializing"
their variables to some neutral, innocuous value in order to
avoid the warning messages about unitialized variables.  That
makes for code that gives plausible wrong answers - the
worst kind of error.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

Shmuel (Seymour J.) Metz wrote:
> In <4880ce70$0$5011$607ed4bc@cv.net>, on 07/18/2008
>    at 01:10 PM, John W Kennedy <jwkenne@attglobal.net> said:
> 
>> But it is only very recently that hardware implementing both float 
>> binary and float decimal came into existence.
> 
> If you consider 4 decades to be recent.

Both hardware binary floating point and hardware decimal floating point 
in one machine?

-- 
John W. Kennedy
  "Sweet, was Christ crucified to create this chat?"
   -- Charles Williams.  "Judgement at Chelmsford"

John W Kennedy wrote:
> Shmuel (Seymour J.) Metz wrote:
>> In <4880ce70$0$5011$607ed4bc@cv.net>, on 07/18/2008
>>    at 01:10 PM, John W Kennedy <jwkenne@attglobal.net> said:
>>
>>> But it is only very recently that hardware implementing both float 
>>> binary and float decimal came into existence.
>>
>> If you consider 4 decades to be recent.
> 
> Both hardware binary floating point and hardware decimal floating point 
> in one machine?

And, of course, I'm talking about both being simultaneously available in 
the same program -- not, for example, a 1620 or 7070 emulator on a 360.


-- 
John W. Kennedy
  "The pathetic hope that the White House will turn a Caligula into a 
Marcus Aurelius is as na�ve as the fear that ultimate power inevitably 
corrupts."
   -- James D. Barber (1930-2004)

Shmuel (Seymour J.) Metz wrote:

> In <4880ce70$0$5011$607ed4bc@cv.net>, on 07/18/2008
>    at 01:10 PM, John W Kennedy <jwkenne@attglobal.net> said:

>>But it is only very recently that hardware implementing both float 
>>binary and float decimal came into existence.

> If you consider 4 decades to be recent.

I think we have had this discussion before, though I may
not be convinced.  By floating point hardware, I would mean
hardware that can do floating point addition, subtraction,
multiplication, or division of floating point numbers.

That would include microcoded implementations that take
relatively few machine cycles, but not ones that take
hundreds of thousands of cycles.  (The distinction
being between microcode as a systematic form of hardware
design, as opposed to software emulation.)

-- glen

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:Q6SdndZiv4SalhnVnZ2dnUVZ_oDinZ2d@comcast.com...
> robin wrote:
> > Greg Lindahl wrote:
>
> >>And this was a known flaw -- PL/1 suffered from it.
>
> > PL/I didn't not "suffer" from it.
> > PL/I provides a default precision (like REAL in Fortran)
> > with the use of the keyword FLOAT --
> > that gives what is generally known as single precision.
>
> But that doesn't help for double precision.

I've already given suitable declarations for that.

>  Also, FIXED
> point would seem to have more problem with this.  It is
> find when you do know the needed precision, but namny times
> you don't.

In fixed-point, the desired precision is usually known,
based on the sizes of numbers that are to be encountered.
If those are not known, one would choose floating-point.

> > When a declaration gives an actual precision, the hardware data type
> > actually used is one that exactly matches that precision, or (if there is
> > not one that exactly matches it) the minimum precision that exceeds that
> > precision is used, just as Fortran does.
> >
> > In particular, if single-byte integers are requred, PL/I will give it.
> >
> > If you want exactly 3-decimal digit computations, PL/I will give it.
> >
> > In general, the precision can be given in terms of the number of
> > decimal digits desired for the calculation, e.g.,
> >      declare x float decimal (10);
> > This has some convenient properties, in that when you print the
> > value of X using free-format, you get exactly 10 decimal digits printed.

"Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
news:zQ8gk.20756$IK1.8032@news-server.bigpond.net.au...
> On Fri, 18 Jul 2008 11:54:30 GMT, robin <robin_v@bigpond.com> wrote:
> > "Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
> > news:Nxybk.17180$IK1.4437@news-server.bigpond.net.au...

> > Regardless of whether it is or is not available,
> > it's trivial to change REAL*8 to DOUBLE PRECISION
> > or some other equivalent form that's standard.
>
> It is not that trivial for a program the size of Gaussian and one that
> is split into several dozen separate source files. It would be tedious
> to check that making that change has not extended a line beyond 72
> characters,

That is something that can be automated.

> Remember it is still f77 code even if it is compliled these
> days by more modern compilers. Indeed I am quite sure it would extend
> the line to be too long in hundreds of cases. Actually it might well do
> it in all 6000 cases of REAL*8 occuring.  The change has already been
> made in some codes such as GAMESS(US), but there are lots of other very
> long f77 scientific programs out there still in very wide use.

You over-rate the "difficulty" with which such constructs
can be converted from REAL*8 to DOUBLE PRECISION.

> As I indicated earlier I do not support changing the standard, but I do
> support keeping compilers backwardly compatable with F77 and allowing
> REAL*8.
>
> I get the impression that those who are developing new versions of
> Fortran, while doing a great and necessary job, do not fully understand
> the problems of maintaining very large scientific programs.

You understimate the understanding of Fortran users.

"Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
news:Niigk.20898$IK1.15906@news-server.bigpond.net.au...
> On Sat, 19 Jul 2008 01:30:48 -0700 (PDT), fj <francois.jacq@irsn.fr> wrote:
> > On 19 juil, 06:34, Brian Salter-Duke <b_d...@bigpond.net.invalid>
> > wrote:
> >> On Fri, 18 Jul 2008 20:06:21 -0700, Walter Spector <w6ws_xthiso...@earthlink.net> wrote:
> >> > Brian Salter-Duke wrote:
> >> >> ... I think those people who look after
> >> >> large scientific codes are mostly trying to add new features while
> >> >> ensuring they can be compiled with all existing compilers that have been
> >> >> used previously.
> >>
> >> > It is now mid-2008.  Any modern compiler supports F95, and has for
> >> > some years.  Some vendors phased out their F77 compilers over 10
> >> > years ago.  No need to support a seperate F77 compiler as, modulo
> >> > a very few minor issues, F77 is a subset of F90.
> >>
> >> > > These code writers have many other responsibilities in
> >> >> most cases. My own involvement is with a relatively small computational
> >> >> chemistry code that can either stand alone or interface to GAMESS(US) or
> >> >> Gaussian. So I see some of the issues from outside but close and some
> >> >> from a smaller piece of code. I am far too busy to work on upgrading the
> >> >> code to F90 or more recent. I also think it would cause more problems
> >> >> than it would solve.
> >>
> >> > Why would it cause more problems that it would solve?
> >>
> >> First, it is highly likely that in doing the upgrade I would introduce
> >> bugs, given that my experience with F77 is so much greater than that of
> >> F90 and more recent.
> >
> > No : this is wrong. My experience shows (and like you I had a large
> > experience with F77) that the F95 programming is safer than the F77
> > one if you apply the F95 style (routines within modules and accessible
> > only via a USE statement). This is simply because the F95 compilers
> > are able to check the programming in a much more efficient way.
>
> You could well be right in what you say, but I was not talking about
> writing code from scratch. I was talking about rewriting existing code.
> Then "if it ain't broke, don't fix it". If it works, any change has the
> chance of stopping it working.

On the contrary, using a modern compiler is going to
find bugs in the program that have not been detected
previously.
I have converted many old codes, and found this to be
true time and time again.

> > If you impose in addition F2003 rules (trying to allocate only
> > allocatable arrays and to use pointer just to point to a memory area
> > already allocated), then you also avoid most of the bugs connected to
> > dynamic allocation and, for instance, very difficult to find in C or C+
> > + programming.
> >
> >> Second, since my code has to interface with other
> >> codes and they are not likely to move away from f77 for a while, this
> >> would likely introduce bugs or problems. A lot of the code is COMMON
> >> areas in my code being the same as those in say GAMESS.
> >
> > COMMONs remain available with any FORTRAN version. And the "rules" I
> > proposed before do not concern data management.
> >
> >>
> >> >> I also find it interesting that when people do decide to write a new
> >> >> piece of code in my area, they do not choose Fortran. They choose C
> >> >> and/or C++.
> >> > Given the choice of F77 or C++, I would take C++ any day.
> >>
> >> But the choice is between F90 or F95 or whatever and C++ as Richard
> >> points out in his comment. Authors are not chosing more recent Fortran
> >> versions for computational chemistry code as far as I can see. They are
> >> doing that for a reason.
> >
> > The only reason I see is the school ! Young people do not learn
> > FORTRAN at school anymore. And the C syntax is the norm today (C, C++,
> > JAVA, C#).
>
> No, the authors of at least two major comp chem codes in C/C++ were well
> versed in Fortran 77 to my knowledge.

And not F90 or 95?

"Richard Maine" <nospam@see.signature> wrote in message
news:1ikbhwu.ox2g8811bljp0N%nospam@see.signature...
> Brian Salter-Duke <b_duke@bigpond.net.invalid> wrote:
>
> > You could well be right in what you say, but I was not talking about
> > writing code from scratch. I was talking about rewriting existing code.
> > Then "if it ain't broke, don't fix it". If it works, any change has the
> > chance of stopping it working.
>
> Quite so. But you appear to be assuming that such a rewrite is involved
> in "converting" f77 code to f90. That is simply *NOT* so.

I think that the point of discussion has been overlooked.

We were talking about converting REAL*8 constructs to
DOUBLE PRECISION, which is trivial.
That change permits codes to run under all compilers,
whether they be F77, F90 , F95, or later.

"Brian Salter-Duke" <b_duke@bigpond.net.invalid> wrote in message
news:S%ugk.21029$IK1.10306@news-server.bigpond.net.au...
> On Sat, 19 Jul 2008 09:21:03 -0700, Richard Maine <nospam@see.signature> wrote:
> > Brian Salter-Duke <b_duke@bigpond.net.invalid> wrote:
> >
> >> You could well be right in what you say, but I was not talking about
> >> writing code from scratch. I was talking about rewriting existing code.
> >> Then "if it ain't broke, don't fix it". If it works, any change has the
> >> chance of stopping it working.
> >
> > Quite so. But you appear to be assuming that such a rewrite is involved
> > in "converting" f77 code to f90. That is simply *NOT* so.
>
> No, I am not assuming that in any way. I use modern compilers such as
> gfortran, and ifort to test our code. I was responding to people who
> were saying that if I did convert it to f90 it would be more robust nad
> have less bugs, or at least it would be easier to fix bugs. Of course the
> modern compilers compile f77 code and so they should,
>
> > That is, in fact, quite a major point. One of the most important design
> > criterion for f90 was to make sure that this would not be so. There are
> > many things in f90 that would not be the way they were except for that
> > criterion. "Nobody" (well, not enough to be a significant influence)
> > would have done the features that way were things starting from scratch,
> > but they were already in f77, so they stayed there.
> >
> > If the existing code in question is f77, then with a very few small
> > exceptions, it is also already f90/f95/f2003 code. No "conversion" is
> > necessary. The few exceptions in theory tend to be even fewer in
> > practice, because most compilers tend to support the f77 features in
> > question anyway, as well as supporting many of the nonstandard features
> > that were common in much f77+extensions code.
> >
> > A "conversion" of f77 code to f90 does not need to involve anything more
> > than the same kind of work involved in converting the code to work with
> > some other f77 compiler. Which is to say that if the code already worked
> > on a wide variety of f77 compilers with minimal conversion, then it will
> > also work on an f90 compiler with minimal conversion. I've done ths kind
> > of conversion myself. A lot. On large legacy scientific programs. (Quite
> > a lot of the people involved in Fortran standards work have experience
> > with such programs and regularly call on that experience in the standard
> > development work, contrary to your prior implication.)
>
> Apologies for the implication. It was just my impression. The codes I am
> talking about already have in place procedures to compile them on a very
> large range of compilers, and they are constantly updated to work with
> new compilers. GAMESS(US) for example at one time recommended f2c/gcc
> for linux, then it recommended g77 and now it recommends gfortran, but
> it still has the ability to use the older methods and ifort and pgf77.
> These codes are legacy only in that they are old. They are still in
> active development and use.
>
> At least for now, I would hesitate about changing any code so it did
> not work with g77, as I know that some users only have access to g77. Of
> course this is changing and will soon be quite unnecessary.
>
> > To the extent that the existing code needs extension or improvement in
> > some way, one can bring f90 features tio bear as appropriate. That is to
> > say, if there are "broken" parts, you can work on fixing them. You don't
> > have to rewrite the whole thing. If anyone is telling you that a rewrite
> > is required to convert to f90, then either you are listening to the
> > wrong peope, or you aren't hearing them correctly. (It is at least
> > possible that they are arguing that you ought to rewrite the code in
> > f90, but that isn't at all the same thing as saying that you have to
> > rewrite the code to use f90).
>
> Exactly - they are saying that I ought.
>
> > Now if you want to convert the code to C or C+, then you *DO* need to
> > rewrite the whole thing. In fact, you may well need to redesign its
> > whole architecture, particularly for C++, unless you want to end up with
> > C++ code that looks like it was written by a Fortran programmer trying
> > to write Fortran code with C++ syntax.
>
> I would not even think of converting the code to C or C++. I was merely
> commenting that some people who started writing a computational
> chemistry program from scratch used C or C++, not f90 or f95.

Because (you said) their experience with Fortran was with F77 only.

> > I realize that it wasn't quite what you were saying (I heard you saying
> > more that the f77 code was remaining f77, presumably plus extensions -
> > both because almost all large "f77" codes do use extensions and because
> > of th specific mention of real*8), but I have run into other people who
> > have tried to maintain that they could not afford to rewrite their f77
> > code, which is why they were converting it to C or C++ instead of
> > f90/f95. I have a little trouble figuring out how they maintain a
> > straight face while saying that. :-)

"Greg Lindahl" <lindahl@pbm.com> wrote in message news:4883d021$1@news.meer.net...
> In article <zQ8gk.20756$IK1.8032@news-server.bigpond.net.au>,
> Brian Salter-Duke  <b_duke@bigpond.net.invalid> wrote:
>
> >It is not that trivial for a program the size of Gaussian and one that
> >is split into several dozen separate source files. It would be tedious
> >to check that making that change has not extended a line beyond 72
> >characters,
>
> Compilers typically have a flag to help you check that, in addition to
> a flag that lets you compile lines longer than 72 characters.

But that may not exist on some old F77 compilers.
However, as I have said, conversion of REAL*8 to DOUBLE PRECISION
is trivial, without producing long lines.

> >As I indicated earlier I do not support changing the standard, but I do
> >support keeping compilers backwardly compatable with F77 and allowing
> >REAL*8.
>
> I can't figure out what the alarm is about; when's the last time any
> compiler removed such a feature, or a new compiler failed to get flack
> for not compiling important crufty codes?

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:A_ydnYBptMkY-R3VnZ2dnUVZ_uGdnZ2d@comcast.com...
> robin wrote:
> > glen herrmannsfeldt wrote in message ...
>
> >>robin wrote:
> >>(snip)
>
> >>>For non IEEE and double words, IBM hardware allowed
> >>>for hex float with 53 maximum guaranteed binary bits, hence
> >>>it could not "round up" to 54 because the hardware
> >>>could not support it.
>
> >>Extended precision hardware has existed since the
> >>360/85,
>
> > But not on the S/360 series generally.
>
> No, but they supplied an emulator.

Not on any of the other 360 systems of which I am aware.
It was not introduced until the /370, and then only
as A, S, and M.

> The original comment applies to the Optimizing compiler
> and later ones.  (F) didn't support extended precision.

Of course not, because it wasn't available on the hardware.

> The rule for precision is supposed to be CEIL(3.32*p) but
> in the case I mentioned, they modified it slightly.
>
> >>and all 370 and later processors.
>
> > Not for division.
> > That was implemented in software.
>
> There is an IBM Systems Journal article on extended
> precision.  IBM did the study showing that the demand
> for DXR was low enough that software was the best way.

As I said, it wasn't for division.

> Somewhat late in ESA/390 it was finally added.
>
> >>Software emulation is used for other S/360 processors.
>
> > That's not so.  And how many S/360 processors are still running?
>
> Are you complaining about my use of the present tense?

I'm saying that it wasn't available on the /360 period.
I'm also saying that unless you can cite a working S/360,
you are incorrect.

> I usually use present tense describing an architecture, which
> exists whether or not any implementations of it exist.

If it does not exist, it doesn't exist.

> >>>But in any case PL/I compilers use whatever hardware
> >>>is available.  And if decimal float is available, the compiler
> >>>uses decimal hardware when FLOAT DECIMAL (16) is
> >>>specified, and binary hardware (if available) when FLOAT BINARY
> >>>is specified.
>
> It seems to me that, especially for floating point, the
> DECIMAL attribute is meant more to indicate specifying
> precision in decimal digits than to specify float decimal
> hardware.

Some machines actually provided float decimal hardware.
The Univac was one of those.

>  That is less true in fixed point, where scaling may
> require multiply or divide by powers of ten, which is easier
> in decimal arithmetic.   I do know at least one IBM compiler
> that implements FIXED DECIMAL in binary.

And I know of many PL/I compilers that implement
FIXED DECIMAL using DECIMAL hardware,
and FIXED BINARY in BINARY hardware.

On those computers that did not have decimal instructions,
decimal arithmetic was implemented using binary integer
instructions.  There is nothing unusual or rare about that.

IBM's PL/I compiler for OS/2 implemented floating-point
in software.

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:ih9gk.125183$102.109230@bgtnsc05-news.ops.worldnet.att.net...
> Brian Salter-Duke wrote:
> ...
> > It is not that trivial for a program the size of Gaussian and one that
> > is split into several dozen separate source files. It would be tedious
> > to check that making that change has not extended a line beyond 72
> > characters, Remember it is still f77 code even if it is compliled
> > these days by more modern compilers. Indeed I am quite sure it would
> > extend the line to be too long in hundreds of cases. Actually it
> > might well do it in all 6000 cases of REAL*8 occuring.  The change
> > has already been made in some codes such as GAMESS(US), but there are
> > lots of other very long f77 scientific programs out there still in
> > very wide use.
>
> Any line that such processing causes to extend beyond the 72
> column limit may be made into a continuation:
>
>       REAL*8 abc, def, ..., xyz
>
> becomes:
>
>       REAL(dp) :: abc, def, ... pqr,
>      & stu, vw, xyz
>
> If the line was already continued, this doesn't change the meaning
> of any of the following continuation lines.  Nor does it send you
> past the continuation limit: prior to F2003,

And how many compilers implement F2003?

> the limit was 19 continuations
> (for a maximum of 20 lines in a statement), since then the limit
> has been 255 continuations (for a maximum of 256 lines in a
> statement).  The automatic conversion leaves code that still
> conforms - even under fixed source form rules.

That is of no help to the OP who thinks that the
code needs to run on F77 compilers.

The only way to be certain that it will is to make
two separate DOUBLE P... statements.

On Jul 22, 6:34=EF=BF=BDam, "robin" <robi...@bigpond.com> wrote:
> "Brian Salter-Duke" <b_d...@bigpond.net.invalid> wrote in message
>
> news:Niigk.20898$IK1.15906@news-server.bigpond.net.au...
>
>
>
>
>
> > On Sat, 19 Jul 2008 01:30:48 -0700 (PDT), fj <francois.j...@irsn.fr> wr=
ote:
> > > On 19 juil, 06:34, Brian Salter-Duke <b_d...@bigpond.net.invalid>
> > > wrote:
> > >> On Fri, 18 Jul 2008 20:06:21 -0700, Walter Spector <w6ws_xthiso...@e=
arthlink.net> wrote:
> > >> > Brian Salter-Duke wrote:
> > >> >> ... I think those people who look after
> > >> >> large scientific codes are mostly trying to add new features whil=
e
> > >> >> ensuring they can be compiled with all existing compilers that ha=
ve been
> > >> >> used previously.
>
> > >> > It is now mid-2008. =EF=BF=BDAny modern compiler supports F95, and=
 has for
> > >> > some years. =EF=BF=BDSome vendors phased out their F77 compilers o=
ver 10
> > >> > years ago. =EF=BF=BDNo need to support a seperate F77 compiler as,=
 modulo
> > >> > a very few minor issues, F77 is a subset of F90.
>
> > >> > > These code writers have many other responsibilities in
> > >> >> most cases. My own involvement is with a relatively small computa=
tional
> > >> >> chemistry code that can either stand alone or interface to GAMESS=
(US) or
> > >> >> Gaussian. So I see some of the issues from outside but close and =
some
> > >> >> from a smaller piece of code. I am far too busy to work on upgrad=
ing the
> > >> >> code to F90 or more recent. I also think it would cause more prob=
lems
> > >> >> than it would solve.
>
> > >> > Why would it cause more problems that it would solve?
>
> > >> First, it is highly likely that in doing the upgrade I would introdu=
ce
> > >> bugs, given that my experience with F77 is so much greater than that=
 of
> > >> F90 and more recent.
>
> > > No : this is wrong. My experience shows (and like you I had a large
> > > experience with F77) that the F95 programming is safer than the F77
> > > one if you apply the F95 style (routines within modules and accessibl=
e
> > > only via a USE statement). This is simply because the F95 compilers
> > > are able to check the programming in a much more efficient way.
>
> > You could well be right in what you say, but I was not talking about
> > writing code from scratch. I was talking about rewriting existing code.
> > Then "if it ain't broke, don't fix it". If it works, any change has the
> > chance of stopping it working.
>
> On the contrary, using a modern compiler is going to
> find bugs in the program that have not been detected
> previously.
> I have converted many old codes, and found this to be
> true time and time again.
>
>
>
>
>
> > > If you impose in addition F2003 rules (trying to allocate only
> > > allocatable arrays and to use pointer just to point to a memory area
> > > already allocated), then you also avoid most of the bugs connected to
> > > dynamic allocation and, for instance, very difficult to find in C or =
C+
> > > + programming.
>
> > >> Second, since my code has to interface with other
> > >> codes and they are not likely to move away from f77 for a while, thi=
s
> > >> would likely introduce bugs or problems. A lot of the code is COMMON
> > >> areas in my code being the same as those in say GAMESS.
>
> > > COMMONs remain available with any FORTRAN version. And the "rules" I
> > > proposed before do not concern data management.
>
> > >> >> I also find it interesting that when people do decide to write a =
new
> > >> >> piece of code in my area, they do not choose Fortran. They choose=
 C
> > >> >> and/or C++.
> > >> > Given the choice of F77 or C++, I would take C++ any day.
>
> > >> But the choice is between F90 or F95 or whatever and C++ as Richard
> > >> points out in his comment. Authors are not chosing more recent Fortr=
an
> > >> versions for computational chemistry code as far as I can see. They =
are
> > >> doing that for a reason.
>
> > > The only reason I see is the school ! Young people do not learn
> > > FORTRAN at school anymore. And the C syntax is the norm today (C, C++=
,
> > > JAVA, C#).
>
> > No, the authors of at least two major comp chem codes in C/C++ were wel=
l
> > versed in Fortran 77 to my knowledge.
>
> And not F90 or 95?- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

I agree that exposing codes to a different compiler frequently finds
bugs. However, I suspect that this is more often that it is a
different compiler rather that that it is a more modern one. I
suspect, for example, that FTN77 would pick up previously undetected
bugs.

And, of course, there is the possiblility that the bugs are detected,
not inthe program, but in the new compiler!

Dave Flower

"David Flower" <DavJFlower@aol.com> wrote in message
news:a1388cce-703a-4f6d-b5fc-114ce1c39cca@f36g2000hsa.googlegroups.com...
On Jul 22, 6:34?am, "robin" <robi...@bigpond.com> wrote:
> "Brian Salter-Duke" <b_d...@bigpond.net.invalid> wrote in message
>
> news:Niigk.20898$IK1.15906@news-server.bigpond.net.au...
> > On Sat, 19 Jul 2008 01:30:48 -0700 (PDT), fj <francois.j...@irsn.fr> wrote:
> > > On 19 juil, 06:34, Brian Salter-Duke <b_d...@bigpond.net.invalid>
> > > wrote:
> > >> On Fri, 18 Jul 2008 20:06:21 -0700, Walter Spector <w6ws_xthiso...@earthlink.net> wrote:
> > >> > Brian Salter-Duke wrote:
> > >> >> ... I think those people who look after
> > >> >> large scientific codes are mostly trying to add new features while
> > >> >> ensuring they can be compiled with all existing compilers that have been
> > >> >> used previously.
>
> > >> > It is now mid-2008. ?Any modern compiler supports F95, and has for
> > >> > some years. ?Some vendors phased out their F77 compilers over 10
> > >> > years ago. ?No need to support a seperate F77 compiler as, modulo
> > >> > a very few minor issues, F77 is a subset of F90.
>
> > >> > > These code writers have many other responsibilities in
> > >> >> most cases. My own involvement is with a relatively small computational
> > >> >> chemistry code that can either stand alone or interface to GAMESS(US) or
> > >> >> Gaussian. So I see some of the issues from outside but close and some
> > >> >> from a smaller piece of code. I am far too busy to work on upgrading the
> > >> >> code to F90 or more recent. I also think it would cause more problems
> > >> >> than it would solve.
>
> > >> > Why would it cause more problems that it would solve?
>
> > >> First, it is highly likely that in doing the upgrade I would introduce
> > >> bugs, given that my experience with F77 is so much greater than that of
> > >> F90 and more recent.
>
> > > No : this is wrong. My experience shows (and like you I had a large
> > > experience with F77) that the F95 programming is safer than the F77
> > > one if you apply the F95 style (routines within modules and accessible
> > > only via a USE statement). This is simply because the F95 compilers
> > > are able to check the programming in a much more efficient way.
>
> > You could well be right in what you say, but I was not talking about
> > writing code from scratch. I was talking about rewriting existing code.
> > Then "if it ain't broke, don't fix it". If it works, any change has the
> > chance of stopping it working.
>
> On the contrary, using a modern compiler is going to
> find bugs in the program that have not been detected
> previously.
> I have converted many old codes, and found this to be
> true time and time again.
>
> > > If you impose in addition F2003 rules (trying to allocate only
> > > allocatable arrays and to use pointer just to point to a memory area
> > > already allocated), then you also avoid most of the bugs connected to
> > > dynamic allocation and, for instance, very difficult to find in C or C+
> > > + programming.
>
> > >> Second, since my code has to interface with other
> > >> codes and they are not likely to move away from f77 for a while, this
> > >> would likely introduce bugs or problems. A lot of the code is COMMON
> > >> areas in my code being the same as those in say GAMESS.
>
> > > COMMONs remain available with any FORTRAN version. And the "rules" I
> > > proposed before do not concern data management.
>
> > >> >> I also find it interesting that when people do decide to write a new
> > >> >> piece of code in my area, they do not choose Fortran. They choose C
> > >> >> and/or C++.
> > >> > Given the choice of F77 or C++, I would take C++ any day.
>
> > >> But the choice is between F90 or F95 or whatever and C++ as Richard
> > >> points out in his comment. Authors are not chosing more recent Fortran
> > >> versions for computational chemistry code as far as I can see. They are
> > >> doing that for a reason.
>
> > > The only reason I see is the school ! Young people do not learn
> > > FORTRAN at school anymore. And the C syntax is the norm today (C, C++,
> > > JAVA, C#).
>
> > No, the authors of at least two major comp chem codes in C/C++ were well
> > versed in Fortran 77 to my knowledge.
>
> And not F90 or 95?- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

>I agree that exposing codes to a different compiler frequently finds
>bugs. However, I suspect that this is more often that it is a
>different compiler rather that that it is a more modern one.

Quite the contrary, it has little or nothing to do with the compiler
being different or being more modern.
It is due to the fact that F90 compiler is able to diagnose
more errors in free source form can an F77 compiler in fixed
source form.

> I suspect, for example, that FTN77 would pick up previously undetected
bugs.

It might, but unlikely, as there has been less development in that
area, and the fact that F77 source admits of limited scope
for detecting errors.

>And, of course, there is the possiblility that the bugs are detected,
>not inthe program, but in the new compiler!

anything is possible, but that is unlikely as F77 source
is less demanding than  F90 source, and manufacturers
have had lots of F77 source to practice on.

In <4884dc08$0$7363$607ed4bc@cv.net>, on 07/21/2008
   at 02:56 PM, John W Kennedy <jwkenne@attglobal.net> said:

>Both hardware binary floating point and hardware decimal floating point 
>in one machine?

Yes.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

robin wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:A_ydnYBptMkY-R3VnZ2dnUVZ_uGdnZ2d@comcast.com...
>> robin wrote:
>>> glen herrmannsfeldt wrote in message ...
>>>> robin wrote:
>>>> (snip)
>>>>> For non IEEE and double words, IBM hardware allowed
>>>>> for hex float with 53 maximum guaranteed binary bits, hence
>>>>> it could not "round up" to 54 because the hardware
>>>>> could not support it.
>>>> Extended precision hardware has existed since the
>>>> 360/85,
>>> But not on the S/360 series generally.
>> No, but they supplied an emulator.
> 
> Not on any of the other 360 systems of which I am aware.
> It was not introduced until the /370, and then only
> as A, S, and M.

No, 128-bit hex floating point was introduced on the 85, was also found 
on the 195, and was provided by software emulation on all other models 
running OS/360 -- emulation was necessary for the DXR instruction, 
anyway, which didn't appear in hardware until much later, although it 
was architected and generated as compiler output for compilers that 
supported it.


>> The original comment applies to the Optimizing compiler
>> and later ones.  (F) didn't support extended precision.

> Of course not, because it wasn't available on the hardware.

It was not implemented as hardware in the 360, except for the 85 and 
195, but it was available via software emulation. However, it was not 
supported by any free OS/360 compiler; you had to get the Optimizer or 
the Checker for PL/I, and H Extended, or, later, VS FORTRAN, for FORTRAN.

> If it does not exist, it doesn't exist.

That amounts to a claim that every S/360 Principles of Operation manual 
has been burnt.

> IBM's PL/I compiler for OS/2 implemented floating-point
> in software.

If it did, then it was years behind the state of the art; normal OS/2 
compilers used 80387 code that could be resolved by an emulator if the 
chip were not present.

-- 
John W. Kennedy
  "...if you had to fall in love with someone who was evil, I can see 
why it was her."
   -- "Alias"

In <BqmdnZnAiLSZmBjVnZ2dnUVZ_ozinZ2d@comcast.com>, on 07/21/2008
   at 02:52 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>I think we have had this discussion before, though I may
>not be convinced.  By floating point hardware, I would mean
>hardware that can do floating point addition, subtraction,
>multiplication, or division of floating point numbers.

Il va sans dire. It existed in the 1950's. It existed on a non-IBM machine
in the 1960's, at least one of which had both floating binary and floating
decimal.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

In <4884dc08$0$7363$607ed4bc@cv.net>, on 07/21/2008
   at 02:56 PM, John W Kennedy <jwkenne@attglobal.net> said:

>Both hardware binary floating point and hardware decimal floating point 
>in one machine?

Yes.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
> 
> >I think we have had this discussion before, though I may
> >not be convinced.  By floating point hardware, I would mean
> >hardware that can do floating point addition, subtraction,
> >multiplication, or division of floating point numbers.
> 
> Il va sans dire.
  ^^^^^^^^^^^^^^^
  Latin?

> It existed in the 1950's. It existed on a non-IBM machine
> in the 1960's, at least one of which had both floating binary
> and floating decimal.

Everett M. Greene wrote:
> Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>>
>>> I think we have had this discussion before, though I may
>>> not be convinced.  By floating point hardware, I would mean
>>> hardware that can do floating point addition, subtraction,
>>> multiplication, or division of floating point numbers.
>> Il va sans dire.
>   ^^^^^^^^^^^^^^^
>   Latin?

It goes with out saying that it isn't Latin, but French. ;)


> 
>> It existed in the 1950's. It existed on a non-IBM machine
>> in the 1960's, at least one of which had both floating binary
>> and floating decimal.

Curious.  Do you remember the name of the machine, or the manufacturer?

LR

LR <lruss@superlink.net> writes:
> Everett M. Greene wrote:
> > Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:
> >> glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
> >>
> >>> I think we have had this discussion before, though I may
> >>> not be convinced.  By floating point hardware, I would mean
> >>> hardware that can do floating point addition, subtraction,
> >>> multiplication, or division of floating point numbers.
> >> Il va sans dire.
> >  ^^^^^^^^^^^^^^^
> >   Latin?
> 
> It goes with out saying that it isn't Latin, but French. ;)

My knowledge of French is about the same as my knowledge of
Latin.  Anyone care to translate it?

Everett M. Greene wrote:
> LR <lruss@superlink.net> writes:
>> Everett M. Greene wrote:
>>> Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:
>>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>>>> Il va sans dire.
>>>  ^^^^^^^^^^^^^^^
>>>   Latin?
>> It goes with out saying that it isn't Latin, but French. ;)
> 
> My knowledge of French is about the same as my knowledge of
> Latin.  Anyone care to translate it?

It goes without saying.

LR

In <20080728.7A3B0E8.6C5F@mojaveg.lsan.mdsg-pacwest.com>, on 07/28/2008
   at 07:14 AM, mojaveg@mojaveg.lsan.mdsg-pacwest.com (Everett M. Greene)
said:

>  Latin?

French. The phrase means that it goes without saying.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

In <488e1685$0$19702$cc2e38e6@news.uslec.net>, on 07/28/2008
   at 02:58 PM, LR <lruss@superlink.net> said:

>Curious.  Do you remember the name of the machine, or the manufacturer?

Yes. RCA 601. Possibly the Burroughs B6500 as well, but I'd have to look
that one up.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

LR <lruss@superlink.net> writes:
> Everett M. Greene wrote:
> > LR <lruss@superlink.net> writes:
> >> Everett M. Greene wrote:
> >>> Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:
> >>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
> 
> >>>> Il va sans dire.
> >>>  ^^^^^^^^^^^^^^^
> >>>   Latin?
> >> It goes with out saying that it isn't Latin, but French. ;)
> > 
> > My knowledge of French is about the same as my knowledge of
> > Latin.  Anyone care to translate it?
> 
> It goes without saying.

What goes without saying?  :-)

Who's on first?

Shmuel (Seymour J.) Metz wrote:
> In <488e1685$0$19702$cc2e38e6@news.uslec.net>, on 07/28/2008
>    at 02:58 PM, LR <lruss@superlink.net> said:
> 
>> Curious.  Do you remember the name of the machine, or the manufacturer?
> 
> Yes. RCA 601

You sure? BitSavers doesn't, unfortunately, have the relevant manual, 
but the Assembler manual has a list of opcodes, with:

Add Word Decimal
Add Word Binary
Add Halfword Decimal
Add Halfword Binary
Add Symbol/Field Controlled
Add Character Address
Add Halfword Address
Add to Address Register

> the Burroughs B6500 as well, but I'd have to look
> that one up.


-- 
John W. Kennedy
  "Though a Rothschild you may be
In your own capacity,
     As a Company you've come to utter sorrow--
But the Liquidators say,
'Never mind--you needn't pay,'
     So you start another company to-morrow!"
   -- Sir William S. Gilbert.  "Utopia Limited"

"John W Kennedy" <jwkenne@attglobal.net> wrote in message news:488ab10b$0$7355$607ed4bc@cv.net...
> robin wrote:
> > "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> > news:A_ydnYBptMkY-R3VnZ2dnUVZ_uGdnZ2d@comcast.com...
> >> robin wrote:
> >>> glen herrmannsfeldt wrote in message ...
> >>>> robin wrote:
> >>>> (snip)
> >>>>> For non IEEE and double words, IBM hardware allowed
> >>>>> for hex float with 53 maximum guaranteed binary bits, hence
> >>>>> it could not "round up" to 54 because the hardware
> >>>>> could not support it.
> >>>> Extended precision hardware has existed since the
> >>>> 360/85,
> >>> But not on the S/360 series generally.
> >> No, but they supplied an emulator.
> >
> > Not on any of the other 360 systems of which I am aware.
> > It was not introduced until the /370, and then only
> > as A, S, and M.
>
> No, 128-bit hex floating point was introduced on the 85, was also found
> on the 195, and was provided by software emulation on all other models
> running OS/360 -- emulation was necessary for the DXR instruction,
> anyway, which didn't appear in hardware until much later, although it
> was architected and generated as compiler output for compilers that
> supported it.
>
> >> The original comment applies to the Optimizing compiler
> >> and later ones.  (F) didn't support extended precision.
>
> > Of course not, because it wasn't available on the hardware.
>
> It was not implemented as hardware in the 360, except for the 85 and
> 195, but it was available via software emulation. However, it was not
> supported by any free OS/360 compiler; you had to get the Optimizer or
> the Checker for PL/I, and H Extended, or, later, VS FORTRAN, for FORTRAN.
>
> > If it does not exist, it doesn't exist.
>
> That amounts to a claim that every S/360 Principles of Operation manual
> has been burnt.
>
> > IBM's PL/I compiler for OS/2 implemented floating-point
> > in software.
>
> If it did, then it was years behind the state of the art; normal OS/2
> compilers used 80387 code that could be resolved by an emulator if the
> chip were not present.

You are contradicting yourself.
Most of the early PCs did not have the float hardware,
and F.P. computation was performed in software,
whether under OS/2 or MS DOS or DR DOS.

In <4890aabd$0$7332$607ed4bc@cv.net>, on 07/30/2008
   at 01:52 PM, John W Kennedy <jwkenne@attglobal.net> said:

>You sure?

I may be thinking of its big brother the RCA 604; my 601 manual doesn't
list floating point at all.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

Shmuel (Seymour J.) Metz wrote:
(snip)

> I may be thinking of its big brother the RCA 604; my 601 manual doesn't
> list floating point at all.

http://www.bitsavers.org/pdf/rca/601/601-01-00_RCA601_FunctSpec_Apr60.pdf

Seems to include the 601, 602, 603, and 604, though with little
detail of each.

For the 604 it does indicate:

"High speed Arithmetic Unit: Provides the circuits required
for high-speed, parallel word, fixed- and floating-point
binary and decimal arithmetic operations."

1.5us memory cycle,

10 us for 11 by 11 digit fixed or floating point multiply.
(It doesn't say binary or decimal digits, though.)

56 bit words, so 11 BCD digits in 44 bits (I assume they
didn't have the coding that IBM now uses).

BCD digit serial doesn't take a huge amount of logic, though
still a pretty good amount for the time.  I can imagine the
same logic being used for BCD digit or hex digit serial
multiply or divide.

That is all it says about it, though.

-- glen

In <gdKdneIzKNQBNQ_VnZ2dnUVZ_gGdnZ2d@comcast.com>, on 07/31/2008
   at 11:10 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>56 bit words, so 11 BCD digits in 44 bits (I assume they
>didn't have the coding that IBM now uses).

No. Each halfword had 24 data bits, three tag bits and one parity bits.

>That is all it says about it, though.

That's a shame; the CPD, 601 and 604 were fascinating machines.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Shmuel (Seymour J.) Metz wrote:
> (snip)
> 
> > I may be thinking of its big brother the RCA 604; my 601 manual doesn't
> > list floating point at all.
> 
> http://www.bitsavers.org/pdf/rca/601/601-01-00_RCA601_FunctSpec_Apr60.pdf
> 
> Seems to include the 601, 602, 603, and 604, though with little
> detail of each.
> 
> For the 604 it does indicate:
> 
> "High speed Arithmetic Unit: Provides the circuits required
> for high-speed, parallel word, fixed- and floating-point
> binary and decimal arithmetic operations."
> 
> 1.5us memory cycle,
> 
> 10 us for 11 by 11 digit fixed or floating point multiply.
> (It doesn't say binary or decimal digits, though.)
> 
> 56 bit words, so 11 BCD digits in 44 bits (I assume they
> didn't have the coding that IBM now uses).
> 
> BCD digit serial doesn't take a huge amount of logic, though
> still a pretty good amount for the time.  I can imagine the
> same logic being used for BCD digit or hex digit serial
> multiply or divide.
> 
> That is all it says about it, though.

While we're on the subject of BCD arithmetic, is there anything
readily available describing how BCD multiplication and division
are done?  I would suspect that something more sophisticated
is done than multiplying by adding the multiplicand n times to
the partial product for each multiplier digit.

Everett M. Greene wrote:
> While we're on the subject of BCD arithmetic, is there anything
> readily available describing how BCD multiplication and division
> are done?  I would suspect that something more sophisticated
> is done than multiplying by adding the multiplicand n times to
> the partial product for each multiplier digit.

There is no one answer. That's exactly what the old IBM 1401 did, but 
its contemporary, the 1620, could directly multiply two one-digit 
numbers. On modern machines, only the circuit designer knows for sure.
-- 
John W. Kennedy
  "You can, if you wish, class all science-fiction together; but it is 
about as perceptive as classing the works of Ballantyne, Conrad and W. 
W. Jacobs together as the 'sea-story' and then criticizing _that_."
   -- C. S. Lewis.  "An Experiment in Criticism"

glen herrmannsfeldt wrote:
> Shmuel (Seymour J.) Metz wrote:
> (snip)
> 
>> I may be thinking of its big brother the RCA 604; my 601 manual doesn't
>> list floating point at all.
> 
> http://www.bitsavers.org/pdf/rca/601/601-01-00_RCA601_FunctSpec_Apr60.pdf
> 
> Seems to include the 601, 602, 603, and 604, though with little
> detail of each.
> 
> For the 604 it does indicate:
> 
> "High speed Arithmetic Unit: Provides the circuits required
> for high-speed, parallel word, fixed- and floating-point
> binary and decimal arithmetic operations."
> 
> 1.5us memory cycle,
> 
> 10 us for 11 by 11 digit fixed or floating point multiply.
> (It doesn't say binary or decimal digits, though.)
> 
> 56 bit words, so 11 BCD digits in 44 bits (I assume they
> didn't have the coding that IBM now uses).

IBM's 8-bit coding is "Extended BCD Interchange Code", "EBCDIC"; it 
replaced IBM's older 6-bit coding, which was called "BCD" at the time, 
but was later retronymed "BCDIC" to distinguish it from 4-bit simple BCD.

But not all 4-bit decimal codes are BCD. There was, for example, 
excess-3 coding, which coded 0 as 0011, 1 as 0100, 2 as 0101, and so on; 
it had certain advantages in designing arithmetic circuits.

Other codes have been used, too, such as 2-of-5 code (two ones and three 
zeros), or bi-quinary (two bits either 01 or 10 plus five bits of four 
zeros and one one, for a total of seven).


-- 
John W. Kennedy
  "Never try to take over the international economy based on a radical 
feminist agenda if you're not sure your leader isn't a transvestite."
   -- David Misch:  "She-Spies", "While You Were Out"

John W Kennedy wrote:
(snip)

>> 56 bit words, so 11 BCD digits in 44 bits (I assume they
>> didn't have the coding that IBM now uses).

> IBM's 8-bit coding is "Extended BCD Interchange Code", "EBCDIC"; it 
> replaced IBM's older 6-bit coding, which was called "BCD" at the time, 
> but was later retronymed "BCDIC" to distinguish it from 4-bit simple BCD.

I was referring to the code used by IBM's decimal floating
point format which stores three digits in 10 bits, plus one
additional decimal digit that shares its bits with the exponent
field.  The result is a very efficient decimal float format.
(It might convert to ordinary BCD when loaded into registers.)

-- glen

glen herrmannsfeldt wrote:
> John W Kennedy wrote:
> (snip)
> 
>>> 56 bit words, so 11 BCD digits in 44 bits (I assume they
>>> didn't have the coding that IBM now uses).
> 
>> IBM's 8-bit coding is "Extended BCD Interchange Code", "EBCDIC"; it 
>> replaced IBM's older 6-bit coding, which was called "BCD" at the time, 
>> but was later retronymed "BCDIC" to distinguish it from 4-bit simple BCD.
> 
> I was referring to the code used by IBM's decimal floating
> point format which stores three digits in 10 bits, plus one
> additional decimal digit that shares its bits with the exponent
> field.  The result is a very efficient decimal float format.

That's IEEE's format, not IBM's, although the three-digits-in-10-bits 
encoding itself, Densely Packed Decimal, was developed by IBM's Mike 
Cowlishaw, based on Chen-Ho coding, developed at IBM in the 70s.

> (It might convert to ordinary BCD when loaded into registers.)

I'm sure it does. The conversions between 10-bit DPD and 12-bit BCD are 
fairly simple and should be quite fast if implemented in a special 
circuit, but trying to do arithmetic on it would be insane.

-- 
John W. Kennedy
  "I want everybody to be smart. As smart as they can be. A world of 
ignorant people is too dangerous to live in."
   -- Garson Kanin. "Born Yesterday"

John W Kennedy wrote:
(snip, I wrote)

>> I was referring to the code used by IBM's decimal floating
>> point format which stores three digits in 10 bits, plus one
>> additional decimal digit that shares its bits with the exponent
>> field.  The result is a very efficient decimal float format.

> That's IEEE's format, not IBM's, although the three-digits-in-10-bits 
> encoding itself, Densely Packed Decimal, was developed by IBM's Mike 
> Cowlishaw, based on Chen-Ho coding, developed at IBM in the 70s.

I thought it was IBM's first, and that the IEEE standard
wasn't final yet, but then I might have missed it even
if it was final.

-- glen

"John W Kennedy" <jwkenne@attglobal.net> wrote in message news:48939752$0$4999$607ed4bc@cv.net...
> Everett M. Greene wrote:
> > While we're on the subject of BCD arithmetic, is there anything
> > readily available describing how BCD multiplication and division
> > are done?  I would suspect that something more sophisticated
> > is done than multiplying by adding the multiplicand n times to
> > the partial product for each multiplier digit.
>
> There is no one answer. That's exactly what the old IBM 1401 did, but
> its contemporary, the 1620, could directly multiply two one-digit
> numbers.

By table lookup, I think.

> On modern machines, only the circuit designer knows for sure.

glen herrmannsfeldt wrote:
> John W Kennedy wrote:
> (snip, I wrote)
> 
>>> I was referring to the code used by IBM's decimal floating
>>> point format which stores three digits in 10 bits, plus one
>>> additional decimal digit that shares its bits with the exponent
>>> field.  The result is a very efficient decimal float format.
> 
>> That's IEEE's format, not IBM's, although the three-digits-in-10-bits 
>> encoding itself, Densely Packed Decimal, was developed by IBM's Mike 
>> Cowlishaw, based on Chen-Ho coding, developed at IBM in the 70s.
> 
> I thought it was IBM's first, and that the IEEE standard
> wasn't final yet, but then I might have missed it even
> if it was final.

IBM implemented it before it was final, just as Intel did a generation 
ago with the original IEEE-754. But the IEEE-754r project goes back to 2000.
-- 
John W. Kennedy
  Read the remains of Shakespeare's lost play, now annotated!
http://pws.prserv.net/jwkennedy/Double%20Falshood/index.html

"robin" <robin_v@bigpond.com> writes:
> "John W Kennedy" <jwkenne@attglobal.net> wrote
> > Everett M. Greene wrote:
> > > While we're on the subject of BCD arithmetic, is there anything
> > > readily available describing how BCD multiplication and division
> > > are done?  I would suspect that something more sophisticated
> > > is done than multiplying by adding the multiplicand n times to
> > > the partial product for each multiplier digit.
> >
> > There is no one answer. That's exactly what the old IBM 1401 did, but
> > its contemporary, the 1620, could directly multiply two one-digit
> > numbers.
> 
> By table lookup, I think.

I would think so, too.

> > On modern machines, only the circuit designer knows for sure.

Where do these designers hide?  Have they ever written anything
for the rest of us to read?

In <20080804.79C5538.8FE7@mojaveg.lsan.mdsg-pacwest.com>, on 08/04/2008
   at 09:36 AM, mojaveg@mojaveg.nodomain (Everett M. Greene) said:

>Where do these designers hide?  Have they ever written anything for the
>rest of us to read?

I don't know what the situation is now, but there was a time when the CE
manuals could be purchased by the general public. Some of the high speed
arithmetic documentation was a bit of a heavy read.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

Shmuel (Seymour J.) Metz wrote:
> In <20080804.79C5538.8FE7@mojaveg.lsan.mdsg-pacwest.com>, on 08/04/2008
>    at 09:36 AM, mojaveg@mojaveg.nodomain (Everett M. Greene) said:

>>Where do these designers hide?  Have they ever written anything for the
>>rest of us to read?

> I don't know what the situation is now, but there was a time when the CE
> manuals could be purchased by the general public. Some of the high speed
> arithmetic documentation was a bit of a heavy read.

Much of the 360/91 design was published in the IBM Research
and Development Journal, and is also included in most books
on pipelined processors.  Between that journal, and the
IBM Systems Journal there is a lot of information on how
IBM did things.

Also, they used to publish instruction timing information
which was sometimes useful to understand how the processors
worked internally.

-- glen

John W Kennedy wrote:

> There is no one answer. That's exactly what the old IBM 1401 did, but 
> its contemporary, the 1620, could directly multiply two one-digit 
> numbers. On modern machines, only the circuit designer knows for sure.

As I understand the 1620, the unusual feature was that the
table was user accessible.

Otherwise, table lookup is a popular logic design
technique.  FPGAs use table lookup to do just
about all logic functions.  A 16 bit table indexed
by four bits can perform any four input logical
operation.  That is the building block of most
programmable logic.

-- glen

In <F-idnWmgR7guqgXVnZ2dnUVZ_v3inZ2d@comcast.com>, on 08/05/2008
   at 04:22 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>Also, they used to publish instruction timing information
>which was sometimes useful to understand how the processors
>worked internally.

I used the CE manuals for that. But the last time that I saw instruction
timings, they were too complicated for practical use, and I'm sure that
it's worse now.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

In <MrednS5ov_dapAXVnZ2dnUVZ_o_inZ2d@comcast.com>, on 08/05/2008
   at 04:31 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>As I understand the 1620, the unusual feature was that the
>table was user accessible.

Perhaps unusual, but IBM wasn't the only vendor to use an add table.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

Everett M. Greene wrote:
> "robin" <robin_v@bigpond.com> writes:
>> "John W Kennedy" <jwkenne@attglobal.net> wrote
>>> Everett M. Greene wrote:
>>>> While we're on the subject of BCD arithmetic, is there anything
>>>> readily available describing how BCD multiplication and division
>>>> are done?  I would suspect that something more sophisticated
>>>> is done than multiplying by adding the multiplicand n times to
>>>> the partial product for each multiplier digit.

>>> There is no one answer. That's exactly what the old IBM 1401 did, but
>>> its contemporary, the 1620, could directly multiply two one-digit
>>> numbers.

>> By table lookup, I think.

> I would think so, too.

Yes, but the point is that its multiply instruction /used/ that, whereas 
the 1401 multiply instruction didn't. To multiply 123 by 45, the 1401 
literally added 123+123+123+123+123+1230+1230+1230+1230. The 1620 added 
15+100+500+120+800+4000.

>>> On modern machines, only the circuit designer knows for sure.

> Where do these designers hide?  Have they ever written anything
> for the rest of us to read?

Somewhere, I'm sure, but not, as a rule, in the main programmer's 
documentation. Such detail was common in the pre-360 era, because there 
was no clear conception of an architecture divorced from its hardware 
implementation, and because it was often important to have a good idea 
of how long an instruction took to execute. (For example, the 1401 had 
an opcode that amounted to "start moving a card through the card reader; 
I swear I'll issue the actual read instruction before it's too late." To 
use it, you had to be able to calculate how many milliseconds would 
elapse in any calculations you performed between the two instructions; 
the 1401 had no interrupts.)

-- 
John W. Kennedy
  "...if you had to fall in love with someone who was evil, I can see 
why it was her."
   -- "Alias"

Shmuel (Seymour J.) Metz wrote:
> In <MrednS5ov_dapAXVnZ2dnUVZ_o_inZ2d@comcast.com>, on 08/05/2008
>    at 04:31 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
> 
>> As I understand the 1620, the unusual feature was that the
>> table was user accessible.

The addition and multiplication tables were, in fact, was in perfectly 
ordinary low core (RAM), and had to be loaded by the bootstrap.

> Perhaps unusual, but IBM wasn't the only vendor to use an add table.

The faster 1620-2 didn't have an add table, though it kept the multiply 
table.

-- 
John W. Kennedy
  "The first effect of not believing in God is to believe in anything...."
   -- Emile Cammaerts, "The Laughing Prophet"

John W Kennedy wrote:
> Everett M. Greene wrote:
>> "robin" <robin_v@bigpond.com> writes:
>>> "John W Kennedy" <jwkenne@attglobal.net> wrote
>>>> Everett M. Greene wrote:
>>>>> While we're on the subject of BCD arithmetic, is there anything
>>>>> readily available describing how BCD multiplication and division
>>>>> are done?  I would suspect that something more sophisticated
>>>>> is done than multiplying by adding the multiplicand n times to
>>>>> the partial product for each multiplier digit.
> 
>>>> There is no one answer. That's exactly what the old IBM 1401 did, but
>>>> its contemporary, the 1620, could directly multiply two one-digit
>>>> numbers.
> 
>>> By table lookup, I think.
> 
>> I would think so, too.
> 
> Yes, but the point is that its multiply instruction /used/ that, whereas 
> the 1401 multiply instruction didn't. To multiply 123 by 45, the 1401 
> literally added 123+123+123+123+123+1230+1230+1230+1230. The 1620 added 
> 15+100+500+120+800+4000.
> 
Sort of. Actually, for each pair of p and q digits, it looked up the two digit 
product in the multiplication table in locations 100-299 and then added this value at 
the appropriate location in the product area using the addition table in locations 
300-399 to perform a 2 digit add with carry propagation. In the example, assuming 
that 123 is the p operand and 45 is the q operand, 15 is added at location 99, 10 at 
location 98, 05 at 97, 12 at 98, 08 at 97, and 04 at 96 leaving the product in 
locations 95-99. The multiply instruction automatically cleared the product area from 
locations 80-99 to zeros. For products longer than 20 digits, it was the programmer's 
responsibility to clear sufficient locations below 80. Very long products could wrap 
around location 0 into high memory addresses.

John W Kennedy wrote:
(snip)

> the 1401 had no interrupts.)

and still doesn't?

http://www.computerhistory.org/restorations/

(also, note the street address of the museum)

-- glen

"John W Kennedy" <jwkenne@attglobal.net> wrote in message news:48a07db2$0$7318$607ed4bc@cv.net...
> Everett M. Greene wrote:
> > "robin" <robin_v@bigpond.com> writes:
> >> "John W Kennedy" <jwkenne@attglobal.net> wrote
> >>> Everett M. Greene wrote:
> >>>> While we're on the subject of BCD arithmetic, is there anything
> >>>> readily available describing how BCD multiplication and division
> >>>> are done?  I would suspect that something more sophisticated
> >>>> is done than multiplying by adding the multiplicand n times to
> >>>> the partial product for each multiplier digit.
>
> >>> There is no one answer. That's exactly what the old IBM 1401 did, but
> >>> its contemporary, the 1620, could directly multiply two one-digit
> >>> numbers.
>
> >> By table lookup, I think.
>
> > I would think so, too.
>
> Yes, but the point is that its multiply instruction /used/ that, whereas
> the 1401 multiply instruction didn't. To multiply 123 by 45, the 1401
> literally added 123+123+123+123+123+1230+1230+1230+1230. The 1620 added
> 15+100+500+120+800+4000.
>
> >>> On modern machines, only the circuit designer knows for sure.
>
> > Where do these designers hide?  Have they ever written anything
> > for the rest of us to read?
>
> Somewhere, I'm sure, but not, as a rule, in the main programmer's
> documentation. Such detail was common in the pre-360 era, because there
> was no clear conception of an architecture divorced from its hardware
> implementation, and because it was often important to have a good idea
> of how long an instruction took to execute. (For example, the 1401 had
> an opcode that amounted to "start moving a card through the card reader;
> I swear I'll issue the actual read instruction before it's too late." To
> use it, you had to be able to calculate how many milliseconds would
> elapse in any calculations you performed between the two instructions;
> the 1401 had no interrupts.)

That was common, right from the early days.
On Pilot ACE (1951), the card reader was started, and the
programmer was then expected to execute an instruction
to read at least the first row of the card.
The read instruction needed to be executed within
160 milliseconds of the start, and the user needed to calculate
the time taken by instructions that he included between
those two events.
Typically, there was no need to do any calculation,
because there was little computing that would be done
after the reader was started.

Similarly, incidentally, for the card punch.

The need to keep a tally of time was necessary in the days
of asynchronous I/O and asynchronous multiply and divide.

Asynchronous operations provided the means to time-share
operations and gain extra speed that way.

In that and subsequent machines asynchronous multiplication
enabled several small integers to be multiplied in succession,
and an automatic shift.  It also enabled conversion to BCD
and (with asynchronous division) conversion from BCD.

In <48a07db2$0$7318$607ed4bc@cv.net>, on 08/11/2008
   at 01:56 PM, John W Kennedy <jwkenne@attglobal.net> said:

>Somewhere, I'm sure, but not, as a rule, in the main programmer's 
>documentation. Such detail was common in the pre-360 era,

I've only seen instruction algorithms in CE manuals.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

Shmuel (Seymour J.) Metz wrote:
> In <48a07db2$0$7318$607ed4bc@cv.net>, on 08/11/2008
>    at 01:56 PM, John W Kennedy <jwkenne@attglobal.net> said:
> 
>> Somewhere, I'm sure, but not, as a rule, in the main programmer's 
>> documentation. Such detail was common in the pre-360 era,
> 
> I've only seen instruction algorithms in CE manuals.

There is considerable detail in, for example, 
<URL:http://www.bitsavers.org/pdf/ibm/14xx/A24-1403-5_1401RefMan_Apr62.pdf>. 
Not as much as in a CE manual, of course, but more than in S/360 
Principles of Operation.

-- 
John W. Kennedy
  "Though a Rothschild you may be
In your own capacity,
     As a Company you've come to utter sorrow--
But the Liquidators say,
'Never mind--you needn't pay,'
     So you start another company to-morrow!"
   -- Sir William S. Gilbert.  "Utopia Limited"

John W Kennedy wrote:
(snip)

> There is considerable detail in, for example, 
> <URL:http://www.bitsavers.org/pdf/ibm/14xx/A24-1403-5_1401RefMan_Apr62.pdf>. 
> Not as much as in a CE manual, of course, but more than in S/360 
> Principles of Operation.

Implementation details shouldn't be in Principles of Operation,
but some could be in the Functional Characteristics manuals for
individual processors.  Details such as ALU width and memory
width are given for some processors, but not much more than that.

You can get some from the timing information in the Functional
Characteristics manuals.  The timing for MVC on some shows faster
times for multiples of eight bytes appropriately aligned indicating
eight byte hardware.

-- glen

In <XqidnaM0upDpQDTVnZ2dnUVZ_u6dnZ2d@comcast.com>, on 08/18/2008
   at 01:37 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>You can get some from the timing information in the Functional
>Characteristics manuals.

The old ones; IBM dropped it for the newer processors. The formulae were
getting too complex to be useful by then.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

Shmuel (Seymour J.) Metz wrote:

> In <XqidnaM0upDpQDTVnZ2dnUVZ_u6dnZ2d@comcast.com>, on 08/18/2008
>    at 01:37 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>>You can get some from the timing information in the Functional
>>Characteristics manuals.

> The old ones; IBM dropped it for the newer processors. The formulae were
> getting too complex to be useful by then.

I haven't seen a Functional Characteristics manual for a newer
processor.  Maybe for the 3168, and that might not have had
timings.   It seems that there is a Functional Characteristics
manual for the ES/9000, and it doesn't have timings.  Otherwise,
they seem to be pretty rare.

-- glen