HDTenEightyP/NetNews huggingface dataset:
From: rodgers@engcon.marshall.ltv.com (KMRODGERS)
Newsgroups: comp.lang.fortran
Subject: Unformatted Format on PCs
Summary: what is it
Date: 10 Nov 92 21:37:25 GMT
Reply-To: rodgers@engcon.UUCP (KMRODGERS)
Organization: LTV MEG, Dallas, TX


We use gnuplot here a lot to plot data from simulations, etc.  Up until now
we have been running mostly on Unix boxes.  To save space and time both 
reading and writing the data (for simulation time histories, we might have
5000 timepoints, with 500 data items per timepoint), we use unformatted
WRITEs from Fortran.  On every Unix box I know of, Fortran unformatted
files look like

          4-byte int  data data data ... data  4-byte int
          4-byte int  data data data ... data  4-byte int
          .
          .
          .
          etc.

It was quite easy to modify gnuplot to read this type of file.  Some people
here would like to run gnuplot on PCompatibles, and would still like to have
the unformatted read capability.  So, . . . does anyone know how most PC
Fortran compilers write unformatted files?  Note that I do not need to
transport binary files between different platforms, I just need gnuplot on
a PC to read a Fortran unformatted file produced on a PC.  Since our newsfeed
typically runs several days behind, please email and I will summarize to
the net.  Thanks in advance . . .

------------------------------------------------------------------------------
Kevin Rodgers  Loral Vought Systems  rodgers%engcon@uunet.uu.net
I only speak (in tongues) for Brother Bob Tilton!
------------------------------------------------------------------------------
Newsgroups: comp.lang.fortran
From: dnl@convex.is.macsch.com (David Lombard)
Subject: Re: Fortran Forever?
Organization: MacNeal-Schwendler Corp.
Date: Wed, 11 Nov 92 17:13:37 GMT

In article <27366@oasys.dt.navy.mil> ruckman@oasys.dt.navy.mil (Christopher Ruckman) writes:
>
>In Scientific American, July 1991, p. 112, Paul Wallich's article entitled
>"FORTRAN Forever:  Is it still the language of choice for science?"
>contains the quote but not its origin.  According to the article, Guy
>L. Steele of Thinking Machines quotes an unknown scientist as saying
>"I don't know what the computer language of the year 2000 will look
>like, but I know that it will be called FORTRAN."


*Legend* attributes it to Seymour Cray.

Regards,
DNL

                 MY_COMMENTS = MY_OPINIONS = NOBODY_ELSES;

David N. Lombard    The first thing we do,         The MacNeal-Schwendler Corp
dnl@macsch.com      Let's kill all the lawyers.    815 Colorado Blvd
(213) 259-4911      II Henry VI, IV.ii             Los Angeles, CA  90041
Newsgroups: comp.lang.fortran
From: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Subject: Re: flushing output in f77
Reply-To: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Organization: MRL - UIUC
Date: Fri, 13 Nov 1992 05:18:39 GMT
Keywords: flush,i/o

In article <141324@lll-winken.LLNL.GOV>, sterne@dublin.llnl.gov (Philip Sterne) writes:
|>Is there a clean standard-conforming way of emptying the write
|>buffer for a unit in f77?  
|>  [...]
|>
|>I could use flush, but that appears to be architecture dependent.
|>
|>At the moment, the best (portable) plan I can come up is to open, 
|>write and close some file for each iteration.  
|>
|>Is there a better way?  For example, does a REWIND force a flush?
|>Or is this vendor dependent?  The standard doesn't seem to address 
|>this question.  

i had this very same problem and examined it some months ago
by posting in this group.  yes, the solution is vendor-dependent
and there is no standard solution.
for the platform i was interested in, AIX on RS6000, it seems that
you have to close and reopen.  i am using a routine that i call
as CALL FLUSH(unit), just as in DECfortran and other 
architectures, which internally INQUIREs the file, discovers
what the name is, closes it and reopens it.  So my source is
sort of "portable" now, at least between DEC and IBM RISCs.   
If you are interested in the routine email me
and i will send you the source (or post it here).
furio 
--
Furio Ercolessi
Materials Research Laboratory           |   Intl School for Advanced Studies
Univ. of Illinois at Urbana-Champaign   |   Trieste, Italy
furio@uiuc.edu                          |   furio@sissa.it
From: bud@ms.uky.edu (William K Glunt)
Newsgroups: comp.lang.fortran
Subject: Lahey fortran
Date: 10 Nov 92 04:42:21 GMT
Article-I.D.: ms.1992Nov9.234221.11019
Organization: University Of Kentucky, Dept. of Math Sciences

Howdy all,

 I'm interested in getting a fortran compiler for a DOS machine
that can use more than 640K of ram.  Anyone know the current status
of the Lahey offerings? How about educational discounts?  Any information
will be appreciated.

Thanks,

Bud Glunt

-- 
Dr. William K Glunt     | Are you ABNORMAL?
APSU Dept of Math and CS| Then you are probably better than most people!
Clarksville TN          | Are alien space monsters bringing a STARTLING NEW
home phone 615 645 8938 | WORLD?  from _The book of the SubGenius_
Newsgroups: comp.lang.fortran
From: gmap11@gmd.de (Clemens-August Thole)
Subject:  High Performance Fortran Presentation in Europe
Keywords: HPF, parallel, language extensions
Organization: GMD, Sankt Augustin, Germany
Distribution: europe
Date: Thu, 12 Nov 1992 16:59:32 GMT


High Performance Fortran Presentation in Europe

The High Peformance Fortran Forum has now been holding meetings for
about 1 year in order to develop language extensions and compiler
directives to support the parallel execution of Fortran 90 programs on
architectures with non-local memory.

Now, a draft proposal has been completed. For information about this
draft send mail to the mail information server hpff-info@cs.rice.edu.
Many supercomputer companies have already announced their intention to
support HPF.

The draft will be presented at the SUPERCOMPUTER 92 conference to
solicit general comments and an e-mail server has been set up to
assist with this process.

The European High Performance Fortran Working Group is prepared to
arrange a presentation of the HPF proposal at a European site (either
Brussels or Bonn) by members of the HPFF core group. This presentation
will be especially directed to application writers and their comments
on the proposal are regarded as very interesting.

In order to be able to estimate the possible response, we would like you
to answer the following questions:

Would you join such a meeting (50 ECU meeting fee) ? 
What would be an appropriate date ?
for instance, what about December 18th ?
Would you prefer Bonn or Brussels ?


Clemens-August Thole

hpf-europe-request@gmdzi.gmd.de
From: fairfield@slacvx.slac.stanford.edu
Newsgroups: comp.lang.fortran
Subject: Re: Problem using $GETUAI
Date: 5 Nov 92 21:34:08 GMT
Article-I.D.: slacvx.1992Nov5.133408.1
Organization: Stanford Linear Accelerator Center

In article <1992Nov5.184235.12119@wega.rz.uni-ulm.de>, KARGL@rzmain.rz.uni-ulm.de (ComRam) writes:
> Starting with the problem of finding the Real Name to a given Account I
> first wrote a little C program which does the job and works quite fine.
> Then I started to do the same thing in FORTRAN (Just for fun:-) and this
> one refuses to work. The SYS$GETUAI returns a SS$_BADCONTEXT. Can anyone
> tell me whats wrong with this thing?
> 
> --------------------------------------------------------------------------
> 
> * FINDREAL.FOR --- Find Owner Name --- (C) 1992 by ComRam
> 
> 	PROGRAM Findreal
> 
> 	IMPLICIT NONE
> 	
> 	INCLUDE '($JPIDEF)'
> 	INCLUDE '($UAIDEF)'
> 
> 	CHARACTER*12   Username
> 	CHARACTER*32   Owner
> 
> 	INTEGER Usernamelen,
> 	1	Ownerlen,
> 	2	Status,
> 	3	I
> 
> 	INTEGER SYS$GETJPI,
> 	1	SYS$GETUAI
> 
> 	STRUCTURE /ITMLST/
> 	   INTEGER*2 BUFLEN,
> 	1            CODE
> 	   INTEGER*4 BUFADR,
> 	1            RETLENADR
> 	END STRUCTURE
> 	
> 	RECORD /ITMLST/ JPI_LIST,
> 	1		UAI_LIST

[...]

> 	Status = SYS$GETUAI (0,0,%DESCR(Username(1:I)),UAI_LIST,0,0,0)
> 
> 	WRITE (*,*) 'Status : ',Status,'  Owner : ',Owner
> 
> 	STOP
> 	END

    Petros Dafniotis <dafnioti@cae.wisc.edu> already noted that the call
to SYS$GETUAI wants a "null" argument.  In VAX Fortran you either omit
the argument, as Petros noted, or you pass a zero BY VALUE, i.e., %VAL(0).

    Furthermore, VAX Fortran passes character string arguments by descriptor,
so your $DESCR(...) is redundant. (All other arguments are passed by reference,
but you're not writing %REF(UAI_LIST), for example.)  Thus you would normally 
write:

 	Status = SYS$GETUAI (,,Username(1:I),UAI_LIST,,,)

    But what I _really_ wanted to comment on is that your item lists are
supposed to be terminated by a longword zero.  Thus it's common to declare
your ITMLST structure like so:

 	STRUCTURE /ITMLST/
	  UNION
	    MAP
 	      INTEGER*2 BUFLEN,
 	1               CODE
 	      INTEGER*4 BUFADR,
 	1               RETLENADR
	    END MAP
	    MAP
	      INTEGER*4 ZERO
	    END MAP
	  END UNION
 	END STRUCTURE

followed by

 	RECORD /ITMLST/ JPI_LIST(2),
 	1		UAI_LIST(2)

Your assignment statements change from "JPI_LIST.BUFLEN = 12" to
"JPI_LIST(1).BUFLEN = 12", etc.  Finally, to be picky, you then add the 
statements:

	JPI_LIST(2).ZERO = 0
and
	UAI_LIST(2).ZERO = 0


		Cheers, Ken
-- 
 Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slac.Stanford.Edu
 SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
 ----------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
Newsgroups: comp.lang.fortran
From: mjs@hubcap.clemson.edu (M. J. Saltzman)
Subject: History question--fortran arrays
Organization: Clemson University, Clemson SC
Date: Fri, 13 Nov 1992 20:53:21 GMT

On comp.lang.c, another discussion of the relative virtues of Forrtan
vs. C is occurring (relatively civilized so far, compared to the usual
religious wars).  It's not my intention to perpetuate the argument,
but a question came up that might get a more accurate answer here than
the speculation I've seen over there.

Does anyone know the historical justification for having Fortran arrays
stored with the fastest-varying index at the left?

My guess is that this is a "natural" order with respect to some matrix
operations, and that perhaps it has to do with data locality rather
than instruction counts, or else it was something peculiar to the IBM
704.  It's certainly different from the "natural" order dictated by
the C/Pascal/etc. philosophy that a multidimensional array is an array
of arrays (with successive indices appended at the right).

I found a copy of a page from the original FORTRAN manual which contains
the following:

>_Arrangement_of_Arrays_in_Storage_
>
>A 2-dimensioanl array A will, in the object program, be stored
>sequentially in the order A(1,1), A(2,1), ...., A(m,1), A(1,2), ....,
>A(m,2), ...., A(m,n).  Thus it is stored "columnwise", with the first
>of its subscripts varying most rapidly, and the last varying least
>rapidly.  The same is true of 3-dimensional arrays.  1-dimensional
>arrays are of course simply stored sequentially.  All arrays are
>stored backwards in storage; i.e. the above sequence is in the order
>of decreasing absolute location.

But the accompanying article (by Backus) doesn't explain further.

-- 
		Matthew Saltzman
		Clemson University Math Sciences
		mjs@clemson.edu
From: lfini@sisifo (Luca Fini)
Newsgroups: comp.lang.fortran
Subject: Re: Running VAX-Fortran Code on IBM compatible PC
Date: 9 Nov 92 15:16:34 GMT
Organization: Osservatorio di Arcetri
X-Newsreader: TIN [version 1.1 PL6]

Arne Reykowski (reykowsk@ee.tamu.edu) wrote:
: 
: Hi, 
: I have a question:
: I wrote this realy nice piece of code using VAX Fortran.
: Now I realized that it would be very appropriate to have it 
: available on an IBM compatible PC. We do have a Microsoft Fortran
: compiler, but I used STRUCTURE/MAP/UNION commands in my source code
: which came very handy for my problems. These are not Fortran 77 comands,
: so the PC compiler chokes on them. 
: 
 ... deleted ....

I've used a very handy utility by Sun Microsystem which was called "f77cvt".
It was a VAX Fortran to Fortran 77 converter which used to be a piece of the
Sun standard Fortran package. Very unfortunately now Sun ships a new 
Fortran compiler which directly compile also Vax code and has not the
separate converter anymore (I hate it!). I've kept a copy of the old
f77cvt binary which still works just to solve the problem you state.
It may not be a solution for you: you need a Sun Sparc to run it.

+------------------------------------------------------------------------+
| Luca Fini                                                              |
| Osservatorio Astrofisico di Arcetri     Tel.   +55 2752 253            |
| L.go E.Fermi, 5                         Fax.:  +55 220039              |
| 50125 Firenze                           e-mail: lfini@arcetri.astro.it |
| Italia                                                                 |
+------------------------------------------------------------------------+
Newsgroups: comp.lang.fortran
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: unformatted output: << SUMMARY >>
Organization: University of Jyvaskyla, Finland
Date: Wed, 11 Nov 1992 13:09:31 GMT

In article <1992Nov5.111303.17921@uts.uni-c.dk> ohnielse@oersted.ltf.dth.dk writes:
>In article 26525@chpc.utexas.edu, michael@chpc.utexas.edu (Michael Lemke) writes:
>>Doesn't have the record *number* to be stored at some place as well?  
>>Nothing stops you from doing
>>
>>         open( ,.... access='direct', .... )
>>         write( ..., rec=777 ) data
>>         write( ..., rec=32 ) mode_data
>>         close( ... )
>>
>>which gives you just two records of data and lots of `holes'.  Or am I
>>missing something?
>
>I think you are exactly right !

No!  Think of a direct-access file as an array on disk.
Indices are not _stored_ with array elements, they are just used
to calculate their addresses.  Likewise, there is no need
to store record numbers with the records.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
From: dafnioti@cae.wisc.edu (Petros Dafniotis)
Subject: Re: Problem using $GETUAI
Organization: U of Wisconsin-Madison College of Engineering
Date: 5 Nov 92 14:07:48 CST

In article <1992Nov5.184235.12119@wega.rz.uni-ulm.de> KARGL@rzmain.rz.uni-ulm.de (ComRam) writes:
>Starting with the problem of finding the Real Name to a given Account I
>first wrote a little C program which does the job and works quite fine.
>Then I started to do the same thing in FORTRAN (Just for fun:-) and this
>one refuses to work. The SYS$GETUAI returns a SS$_BADCONTEXT. Can anyone
>tell me whats wrong with this thing?
>
>--------------------------------------------------------------------------
>
>* FINDREAL.FOR --- Find Owner Name --- (C) 1992 by ComRam
>
>	PROGRAM Findreal
>
           ...   [code deleted] ...
>
>	Status = SYS$GETUAI (0,0,%DESCR(Username(1:I)),UAI_LIST,0,0,0)
                             ^ ^                                ^ ^ ^
>
>	WRITE (*,*) 'Status : ',Status,'  Owner : ',Owner
>
>	STOP
>	END
>

  Frank,

  using HELP SYSTEM $GETUAI you see that where you put 0 you really need
null argument. Therefore, try:
	Status = SYS$GETUAI(,,%DESCR(Username(1:I)),UAI_LIST,,,)
This works for me. Hope it helps.

>------------------------------------------------------------------------------
> ComRam  (in real life : Frank Kargl)    Student consultant for programming
> IP            : COMRAM@RZ.UNI-ULM.DE    University of Ulm          Germany
> DECnet(Belwue) : 50186::KARGL           All statements posted above are
> Bitnet       : KARGL@DULRUU51.BITNET    my personal oppinion ONLY !
>------------------------------------------------------------------------------

				Petros Dafniotis (AKA VMS4Ever)
				Chem Engr Dept, UW-Madison
			e-mail:	dafnioti@cae.wisc.edu
From: dafnioti@cae.wisc.edu (Petros Dafniotis)
Newsgroups: comp.lang.fortran
Subject: Re: Running VAX-Fortran Code on IBM compatible PC
Date: 8 Nov 92 20:39:19 GMT
Organization: U of Wisconsin-Madison College of Engineering

In article <1992Nov8.045246.5765@tamsun.tamu.edu> reykowsk@ee.tamu.edu (Arne Reykowski) writes:
>
>Hi, 
>I have a question:
>I wrote this realy nice piece of code using VAX Fortran.
>Now I realized that it would be very appropriate to have it 
>available on an IBM compatible PC. We do have a Microsoft Fortran
>compiler, but I used STRUCTURE/MAP/UNION commands in my source code
>which came very handy for my problems. These are not Fortran 77 comands,
>so the PC compiler chokes on them. 
.........
>Since I am more on the lazy side of the human spectrum I would
>appreciate any suggestion that would solve my problem without major
>effort.

  Arne,

  I think both MS-FORTRAN v5.0 and v5.1 as well as MicroWay NDP-FORTRAN 486
(the former is DOS/Windows compiler, the latter is a 386/486 Extended-DOS
compiler) will do what you want. They both support UNION/STRUCTURE etc.
MS-FORTRAN has a very low educational price; just $83 (I think) and it is
not that bad, though I wouldn't classify it as great piece of S/W.

  Regards,

					Petros Dafniotis
					Chem Engr Dept, UW-Madison
Newsgroups: comp.lang.fortran,comp.sys.hp
From: rvenable@helix.nih.gov (Richard M. Venable)
Subject: Re: Weird HP compiler warning
Reply-To: rvenable@helix.nih.gov (Richard M. Venable)
Organization: National Institutes of Health
Date: Wed, 11 Nov 1992 00:06:21 GMT

In article <1992Nov10.193635.2736@alchemy.chem.utoronto.ca>,
mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes:
|>      I usually like my compilers to give me a lot of warnings, even
when
|> they are most likely useless.  In this case however, I have run
across
|> one warning whose meaning I cannot fathom.  Consider the following
short
|> program:
|> 
|> 	  double precision h,nexth,err,d2fex
|> 	  h = 1.d0
|> 	  err = 10.d0
|> 	  d2fex = 123.d0
|>           nexth = min(h,sqrt(12.d0*err/d2fex))
|> 	  write(*,*)nexth
|> 	  END
|> 
|> For this piece of code, the compiler produces the warning
|> 
|> Warning on line 5 of weird.f: Argument has same name as INTRINSIC
function
|> 
        	[ some commentary deleted ]

Hmmm.  I tried the above code on an HP/Apollo workstation and on an
HP9000/750
and didn't get the above error message on either system.

<---------------------------------------------------------------------->
>
<  Rick Venable                (O O) |  "Back off, I'm a scientist."  
>
<  FDA/CBER Biophysics Lab      )|(  |        -- Bill Murray in       
>
<  rvenable@helix.nih.gov       (=)  |           'Ghostbusters'       
>
<---------------------------------------------------------------------->
>

Newsgroups: comp.lang.fortran
From: jim@meiko.co.uk (James Cownie)
Subject: IEEE arithmetic [was Re: unformatted output]
Followup-To: jim@meiko.co.uk
Organization: meiko
Date: Wed, 11 Nov 1992 10:26:11 GMT

In article comp.lang.fortran <1992Nov10.192736.22118@newshost.lanl.gov>,
jlg@cochiti.lanl.gov (J. Giles) writes:

|> Unfortunately, the Fortran standard does not conform to
|> IEEE (in fact, it conflicts with it in some places - like with regard
|> to negative zero).  And the Fortran standard does not require the same
|> conversion accuracy as the IEEE floating point standard.  

This is a less significant difference than some of the others, in particular 
Fortran definition of NINT and ANINT directly conflicts with the IEEE definitions
of the same functions. 

The Fortran definition could be written as
	INTEGER FUNCTION NINT(X)

	IF (X > 0.0) THEN
	   NINT = INT(X+0.5)
        ELSE
           NINT = INT(X-0.5)
        ENDIF
        END

IEEE (in round nearest mode, which is the default) specifies round even,
so
	IEEENINT(1.5) == 2.0  (as Fortran NINT)
BUT     IEEENINT(2.5) == 2.0  (Fortran gives 3.0)

Another area where IEEE seems never to be implemented correctly by compilers
is in the handling of Not a Numbers (NaNs). 

In the IEEE standard NaNs are values which can be encoded into a floating point
variable, which represent the concept that it is not a reasonable number.
(They are generated for operations such as sqrt(-ve), 0.0/0.0 etc.)
IEEE specifies that a NaN is unordered with respect to anything else, 
EVEN ITSELF. Therefore ALL comparisons involving floating variables MUST be 
generated by the compiler WITHOUT introducing logical negation, since in the face 
of NaNs (and their unordered relationship with other numbers)
	
	(.NOT. (X .LT. 2.0)) does NOT imply (X .GE 2.0)

(If X is a NaN (X .LT. 2.0) is FALSE (it's not less it's unordered),
 but (X .GE. 2.0) is also FALSE (it's not greater equal it's unordered)).

Similarly (and I've never seen this handled right in an optimising compilation),

	IF (X .ne. X) THEN
            print *,'X is a NaN'
        ELSE
            print *,'X is a number'
        ENDIF

should generate code which has a run time test. 

-- Jim
James Cownie 			Normal disclaimers apply.
Meiko Limited
650 Aztec West
Bristol BS12 4SD
England

Phone : +44 454 616171
FAX   : +44 454 618188
E-Mail: jim@meiko.co.uk or jim@meiko.com

Newsgroups: comp.lang.fortran,comp.os.msdos.programmer
From: chrism@col.hp.com (Chris Magnuson)
Newsgroups: comp.lang.fortran,comp.lang.c
Subject: Re: Need Fortran->C converter!
Date: 6 Nov 92 14:34:13 GMT
Article-I.D.: col.1992Nov6.143413.26296
Organization: HP Colorado Springs Division


  Never mind I got it now.

  Thanks.
Newsgroups: comp.lang.fortran
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: Z'hexno' gives compilation errors
Organization: Los Alamos National Laboratory
Date: Fri, 6 Nov 1992 18:48:45 GMT

BOZ constants are not in the Fortran 77 standard.  Although the
Fortran 90 standard allows them, the example given here was explicitly
stated to be an `f77' compiler.

(BOZ: Binary, Octal, and Z-hexadecimal.  The syntax is to begin the
constant with the corresponding letter - B, O, or Z - and follow with
a numeric literal limited to the appropriate digit set and enclosed
in apostrophes.  Z was chosen instead of the more natural H or X in
order that the letter be available as the format specifier for hex:
H and X already had meanings there.)

-- 
J. Giles
Newsgroups: comp.lang.fortran
From: acs25@rosie.uh.edu (Tom Monroe Jr.)
Subject: Query: NAG vs. IMSL
News-Software: VAX/VMS VNEWS 1.41    
Organization: University of Houston
Date: Mon, 9 Nov 1992 19:43:00 GMT


    We have several researchers at the University of Houston asking us to
purchase NAG.  If any one has any experience using NAG, can you tell me
what your impressions are.  Also any comparisons between NAG and IMSL would
be a great help.


Thanks



Tom Monroe
Supervisor Support Services

Newsgroups: comp.lang.fortran