HDTenEightyP/NetNews huggingface dataset:
From: i2041101@rzphy1.rz.tu-bs.de (Paulini)
Subject: Re: Welcome to HPFF
Keywords: HPFF, High Performance Fortran
Organization: TU Braunschweig, Informatik, Bueltenweg, Germany
Date: Fri, 14 Aug 1992 09:29:52 GMT

In article <Bsy43C.9BG@rice.edu>, chk@rice.edu (Charles Koelbel) writes:
|> 
|> Welcome to the High Performance Fortran Forum!
|> 
|> 
|> WHAT IS HPFF?
|> =============
|> 
|>      ..... deleted ....
|>
|> Our intent is to develop extensions to Fortran which
|> provide support for high performance programming on a wide variety of
|> machines, including massively parallel SIMD and MIMD systems and
|> vector processors.  Some of the topics considered will be
|> 
|>      ..... deleted ....
 
Stop it! I'm programming now for several years scientific applications
in FORTRAN 77 because I must do it, due to libraries and already existing
programs in FORTRAN. Compared to other languages (even to cryptic C - Codes)
FORTRAN is not recommendable as a programming language at all. It is merely
a collection of erratic ideas and lacks a real conception. In my opinion it is
not useful to make any extensions or "improvements" to the language (this also
holds true for Fortran 90). A better way seems to me to design a comptetely
new language or to use an existing better (like C, Ada, Modula or whatever).
And then to decide no longer to support programming in FORTRAN but to use
existing FORTRAN codes in the new language in a portable way (e.g. by defining
an interface or a standard linking method or something similar).

The situation now is that people who are used to a 'real' programming language
(mostly C) only write programs in FORTRAN if there is no other way ... like me.
If in some years most of the numeric software is available in C, all new
numeric programmers won't code in FORTRAN and many of the old will convert too.


-- 
#-----------------------------------------------------------------------------#
# Joachim Paulini                                                             #
#                                            Tel    (0531) 391-5190           #
# TU Braunschweig                            Fax    (0531) 391-5833           #
# Institut f. Theoretische Physik            e-mail i2041101@ws.rz.tu-bs.de   #
# Mendelssohnstrasse 3                              i2041101@dbstu1.bitnet    #
# 3300 Braunschweig / Germany                                                 #
#-----------------------------------------------------------------------------#
Newsgroups: comp.lang.fortran
Subject: Re: programming style question
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Thu, 13 Aug 1992 00:40:56 GMT
Organization: University of Auckland, New Zealand.

tholen@galileo.ifa.hawaii.edu (Dave Tholen) writes:

>A question about programming style:  How many of you explicitly OPEN
>preconnected units, which nowadays usually mean standard input, standard
>output, and sometimes standard error (typically units 5, 6, and 0)?  In
>the old days, 5 and 6 were often card reader and printer.

I have done work on both an MVS system and Unix boxes. In MVS, I only
very rarely open a unit explicitly (for example when I loop over all the
members in a PDS). Usually, I preconnect all the units in the JCL.

It's a real shame that Unix does not have standard way of attatching
FORTRAN units to file descriptors, that would make things much easier.
Does POSIX have anything to say about that?

If I port a program from one machine to the other, I usually manually
insert the necessary OPEN statements, plus the commands to get the
filenames from the command line or to read them from stdin. I have to
do editing anyway, because the syntax of our beloved, non- standard
INCLUDE is different for both machines; it's INCLUDE (MEMBER) for
MVS, and INCLUDE 'header.fi' for Unix.

I don't open anything which I know is preconnected. The needed filenames
are too different, anyway; opening '/dev/tty' under Unix (what about
background jobs, though?) or 'CON' under MS-DOS or... If I have to change
those, I might as well add a few more OPEN's.
-- 
Thomas Koenig, ecmtwhk@ccu1.aukuni.ac.nz, ib09@rz.uni-karlsruhe.de
The joy of engineering is to find a straight line on a double logarithmic
diagram.
From: sandee@Think.COM (Daan Sandee)
Newsgroups: comp.lang.fortran
Subject: Re: Ignoring Least Significant Bit in a Real Compare
Date: 21 Aug 1992 21:12:34 GMT
Organization: TMC
Distribution: world
NNTP-Posting-Host: django.think.com

In article <1992Aug21.203055.29668@aero.org>, wae@aero.org (William A. Emanuelsen) writes:
|> 
|> TEMP1 = 17266436725301415722
|> TEMP2 = 17266436725301415723
|> 
|> They should be equal since TEMP1 is assigned a number,
|> and TEMP2 = TEMP3 + DELTA, where DELTA = TEMP1 - TEMP3.
|> (It's really a bit more complicated than this.)

 This is (as you know) one of the facts of life when using floating point
 arithmetic. The hardware does not guarantee that X+Y-Y is the same as X.
 So my first reaction is, of course : you're SOL.

|> So what I did was to write a logical function, REQ, to replace the .EQ. 
|> comparison:
|> 
|>       LOGICAL FUNCTION REQ(X1,X2)
|>       REQ = .FALSE.
|>       IF (ABS(X1-X2) .LT. EPS) REQ = .TRUE.
|>       RETURN
|>       END
|> 
|> So where I formerly had: IF (TEMP1 .EQ. TEMP2) ...
|> I now have:              IF (REQ(TEMP1,TEMP2)) ...

It would be a lot faster if you had a statement function

        LOGICAL REQ
        REQ(X1,X2) = ABS(X1-X2) .LT. EPS

 Not having an external function call saves two memory writes, an RJ,
 three memory reads, and two EQ (jump) instructions, plus the cost of
 not being able to optimize across a function call.

 Depending on how you use it, it might be faster to have a real function,

       REQ(X1,X2) = ABS(X1-X2) - EPS

 and then test with IF (REQ(X1,X2) .LT. 0.). It would save the compiler
 the trouble of converting the result of the subtract into a logical value.

Daan Sandee                                           sandee@think.com
Thinking Machines Corporation
Cambridge, Mass 02142                                 (617) 234-5044
From: mhiroshi@tansei.cc.u-tokyo.ac.jp (H. Murakami)
Newsgroups: comp.lang.fortran
Subject: Does your f77 compiler accepts this?
Date: 22 Aug 92 13:08:23 GMT
Organization: Hokkaido Univ. However I am subject to tansei for JUNET.

*
*     This is a correct Fortran 77 program (,I think).
*
*     However, many compiler (for example BSD f77) complains
*     there is an error because X is surrounded by the parenthesis.
*     I think only the output-list surrounded by parenthesis
*     which contains more or equal to two items are forbidden.
*
      X = 1.0
      WRITE(*,*) (X)
      END
From: cpg@jet.uk (Dr Chris P Gatcombe)
Newsgroups: comp.lang.fortran
Subject: Re: What extensions do you use?
Date: 14 Aug 92 08:18:36 GMT
Organization: Joint European Torus

In <1992Aug13.004448.4409@ccu1.aukuni.ac.nz> ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig) writes:

>What extensions do you usually use when programming FORTRAN? I try to
>restrict myself to two: Use of INCLUDE statements, without which COMMON
>blocks and PARAMETER statements would be almost impossible, and
>IMPLICIT none. Altough the temptation to use identifiers longer than 6
>letters can be overwhelming, I usually don't because one system I work
>on does not support them; same goes for use of lowercase letters.

>How about you?
>-- 
>Thomas Koenig, ecmtwhk@ccu1.aukuni.ac.nz, ib09@rz.uni-karlsruhe.de

I would _ALWAYS_ try to use IMPLICIT NONE, if it is available on the
compiler (though some compilers allow IMPLICIT UNDEFINED as an
alternative). I like to have all my variables defined explicitly
(I _HATE_ implicit typing). If this was not available, there may be
command-line options to warn about undefined variables.

INCLUDE 'file' is useful as mentioned for definitions of COMMON blocks
and PARAMETERs. I certainly use this in several codes.

I would disagree with the above about using 6-character names. I find
that such variable names make the code very cryptic to read. This
is a facility I would try to use on every system.

I'm probably lucky in that my programs don't get ported to lots
of different machines with their quirky compilers :-)

Chris.
-- 
Dr. Chris Gatcombe
Tessella Support Services plc,       Room K1/0/31,
3 Vineyard Chambers, Abingdon,       JET Joint European Undertaking,
Oxfordshire OX14 3PX, UK.            Abingdon, Oxfordshire OX14 3EA, UK.
Phone:  (+44) (0235) 555511          Phone:  (+44) (0235) 464490
Fax:    (+44) (0235) 553301          Fax:    (+44) (0235) 464766
E-mail: gatc@tessella.co.uk          E-mail: cpg@jet.uk
        gatc@tss.uucp
- Disclaimer: Please note that the above is a personal view and should not 
  be construed as an official comment from the JET project.
From: davisonj@bnr.ca (John Davison)
Newsgroups: comp.lang.fortran,slac.lang.fortran
Subject: What is the name of the latest Fortran standard document?
Summary: is it X3J3/S8.112?
Keywords: Fortran 90 ANSI ISO
Date: 14 Aug 92 07:33:29 GMT
Followup-To: comp.lang.fortran,slac.lang.fortran
Organization: Bell-Northern Research, Richardson, Tx.


        I am sitting here with Draft S8, Version 112 of S8 (X3.9-198x), also
known as X3J3/S8.112, and I am wondering if this document actually represents
the new Fortran.  (I doubt it, since it appears that this is an "8x" thing and
not a "90" thing, but I don't know a whole lot about the last few years'
evolution of the proposed Fortran standards.)

        Would some nice person tell me whether this document was adopted
without revision by ANSI and ISO, or if this document is useless, or something
like that?

        Replies both by electronic mail (see my signature) and USENET articles
in these newsgroups would be appreciated.

        Thanks!


-- 
NOTE: The opinions and other information contained herein are not to be
      construed as representative of Northern Telecom or any of its
      subsidiaries.  Please direct all electronic mail to 
                   =======> davisonj@ecn.purdue.edu. <=======
Newsgroups: comp.lang.fortran
From: cflatter@nrao.edu (Chris Flatters)
Subject: Re: how to quit on an NaN result?
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Mon, 17 Aug 1992 18:27:48 GMT

In article 18062@craycos.com, jrbd@craycos.com (James Davies) writes:
>In article <1992Aug16.221125.19419@ccu1.aukuni.ac.nz> ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig) writes:
>>Bruce.Scott@bbs.oit.unc.edu (Bruce Scott) writes:
>>
>>>How can I check forNaN's and quit when one arises.
>>
>>NaN's are supposed to fail every test, so
>>
>>      IF ((.NOT.AVAR.GE.0.) .AND. (.NOT.AVAR.LT.0.)) STOP
>>
>>should do the trick.
>
>Would this have the same effect?
>
>	IF (AVAR .NE. AVAR) STOP

It is preferable.  Not only does it only involve only one test but it will not
raise an invalid operation flag if AVAR is a NaN (the former will).

	Chris Flatters
	cflatter@nrao.edu
Newsgroups: comp.lang.fortran
Subject: Re: programming style question
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Sun, 23 Aug 1992 01:37:04 GMT
 <1992Aug14.002538.3929@monu6.cc.monash.edu.au> <1992Aug21.184751.9673@draco.macsch.com> <1992Aug22.205756.21870@chpc.utexas.edu>
Organization: University of Auckland, New Zealand.

aswx266@chpc.utexas.edu (Michael Lemke) writes:

>In article <1992Aug21.184751.9673@draco.macsch.com> drd@macsch.com (Daniel R. Dawson) writes:
>>Forget about using links, man!
>>
>>Here's how I'd handle this problem for Unix boxes:
>>
>>(C-Shell script fragment similar to the DCL script fragment above)
>>setenv FOR005 ${1}.dat
>>setenv FOR006 ${1}.out
>>myprog
>>unsetenv FOR005
>>unsetenv FOR006
>>
>>Then, in the Fortran, just use getenv() to get the filenames
>>for the open statements.
>>
>>Easy as pie!

Quite an elegant solution, I guess I'll start using it.

>Except it is no standard Fortran anymore.  And it won't run on VMS 
>anymore either.  Of course you can conconct a getenv function but that 
>would have to be changed for the IBM again (can it be done?).

You don't need to. In MVS and CMS, you can pre-open units with a DD-card
or equivalent.

OPEN - statements are highly system - dependent anyway.

>But the actual solution for this particular problem is terribly easy in 
>Unix:

>myprog <${1}.dat >${2}.out

If your program happens to read only from one file and write to one
file, that's ok. Unfortunately, my problems usually don't fall into that
category.
-- 
Thomas Koenig, ecmtwhk@ccu1.aukuni.ac.nz, ib09@rz.uni-karlsruhe.de
The joy of engineering is to find a straight line on a double logarithmic
diagram.
From: burley@geech.gnu.ai.mit.edu (Craig Burley)
Newsgroups: comp.lang.fortran
Subject: Re: subroutine calls with loop index parameters
Date: 18 Aug 92 16:48:35 GMT
Article-I.D.: geech.BURLEY.92Aug18124835
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
In-reply-to: ecmtwhk@ccu1.aukuni.ac.nz's message of 18 Aug 92 06:49:27 GMT

In article <1992Aug18.064927.1990@ccu1.aukuni.ac.nz> ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig) writes:

   Unless I am quite mistaken, the FORTRAN standard specifies that it is
   illegal to modify the value of an index variable inside the loop, so
   any change which FUNC made to it would have been illegal; the compiler
   could therefore safely assume it would not be made, and produce optimum
   code the first time.

You are not mistaken.

   How widespread is this kind of behaviour? Should I always introduce
   additional variables to get around situations like that?

I don't know.  You might try enclosing all "questionable" references to
loop index variables in parentheses just to see what it would do, as in:

    A(I,J) = FUNC((I),(J))

It might accomplish nothing, but it's a little more readable than throwing
in a couple more temporaries.  You could also try "(I+0)" etc.

The front end for GNU Fortran automatically marks all such references in the
IL as "loop-index" references so the back end, if it wants, can realize that
the variable won't be modified no matter what.  Offhand, I don't remember if
I've made use of this in the initial implementation of GNU Fortran with the
GNU compiler back end, but when building the front end, I thought it important
to provide to whatever back ends people wanted to attach to it.
--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)
From: Peter.Hammond@brunel.ac.uk (Peter D Hammond)
Newsgroups: comp.lang.fortran
Subject: BC-F77 Document in English
Date: 13 Aug 92 13:40:46 GMT
Organization: Brunel University, Uxbridge, UK
X-Newsreader: Tin 1.1 PL3

-- 
BFN, Pete.

 Dept. Materials Technology | Disclaimer: SERC pay me | You sometimes have to  
 Brunel University          | to report my opinions,  |    listen to
 Uxbridge                   | not for theirs or the   | A lot of useless talk.
 Middx, UB8 3PH, UK.        | the university's.       |         N. Peart. (RUSH)
From: tim@ksr.com (Tim Peters)
Newsgroups: comp.lang.fortran
Subject: Re: Function declaration query
Date: 13 Aug 92 20:33:47 GMT
Article-I.D.: ksr.14777
Organization: Kendall Square Research Corp.

In article <1992Aug11.203411.24268@ctr.columbia.edu> shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin) writes:
>I have a function that looks pretty much like this:
>
>      LOGICAL FUNCTION FOO
>      COMMON/STUFF/....
>C     *** based on things in common, set FOO to .TRUE. or .FALSE.
>      RETURN
>      END
>
>[... IBM RS6000's xlf compiler gripes, requiring
      LOGICAL FUNCTION FOO()
  instead ...]
>I was under the impression that the declaration as I originally wrote it
>was standard-conforming;  can someone tell me if I am correct?

The F77 std requires parens for FUNCTION declarations but not for
SUBROUTINE declarations.  So xlf is doing you a favor <grin>.

A curious thing about F77 is that while it restricts variable names to 6
characters, the syntax nowhere *relies* on that.  Since blanks are
insignificant, your original line:

      LOGICAL FUNCTION FOO

is ambiguous (i.e., are you declaring the LOGICAL function FOO or the
LOGICAL variable FUNCTIONFOO?) without invoking the 6-character rule.  A
similar ambiguity cannot occur for SUBROUTINE statements, so F77 allows
you to omit the parens for them.

demonstrating-the-mind's-need-to-find-order-in-chaos-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
tim@ksr.com,         ksr!tim@uunet.uu.net
Newsgroups: comp.lang.fortran
From: klassen@sol.UVic.CA (Melvin Klassen)
Subject: C versus FORTRAN debate (WAS: Re: Welcome to HPFF
Keywords: HPFF, High Performance Fortran
Organization: University of Victoria, Victoria, B.C. CANADA
Date: Fri, 14 Aug 92 22:41:12 GMT

In article <0@ibr.cs.tu-bs.de> 
  i2041101@rzphy1.rz.tu-bs.de (Joachim Paulini, TU Braunschweig) writes:
> 
>Stop it! I'm programming now for several years scientific applications
>in FORTRAN 77 because I must do it, due to libraries and already existing
>programs in FORTRAN. 
> ...
>The situation now is that people who are used to a 'real' programming language
>(mostly C) only write programs in FORTRAN if there is no other way ... like me.
>If in some years most of the numeric software is available in C, all new
>numeric programmers won't code in FORTRAN and many of the old will convert too.

I wish my employer would pay me to "wait some years"!
He wants the results **NOW**, even if I have to use arrays in Fortran 90!
You really should **not** walk away from your terminal without logging off!
It lets hackers restart the old "C versus FORTRAN" religious debates!
From: Peter.Hammond@brunel.ac.uk (Peter D Hammond)
Newsgroups: comp.lang.fortran
Subject: Re: Free f77 documentation wanted.
Date: 12 Aug 92 16:04:51 GMT
Organization: Brunel University, Uxbridge, UK
X-Newsreader: Tin 1.1 PL3

Peter.Hammond@brunel.ac.uk (Peter D Hammond) writes:
: 
: Has anyone got the documentation of the BCF77 P.D. compiler for the PC
: translated into English? (I assmume that is allowed by the copyright holder.)
: 

And I've already recieved it, acknowlegement sent by mail.
I'll forward it if anyone asks, or post here if there is any demand.


-- 
BFN, Pete.

 Dept. Materials Technology | Disclaimer: SERC pay me | You sometimes have to  
 Brunel University          | to report my opinions,  |    listen to
 Uxbridge                   | not for theirs or the   | A lot of useless talk.
 Middx, UB8 3PH, UK.        | the university's.       |         N. Peart. (RUSH)
From: gerardo@ferris.cray.com (Gerardo Cisneros)
Subject: Re: WILDCARD expansion in UNIX FORTRAN
Organization: Cray Research, Inc.
Distribution: na
Date: 13 Aug 92 10:11:54 CDT

In article <1992Aug13.125538.13533@nsisrv.gsfc.nasa.gov> schieb@shark.gsfc.nasa.gov (Brian D. Schieber) writes:
> I'm porting a VAX FORTRAN program to UNIX that uses VAX library
>calls to expand a wildcard for filenames into an array of strings.
>Is there any such capability for UNIX FORTRAN? Short of doing
>a SYSTEM call and running 'find' I don't know how this would be
>done.

Where are you expecting the wildcard to come from?  Wildcards in command
lines are expanded by the shell, so the program gets an array of pointers to
strings.  If you need wildcard expansion within the program and your Fortran
library does not have extensions supporting this, you could interface to
the system and C-library functions getdirentries(2), opendir(3), readdir(3),
telldir(3), seekdir(3), rewinddir(3), closedir(3) and scandir(3), where
(2) and (3) refer to sections 2 (System calls) and 3 (Library functions) of 
the Unix manual.
-- 
Dr. Gerardo Cisneros		|Cray Research de M'exico, S.A. de C.V.
gerardo.cisneros@cray.com	|Camino a Sta. Teresa 480-A #302
(+52+5)622-8584			|14020 Tlalpan, D.F., MEXICO
 Anything I said sound like an opinion? Then it's no one's but my own.
From: acmeyer@hpfcso.FC.HP.COM (Alan C. Meyer)
Date: Thu, 13 Aug 1992 16:45:22 GMT
Subject: Re: Are assumed-size array args faster than adjustable?
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.lang.fortran

In comp.lang.fortran, matap@lure.latrobe.edu.au (Andrej Panjkov, La Trobe Maths) writes:

> Which makes faster code:  declaring array arguments as adjustable arrays
> or as assumed-size arrays?  (Please answer for whatever compiler you
> use, as I use four compilers, and I'm interested in general principles.)
> 
> I ask because I noticed different things happen when debugging a Lahey
> F77L compiled program under SOLD.  Suppose I have two array arguments for a 
> subroutine, one adjustable, one assumed-size.  I can use the debugger to
> inspect the contents of the assumed-size array immediately on entering the 
> subroutine.  I can't inspect the contents of the adjustable array until I 
> execute at least one statement.  
> 
> I assume this is because the dimensions of the adjustable array are 
> evaluated or decoded on entry to the subroutine.  This suggests that 
> assumed-size arrays are just a touch quicker to use.  What do you think?

The difference between using assumed-size vs. adjustable arrays should
be negligible.  For example, here are two sets of declarations:

   ! Assumed-size                      ! Adjustable
   SUBROUTINE SUB(A,K,L,M)             SUBROUTINE SUB(A,K,L,M,N)
   REAL A(K:L, M:*)                    REAL A(K:L, M:N)
   ...                                 ...

The processing for A that might typically be performed at procedure prolog
would include calculation of the size of each dimension.  For the assumed-size
array there is no size for the second dimension so this calculation would
typically not be executed.  This would save you a slight amount of time
at prolog (compared to the adjustable array).

However, the real concern would be any difference in performing offset
calculations in referencing the array.  Since the upper bound of the last
dimension is not required (this is column-major Fortran), there should be
absolutely no difference in performance of accessing array elements.

So, the assumed-size array might save a slight amount (depending on the
implementation of the compiler) but it would be negligible.

Alan Meyer
Colorado Language Lab
acmeyer@fc.hp.com

"These are my own opinions ..."