HDTenEightyP/NetNews huggingface dataset:
From: mfavas@uniwa.uwa.edu.au (Mark Favas)
Subject: Portability - I/O, time, date, byte order
Organization: University of Western Australia
Date: Tue, 18 Aug 1992 03:23:37 GMT

I'm trying to collect together information related to the portability of fortran
code. At the moment I am just concerned with Unix-based machines. I have access
to the following Unix boxes: Sun, DEC (MIPS-based running Ultrix), Sony,
Silicon Graphics, and HP 9000/700 series. If you have some other type of Unix
box, and could spare the time,  I would appreciate answers to these questions 
(especially for IBM RS/6000 machines).
Please email your responses (I'll summarize if there's enough interest).

(1) I need to know in what units the record length of unformatted direct access
files must be specified in an OPEN statement. On some machines it is in bytes,
 in others words. If in words I need to know the wordsize in bytes.

(2) The library routine returning the elapsed CPU time for a job. Usually this
is ETIME, but not all systems have it. I also need to know the type of the
function (REAL*4 or REAL*8) since this varies, and how it is called, and the
type of the arguments, if any.

(3) The library routine returning the wall-clock time. This is usually ITIME.
Again, I need the type of the function, and arguments etc.

(4) The library routine returning the current date as a character string
(commonly FDATE), or, failing that, as an integer array (commonly IDATE).
Again, arguments and types etc.

(5) Byte order - is it big-endian (1234 as in Sun) or little-endian (4321 as in
DEC or VAXen)

Thanks in advance.

Mark C Favas
Department of Chemistry
The University of Western Australia    mark@crystal.uwa.edu.au
Newsgroups: comp.lang.fortran
From: tholen@galileo.ifa.hawaii.edu (Dave Tholen)
Subject: programming style question
Organization: University of Hawaii
Date: Wed, 12 Aug 1992 19:37:39 GMT

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 haven't
been doing so myself, but the question came up recently because I've
started using a new 32-bit OS/2 compiler that preconnects standard input
and standard output, but not standard error, whereas the old 16-bit OS/2
compiler preconnected all three.  To get standard error, I need to add
an explicit OPEN, and I'm debating about adding explicit OPENs for all
three.  While thinking about it, the following thoughts have occurred.
If OPENing standard output, what good is trapping an ERR= condition,
because there is no output device to which an error message can be
written?  Of course, one could use the STOP 'Error message here'
construct to get around this problem.  Also, in the PC world, to get
these three connected to the keyboard and screen, all three would OPEN
FILE='CON'.  At first, this looks like a violation of the FORTRAN 77
standard, because a file can be connected to only one unit at a time,
but even though the devices have the same name, I presume they are
treated as different logical devices to be standard conforming.

I'd appreciate more comments!
From: wae@aero.org (William A. Emanuelsen)
Newsgroups: comp.lang.fortran
Subject: Ignoring Least Significant Bit in a Real Compare
Summary: How best to go about it?
Date: 21 Aug 92 20:30:55 GMT
Followup-To: comp.lang.fortran
Organization: The Aerospace Corporation, El Segundo, CA

I am working on a 60-bit CDC machine in fortran-4.  (stop laughing!) I
am trying to compare two real numbers with .EQ. in an 'if' statement.  
But what happens is that the numbers I am comparing, and which should be 
equal, fail the test since the 60th bit sometimes gets rounded in the 
opposite direction.

For example, I have two variables, TEMP1 and TEMP2.  

Both print out unformatted as 104.9661485585.  

But in Octal representation,

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

So what I did was to write a logical function, REQ, to replace the .EQ. 
comparison:

      LOGICAL FUNCTION REQ(X1,X2)
C
      REQ = .FALSE.
      IF (ABS(X1-X2) .LT. EPS) REQ = .TRUE.
      RETURN
      END

Where EPS is the smallest difference I expect to see between two numbers 
that actually are unequal.

So where I formerly had: IF (TEMP1 .EQ. TEMP2) ...
I now have:              IF (REQ(TEMP1,TEMP2)) ...

Is there a better (faster and more straightforward) way to ignore the 
least significant bit when doing real compares in fortran-4?
(Bit-shifting seems to add more steps.)
-- 
William A. Emanuelsen    "You'll never get famous by repeating what
wae@aerospace.aero.org      other people say." -- Bartlett's Mom.
From: davem@ee.ubc.ca (david michelson)
Subject: Re: programming style question
Organization: University of BC, Electrical Engineering
Date: Sun, 16 Aug 1992 22:17:25 GMT

 
    Is it dangerous or poor practice to assume that the variables
    in a subroutine will retain the values assigned in the immediately
    previous execution the next time it is called?

    For example, consider the subroutine FOO with entry point FOOC:           
 
 
       SUBROUTINE FOO(X,A,B,C)
 
       [lots of stuff that depends only on A and B
 
       G = ....
       H = ....
 
       ENTRY FOOC (X,C)
 
       X = G * C + H
 
       RETURN
       END
 
 
    Is this a dangerous way to write FOO if I want to do this:
 
 
       PROGRAM OPTIMIZE
 
       A = ... 
       B = ...
       C = ...
 
       CALL FOO(X,A,B,C)
 
  * find the value of C which is a root of X with A and B fixed 
 
       [lots of code]     <----
                               |
       CALL FOOC (X,C)  <-------------------- the values of G and H 
                               |              are "remembered" from when
                               |              FOO() was called.
       [loop back until done]--
 
       WRITE(6,*) 'The root is...  ', C, ' !'
 
       END
 
 --------------------------------------------------------------------
 
 
 
       There are many ways that I can accomplish the desired result but
       this seems to be the easiest way to "speed up" my existing code
       and it seems to work, in principle, on the PC-based WATFOR77 
       compiler. 
 
       Does the Fortran standard specify that compilers will generally
       behave this way?  Would I look foolish and look like a "hack"
       programmer if I were to describe this in the documentation to
       my program?
 
       ( the real issue! :-)
 
       Looking forward to your thoughts on the matter.
 
       Dave Michelson  "davem@ee.ubc.ca"
Newsgroups: comp.lang.fortran
Subject: What extensions do you use?
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Thu, 13 Aug 1992 00:44:48 GMT
Organization: University of Auckland, New Zealand.

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
The joy of engineering is to find a straight line on a double logarithmic
diagram.
Newsgroups: comp.lang.fortran
Subject: Re: programming style question
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Mon, 17 Aug 1992 01:35:21 GMT
Organization: University of Auckland, New Zealand.

davem@ee.ubc.ca (david michelson) writes:

>    Is it dangerous or poor practice to assume that the variables
>    in a subroutine will retain the values assigned in the immediately
>    previous execution the next time it is called?

Yes. This will fail on stack - oriented implementations, like most
modern RISC architectures. Although most of the compilers on these
machines have an option which saves variables across calls, because too
much old code simply depends on it, there is a performance penalty for
this.

Put those variables into SAVE statements instead.
-- 
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.
Newsgroups: comp.lang.fortran
Subject: Re: how to quit on an NaN result?
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Sun, 16 Aug 1992 22:11:25 GMT
Organization: University of Auckland, New Zealand.

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.
-- 
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.
Newsgroups: comp.lang.fortran
From: cflatter@nrao.edu (Chris Flatters)
Subject: Re: FORTRAN 90
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Thu, 13 Aug 1992 19:58:03 GMT

In article 6635@cfa.harvard.edu, orszak@cfa.harvard.edu (Jeff Orszak) writes:
>I would like to know if the FORTRAN 90 standard is "frozen", and if so
>what are the best reference to what will be in FORTRAN 90.

Fortran 90 has been approved by ANSI and ISO.  The ISO desgination
is  IS1539.  The best reference is obviously the standard itself
but "Fortran 90 Explained" by Metcalf and Reid (Oxford University Press) is
good if you don't want to wade through the full language definition.

>Also, what
>progress is being made in make compilers that follow the standard?
>Because having compilers available will really make it a standard.

There are at least 2 third-party Fortran 90 compilers available for
UNIX systems.  NAG distribute a compiler that uses C as an intermediate
code while Parasoft distribute a compiler that uses FORTRAN 77 as
its intermediate code.  Both are reasonably priced.

Vendors have generally been lukewarm at best to Fortran 90 but there
appears to some signs of a change for the better here, at least among
computer vendors whose lines include multiprocessors or
multicomputers.

	Chris Flatters
	cflatter@nrao.edu
Newsgroups: comp.lang.fortran
Organization: Penn State University
Date: Mon, 17 Aug 1992 17:12:00 EDT
From: H. D. Knoble <HDK@psuvm.psu.edu>
Newsgroups: comp.lang.fortran
Subject: Re: how to quit on an NaN result?
 <KHB.92Aug16143141@chiba.Eng.Sun.COM>

In article <KHB.92Aug16143141@chiba.Eng.Sun.COM>, khb@chiba.Eng.Sun.COM (Keith
Bierman fpgroup) says:

>The fnonstd changing the way underflow works and trapping rather than
>ignoring "ieee exceptions". Since I personally want proper underflow,

It could be claimed that floating-point underflow is not "proper". In
fact wrong answers could be generated; and interrupt handling may be rather
CPU time consuming. Two examples follow to illustrate these points.

Suppose the underflow threshold minimum is 10**(-79). Then

Y=1.E-40**2*1.E+20*1.E+40**2    is algebraically 1.E+20

but most exception (interrupt) handlers would set the intermediate result
of an underflow to zero; thus the result for Y above would be 0.0 instead
of 1.E+20 in this event.

Furthermore, in some cases at least, trapping such exceptions can be
be very CPU expensive. For example, on an IBM 3090 (a reasonably fast
CPU) the threshold is less than 1.E-40 (in this case ABS(16**(-65)) ).
Using the IBM VS Fortran error trapping utility subroutine, ERRSET,
handle underflows, one could run the program:

         IMPLICIT DOUBLE PRECISION (A-H,O-Z)
         CALL ERRSET(208,256,-1,1,0,0)
         SUM=0
         X=1.E-40
         DO 1 I=1,100000
           SUM=SUM+X**2
   1     CONTINUE
         STOP
         END

The result of this program is SUM=0, but it took 18 full seconds of IBM
3090 CPU time to get through the system and VS Fortran interrupt handling
code!  Clearly, even if one isn't concerned about wrong results, this
method should not be used to ignore underflows since it is over 400 times
slower than using an IF statement (or using the equivalent VS Fortran
run-time option NOXUFLOW).
Newsgroups: comp.lang.fortran
From: mrl@uai.com (Mark R. Ludwig)
Subject: Re: Ultrix Fortran alternatives?
Organization: Universal Analytics, Inc., Torrance (LA), CA
Date: 13 Aug 92 08:06:07

In article <1992Aug11.210101.10249@nmt.edu> dcuddihy@nmt.edu (David Cuddihy) writes:

           We are currently running with the Fortran that came with the Ultrix 4.2
   release and we have had troubles with inconsistencies, for example code that
   runs on our Suns, miscellaneous workstations at other sites, supercomputer
   machines, etc... don't compile or have slightly different functionality on
   the Ultrix f77(and occasionally vice-versa).

Are you on a VAX or MIPS?  It matters, because DEC does not support
f77 on the VAX; they only support VAX/Fortran.  Of course, dbx doesn't
work very well with VAX/Fortran, so we use f77 for debugging and hope
for the best.  The only bug I've found uniquely attributable to the
f77 compiler is mixing character arguments with external subroutines
on a call to a subroutine.$$
-- 
INET: mrl@uai.com      BANG: uunet!uaisun4!mrl      ICBM: USA; Lower Left Coast
  "You can get a crowd to clap at a phone number, if the inflection is right."
   -- Dave Ross
From: jf@threel.co.uk (John Fisher)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran subroutine in C main
Date: 19 Aug 92 09:31:41 GMT


jaaksi@cs.tut.fi (Jaaksi Ari) writes:

> How to use Fortranm subroutines called from C main.

There really isn't any point in asking questions like
this unless you say what computer, environment and
compiler you're using.

--John
Newsgroups: comp.lang.fortran
From: wahler@Informatik.TU-Muenchen.DE (Bernhard Wahler (D MS))
Subject: C to Fortran , Character Strings
Originator: wahler@hpzenger1.informatik.tu-muenchen.de
Organization: Technische Universitaet Muenchen, Germany
Date: Mon, 17 Aug 1992 08:29:30 GMT




Hello everybody, I've got a problem with character strings 
in FORTRAN.  I have to translate a C-prg into a FORTRAN-prg.
and everything is working fine so far.
On a HP there is the ALIAS-Directive to tell the fortran-compiler
how to pass parameters. I tried this and it worked.

But how can I get
get a C-character string, which is returned by my C-function 
"msys_rcv()" ( see below ) into a fortran-type and work with it
( print it ). 
 
Any help would be appreciated. Thanks in advance,

Bernhard Wahler

wahler@dszenger10.informatik.tu-muenchen.de



---------------- C-Code --------------------------

char *RECEIVE( long *size, long *channel )
{
   char *mess;
->   if ((mess = msys_rcv( WAIT, size, channel ))!=NULL) {
     printf("Msg-Laenge : %ld\t", *size );
     printf("Channel : %ld\t", *channel );
     printf("Erstes Byte : %c\n", mess[0] );
     printf("Letztes Byte : %c\n", mess[*size-1] );
     msys_free(mess);
   }
   return mess;
}

-------------- FORTRAN-Code ----------------------

$ALIAS CC3 = 'msys_rcv' (%val,%ref,%ref)

        subroutine RECEIVE( mess )
          character mess*(*)
          integer*4 size, channel
          integer MSYS_NOWAIT
          parameter( MSYS_NOWAIT = 1 )
---->     mess =  CC3( MSYS_NOWAIT, size, channel )
        end


Keywords: 

Newsgroups: comp.lang.fortran
From: jmfres11@ucs.usl.edu (Karthikeyan Gurnswamy)
Subject: Event driven GOSUB in FORTRAN 90 ...
Organization: Univ. of Southwestern La., Lafayette
Date: Wed, 19 Aug 1992 16:12:26 GMT

Hi !
I am new to this newsgroup and have a peculiar requirement for a 
event driven handler in FORTRAN. The idea is, within a DO LOOP if I
hit some key I need to execute a subroutine and come back where it
branched of from. Actually I am looking for something like 
ON KEY GO SUB 
QBASIC equivalent in FORTRAN. Can somebody help me ?

Karthik
/----------------------------------------\--------------------------\
| Karthikeyan Guruswamy                  | Why does'nt my           |
| Graduate Student, Computer Science     |                          |
| Center for Advanced Computer Studies   |    NET always WORK ?     | 
| Univ. of SouthWestern Louisiana        |                          |
| Lafayette, LA 70501                    | -- Life beats any logic  |
| Email: jmfres11@ucs.usl.edu            |                          |
|                                        \--------------------------\
| The opinions stated are solely mine and does not reflect the views|
| of anyone in my organization ...                                  |
\-------------------------------------------------------------------/
From: burley@geech.gnu.ai.mit.edu (Craig Burley)
Newsgroups: comp.lang.fortran
Subject: Re: C versus FORTRAN debate (WAS: Re: Welcome to HPFF
Date: 18 Aug 92 16:50:00 GMT
Article-I.D.: geech.BURLEY.92Aug18125000
	<1992Aug14.224112.19348@sol.UVic.CA>
	<1992Aug15.172219.2138@ibr.cs.tu-bs.de>
	<92231.155237HBO043@DJUKFA11.BITNET>
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
In-reply-to: HBO043@DJUKFA11.BITNET's message of 18 Aug 92 13:52:36 GMT

In article <92231.155237HBO043@DJUKFA11.BITNET> HBO043@DJUKFA11.BITNET (Dr. Christoph van Wuellen) writes:

   P.S. I have not yet seen a 100,000 lines C program, whereas I work with
   several FORTRAN programs which are larger than this.

I've seen a few.  So far, they've all been Fortran compilers.  :-)

(Ok, plus GNU EMACS and GNU C, which are probably 100K lines as well.)
--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)
From: davisonj@bnr.ca (John Davison)
Newsgroups: comp.lang.fortran
Subject: Re: C versus FORTRAN debate
Summary: ...or Ratfor
Date: 18 Aug 92 19:45:49 GMT
Organization: Bell-Northern Research, Richardson, Tx.

In article <py0mz+n@lynx.unm.edu> john@aquarius.unm.edu (John Prentice) writes:
>If we are going to debate Fortran versus *any* other language, let's at
>least debate the merits of Fortran 90 (or variants like HPF or Fortran D).

...or Ratfor...                        <--- that is a JOKE


-- 
NOTE: I CAN'T SEND/RECEIVE E-MAIL HERE!!!  Use --> davisonj@ecn.purdue.edu <--
      During (roughly) August 20-25, I will be in transit.  Please be patient.
      The opinions and other information contained herein are not necessarily
      representative of Northern Telecom or any of its subsidiaries. 
Newsgroups: comp.lang.fortran
From: jtbell@hubcap.clemson.edu (Jon Bell)
Subject: Re: programming style question
Organization: Presbyterian College, Clinton SC
Date: Mon, 17 Aug 1992 21:15:04 GMT

In article <1992Aug17.174516.18372@ee.ubc.ca> davem@ee.ubc.ca (david michelson) writes:
>This quote from "Numerical Recipes: The Art
>of Scientific Computing" caught my eye:
> 
>"The Fortran 77 standard provides that variables internal to a subroutine
>are *not* guaranteed to be saved between successive calls to that 
>subroutine unless the variable is declared global in a SAVE statement.
>(This allows stack-oriented implementations.)
> 
>If this part of the standard were "enforced", a large fraction of all 
>programs written by all living programmers would immediately cease to
>function.  Only a few compilers *dare* to implement this part of the
>standard, therefore."

Well, I regularly use two Fortran 77 compilers:  Language Systems 
Fortran for the Macintosh and Salford FTN77 for Prime 50 series.
Both of them implement that part of the standard by default.  They
do both provide a compiler option which has the effect of SAVEing
all local variables in subroutines.

>Dave Michelson   "davem@ee.ubc.ca"

Jon Bell / Dept. of Physics & Computer Science / Presbyterian College
Clinton SC USA / email: jtbell@presby.edu
From: wsj@triton.wpd.sgi.com (Bill Johnson)
Newsgroups: comp.lang.fortran
Subject: Re: NAMELIST simulating routine
Keywords: NAMELIST
Date: 21 Aug 92 21:21:33 GMT
Reply-To: wsj@wpd.sgi.com
Organization: Silicon Graphics, Inc.

In article <1992Aug21.044540.22611@cco.caltech.edu>, yucao@sampson.ccsf.caltech.edu (Yu Cao) writes:
|> Has anybody written such a thing that enables you to read NAMELIST formatted
|> files when the compiler doesn's support it?
|> 
|> Any info is appreciated.
|> 
|> --Yu

You could translate to C using f2c -- this supports namelist.  f2c is
available from research.att.com -- use

	mail netlib@research.att.com
	send index

to get info, or ftp from research.att.com (with login netlib).  I have
used f2c with great success.

-- 
Bill Johnson                    9U-530                   wsj@wpd.sgi.com
Silicon Graphics, Inc.                             Office:(415) 390-1440
Systems Software Technology Center                    Fax:(415) 969-2314
From: jac@moonshine.llnl.gov (James A. Crotinger)
Newsgroups: comp.lang.fortran
Subject: Re: C versus FORTRAN debate
Date: 20 Aug 92 18:42:08 GMT
Organization: Magnetic Fusion Energy - LLNL

jsvrc@rc.rit.edu (J A Stephen Viggiano) writes:
> >Continuing to compare F77 to languages like C is a bit silly.  
> As is comparing FORTRAN 90 to languages like C. (Sorry, no ":-)".)

  I fail to see why this is silly. I think it is perfectly reasonable
to compare C++ (a language "like C") and Fortran 90. There are a
growing number of people doing scientific programming in C++. It
shares many features with Fortan 90, and has many the F90 lacks
(inheritance, pointers to functions, etc.) And it is widely available
and more mature than F90 (in spite of the fact that there is an F90
standard, and not yet an official ANSI C++ standard).

  I agree that rwars are useless, as are statements like J. Giles
typical "C is totally worthless for anything" type remarks. But
I think there are some valid reasons to compare F90 and C++. 

  Jim
--
-------------------------------------------------/\--------------------------
James A. Crotinger     Lawrence Livermore N'Lab // \ The above views are mine
jac@moonshine.llnl.gov P.O. Box 808;  L-630 \\ //---\  and are not neces-
(510) 422-0259         Livermore CA  94550   \\/Amiga\  sarily those of LLNL.
From: fmbutt@engage.sps.mot.com (Farooq M. Butt)
Newsgroups: comp.lang.fortran
Subject: yacc grammar for FORTRAN expressions
Date: 20 Aug 92 20:59:16 GMT
Organization: Motorola RISC Software, Austin, TX

Net.FORTRANOIDS:

I am looking for a YACC grammar that can handle FORTRAN 77 
expressions (I am adding FORTRAN smarts to GDB v4.5).  If you 
can point me at such a beast I'd be very grateful.  If this 
message has been multiply posted please accept by net.apologies
for a flaky reader :-( 

Please email and I'll summarize...

Thanks
fmb

-- 
Standard High-Tech Disclaimer: NOTHING  in the above article has the slightest 
relationship to reality. If any reality correspondences are found, please 
notify me IMMEDIATELY. Any threats, abuse or stupidity of any kind is purely 
UNintentional. These are MY Opinions NOT my employer's.
Newsgroups: comp.lang.fortran