HDTenEightyP/NetNews huggingface dataset:
From: pullin@mail.physics.utah.edu (Jorge Pullin)
Subject: Re: How to print a "TAB" in fortran 77?
Reply-To: pullin@mail.physics.utah.edu
Organization: University of Utah, Department of Physics
Date: Sat, 26 Sep 92 18:22:33 GMT

In article <1992Sep26.175435.21998@fcom.cc.utah.edu>, pullin@mail.physics.utah.edu (Jorge Pullin) writes:
|> Hello
|> 
|> I need to write to a file a "TAB" (ASCII 09, Ctrl-I) character to separate
|> fields of data. This is due to the fact that an application that reads my
|> data requires this type of separation among fields (note that I am not
|> talking about the TAB format, but of actually writing a character TAB). 

Thanks to all of you who so promptly replied! One possible answer is to use 
TAB=CHAR(9) to assign the ASCII value 9 to TAB and then print TAB in format 
A1.

Regards.
Jorge


-----------------------------------------------------------------------------
|Jorge Pullin, Department of Physics |  pullin@mail.physics.utah.edu        |
|201 JFB,  University of Utah        |  pullin@utahcca.bitnet               |
|Salt Lake City, UT 84112 USA        |  Tel:(801)581-5395 Fax:(801)581-4801 |
-----------------------------------------------------------------------------
Newsgroups: comp.lang.fortran
From: ercolessi@uimrl7.mrl.uiuc.edu (furio ercolessi)
Subject: Re: FORMAT overhead
Reply-To: ercolessi@uimrl7.mrl.uiuc.edu (furio ercolessi)
Organization: MRL - UIUC
Date: Fri, 2 Oct 1992 21:00:38 GMT

In article <1992Oct2.172343.10120@unixg.ubc.ca>, morgan@sitka.triumf.ca (Morgan Burke) writes:
|>It seems to me that a format specification specified in a FORMAT statement
|>should be parsed at compile time, not run time.

in general, the format specification may not be known at compile time
(it could be a character variable which is defined at run time).
so, run time parsing _must_ be there.

in most cases however compile time parsing is sufficient, but
probably manufacturers do not feel it's worth to implement it
since run time parsing is already there.

i also think that speed of formatted reads sucks on many
machines and if it can be improved by compile time FORMAT
parsing it would be a very welcome thing to do.

Credit to IBM: VS Fortran (VM,MVS) seems to read/write
formatted records pretty efficiently in my experience
(better than Crays). 

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
Newsgroups: comp.lang.fortran
From: das9674@usl.edu (Stephenson Daniel A)
Subject: The FORTRAN Yell
Organization: University of Southwestern Louisiana
Date: Sun, 27 Sep 1992 02:05:05 GMT

Have any of you fellow FORTRAN programmers ever worked so long on
a FORTRAN program, perhaps in university, and worked on it
so very long that when you make some random tweaking in hopes
that the program will work (I call this 'FORTRAN Dispair))
the PROGRAM ACTUALLY WORKS AND YOU JUMP UP FROM YOU CHAIR
IN THE LAB AND **YELL**?? And scare the bejesus out of everyone?

Just wondering...it is an interesting phenomenom.

-Dan
.

-- 
*Dan Stephenson   das9674@usl.edu  
*
* "To conquer death, you only have to die,..."                   
*                             -Jesus , from _Jesus Christ Superstar_
Newsgroups: comp.lang.fortran
From: morgan@sitka.triumf.ca (Morgan Burke)
Subject: Re: FORMAT overhead
Organization: TRIUMF, Vancouver BC
Date: Fri, 2 Oct 1992 17:23:43 GMT

In article <25862@oasys.dt.navy.mil>, jwhite@oasys.dt.navy.mil (Joseph White) writes:
|> In the formatted read, the read statement has to parse the format statement 
|> to figure out how it is supposed to treat this particular input, go 
|> get an exact number of digits, convert it to internal binary form, and 
|> then error check it.  I would think the finding of the format, and parseing
|> it would take longer than finding out it free format, and then doing
|> it.

It seems to me that a format specification specified in a FORMAT statement
should be parsed at compile time, not run time.  This should eliminate the 
bulk of parsing overhead when reading, since the purpose of the FORMAT is 
to provide a parsing template.  Free format records, on the other hand, 
always need to be scanned for blanks to determine where the data begin and 
end, and therefore must be parsed at run time.

Evidently, the MIPS compiler writers think differently from me, or else I
am missing some important considerations.

-- Morgan Burke (morgan@reg.triumf.ca)
Newsgroups: comp.lang.fortran
From: bai@msiadmin.cit.cornell.edu (Dov Bai-MSI Visitor)
Subject: Re: How do I make MS Fortran 5.1 use lots of memory?
Organization: /usr/local/lib/news/organization
Date: Wed, 30 Sep 1992 21:53:09 GMT

In article <1992Sep30.202817.6122@tc.cornell.edu> bai@msiadmin.cit.cornell.edu (Dov Bai-MSI Visitor) writes:
>In article <25715@oasys.dt.navy.mil> ruckman@oasys.dt.navy.mil (Christopher Ruckman) writes:
>>Can someone help me figure out how to compile/link my program and run
>>it under DOS using MS FORTRAN 5.1, pleeeeze!  I've spent hours thumbing
>>through the manuals, but I just can't seem to figure it out!
>>
>>I have a 486-50 with 16MB of RAM.  The program source code is about
>>2000 lines, and includes lots of real*8 and complex*16.  The biggest
>>array is something like 130 by 37 (complex*16).  I'd be glad to elaborate
>>if that's not enough info.
>
>Let's see:
>   Number of bytes for largest array is:
>       130 * 37 * 16 * 2 = 153920 > 64k.
                        ^  
Sorry, I was wrong in multiplying by 2. I thought that _each_
of the real and imaginary parts was of length 16. My conclusion,
however, is the same - to use the huge model since half the number
is still > 64k. 

Dov
From: sandee@Think.COM (Daan Sandee)
Newsgroups: comp.lang.fortran
Subject: Re: [HEL] what's wrong with the following simple code?
Date: 29 Sep 92 17:14:22 GMT
Article-I.D.: early-bi.1aa2teINNnmo
Distribution: world
Organization: TMC
NNTP-Posting-Host: telecaster.think.com

In article <90871@netnews.upenn.edu>, duong@chestnut.chem.upenn.edu (-3612) writes:
|> 
|> Pardon for my ignorance in my previous posting. The error I got when
|> compile from the  previous program is followed
|> 
|> f77 -c tt.f
|> Error on line 8 of tt.f: unbalanced quotes; closing quote supplied
|> Error on line 8 of tt.f: unbalanced parentheses, statement skipped
|> Error on line 8 of tt.f: Execution error unclassifiable statement

Your statement extends beyond column 72. Either break it up, or invoke
a compiler option (if available) to allow this. (Actually, I think
you're not starting at column 7, but somewhere halfway down the line.)

|> Error on line 10 of tt.f: Execution error unclassifiable statement

Apparently the 'c' isn't in column 1.


|> Error on line 27 of tt.f: Execution error unclassifiable statement
Apparently the 'c' isn't in column 1.

|> Error on line 31 of tt.f: missing statement number 2

That's right. It's missing. So supply it. (It's used in the read
statement in line 28).

Daan Sandee                                           sandee@think.com
Thinking Machines Corporation
Cambridge, Mass 02142                                 (617) 234-5044
From: chenyh@memstvx1.memst.edu
Newsgroups: comp.lang.fortran
Subject: Re: second()
Date: 3 Oct 92 03:13:09 -0600
Distribution: na
Organization: Memphis State University

In article <1a6r2uINNir6@early-bird.think.com>, sandee@Think.COM (Daan Sandee) writes:
> In article <BuzBLn.KrG@cs.dal.ca>, glenn@cs.dal.ca (Glenn McCarville) writes:
> |> I am doing conversion of fortran programs to C and have come across a
> |> fortran function second(). Is this a standard fortran function? What does
> |> it return? The libraries provided with the f2c translator do not have a
> |> definition for it.
> 
> No, second() is not standard Fortran. Commonly, it is supposed to return
> the CPU time consumed since the start of the program. Some O/Ses provide
> it as a Fortran-callable function (e.g., UNICOS). Otherwise you have to 
> figure out which equivalent O/S call to use.
> 
> Daan Sandee                                           sandee@think.com
> Thinking Machines Corporation
> Cambridge, Mass 02142                                 (617) 234-5044

===> In VAX FORTRAN here, it's SECNDS(), a good function if you want
to count the pgm.running time. say

StartT=SECNDS(0.0)
brah,brah,brah....
TotalT=SECNDS(StartT)

of course,it return seconds up to 0.01 sec.

CHEN
Newsgroups: comp.lang.fortran
From: cpaulse@magnus.acs.ohio-state.edu (Chris D Paulse)
Subject: Adjustable arrays
Organization: The Ohio State University
Date: Mon, 5 Oct 1992 17:18:33 GMT


In some code I'm trying to modify, there are declarations within subroutines
for arrays of size 1, for instance

      dimension v(1)

These arrays seem to be ajustable, as elements with indices greater than 1
are referenced within the subroutine.  Obviously, the declaration facilitates 
the correct addressing of the beginning of the array.  I can't seem to find
any reference to this sort of programming in the standard fortran texts.
Could someone please explain what is going on here?  For each of the arrays
declared, I want to add another dimension.  Should I make the adjustable
dimension the last one?  Any help would be welcome.

Chris Paulse
Newsgroups: comp.lang.fortran
From: bai@msiadmin.cit.cornell.edu (Dov Bai-MSI Visitor)
Subject: Re: How do I make MS Fortran 5.1 use lots of memory?
Organization: /usr/local/lib/news/organization
Date: Thu, 1 Oct 1992 13:29:09 GMT

In article <25730@oasys.dt.navy.mil> ruckman@oasys.dt.navy.mil (Christopher Ruckman) writes:
>In comp.lang.fortran, bai@msiadmin.cit.cornell.edu (Dov Bai-MSI Visitor) writes:
>> ........
>>If you hit in the future the DOS 640k limit, you can still use
>>the compiler under OS/2 and it would let you address 16M. I think
>>that Ver. 5.1 works also under MS-WINDOWS which may also let you
>>use the extended memory.
>     ^^^^^^^^^^^^^^^^^^^
>
>There's what I'd like to figure out how to do!  When I compile this
>program on our MicroVAX II, the largest array is actually 2470 by 19.
>This gives 2470*19*16=750k, which obviously won't fit in 640k.  When
>I compile and link using this array size, I get an executable that takes
>up 1447k on the disk!  Any hints on getting *this* beast to run on the
>PC using Win3.1, FORTRAN 5.1, and the MS QuickWin library?
>
>Thanks for your help.  8-)

I cannt verify if it works, becasue my version of MS-FORTRAN is 5.0.
However, I found this in an ad in Byte megazine:

  * Use the new /MW option with the FL command to invoke the 
    QuickWin library. For example: "FL /MW MYAPP.FOR" is all
    it takes to make MYAPP a Windows-base program.

Note also that you must use the [HUGE] attribute for large arrays
or the huge memory model even if you are working under Windows or 
OS/2.

Dov
From: dwright@ace.acadiau.ca (DON WRIGHT)
Subject: Re: What does RAN() do?
Organization: Acadia University
Date: Thu, 1 Oct 1992 12:22:01 GMT

In article <1992Sep30.180838.4602@ee.eng.ohio-state.edu> coil@sneezy.eng.ohio-state.edu (Stacy D. Coil) writes:
>From: coil@sneezy.eng.ohio-state.edu (Stacy D. Coil)
>Subject: What does RAN() do?
>Date: Wed, 30 Sep 1992 18:08:38 GMT

>I am trying to port a FORTRAN 77 program from Ultrix to IBM's AIX.
>Would any happen to know what the following function does.

>        RAN()

>It appears to take two REALs as arguements and returns a REAL.


>Any help would be appreciated.

>Stacy

>-------------------------------------------------------------------------------
>Stacy D. Coil                            The Ohio State University
>Student Programmer III          Electrical Engineering Computer Facilities
>coil@ee.eng.ohio-state.edu                    Columbus, Ohio
>coil@cis.ohio-state.edu                       (614) 292-1416
>-------------------------------------------------------------------------------
I would guess that it generates uniform random numbers in the range of 0
to 1.  Quite often the argument(s) contain a seed which is changed and used
to generate the next random number.  I've only seen it with one argument 
except on computers which used 16 bit integers to store two halves of a seed.
 =====================================================================
 Don Wright                         -Internet - DWRIGHT@ACE.AcadiaU.CA
 School of Business-Acadia University              Phone (902)542-2201
 Wolfville, NS, Canada-B0P 1X0                     Fax   (902)542-4111
Newsgroups: comp.lang.fortran
From: towne@lerc.nasa.gov (Charlie Towne)
Subject: Re: Is this a Compiler Bug ?
Organization: NASA Lewis Research Center
Date: Fri, 2 Oct 1992 14:12:19 GMT

In article <1992Oct1.195512.16735@chpc.utexas.edu>, ivab015@hermes.chpc.utexas.edu (Albert Wu) writes:
> The following program cannot be compiled by fortran compilers on a Sun as well
> as on a RS6000.  Apparently, the backslash is treated as a continuation
> symbol.  Is this considered a bug in this program or a bug in the compiler.
> 
>       program test
> 
>       character*30 string
> 
>       string = '1234567890123456\8901234567890'
>       ibksl = index ( string, '\' )
>       print *, 'ibksl=',ibksl
> 
>       end

I recently looked at this problem when porting one of my codes to other
systems.  I found that Fortran workstations from SGI, IBM, DEC, and Sun
treat the backslash as an escape character by default.  On a Convex
mainframe the default is to treat it as an ordinary character.

In cases where it's an escape character, doubling the backslash in
character strings is necessary to get an ordinary character.
(Alternatively, as pointed out by another poster, on at least some
machines there's a compiler option (-backslash on SGI, -xl on Sun,
don't know about others) that allows a single backslash to be an
ordinary character.)

-- 
Charlie Towne                        Email: towne@lerc.nasa.gov  
MS 5-11                              Phone: (216) 433-5851
NASA Lewis Research Center
Cleveland, OH 44135
Newsgroups: comp.lang.fortran
From: smadden@titan.trl.OZ.AU (Steve Madden)
Subject: Re: F77 Compilers for MS-DOS PC's
Organization: Telecom Research Labs, Melbourne, Australia
Date: Mon, 28 Sep 1992 08:02:33 GMT

hutch@edge1.pfc.mit.edu writes:

>Without much to add to this thread except my interest, can I expand
>thoughts to include the speed of the compile/link steps. My own experience
>with MS 5.0 (which is way better than 3.3 and 4.0) leaves me relatively
>satisfied, except that it takes for ever to compile.
>My comparison is primarily with VAX-VMS. At a rough guess, on machines
>that give roughly equivalent run-time program performance, the VAX compiler
>compiles at least 5 times faster. Why is MS FORTRAN so slow? The environment
>advantages of the PC are negated by this factor, making it a close call
>whether I prefer PC or VAX development. A compiler that was much faster
>than MS on the PC would probably tip the balance.

>More generally, I notice that much more attention is paid in these discussions
>to run time than compile time. However, from the programmer's viewpoint the
>latter may be much more important.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


You might want to try the Lahey or Salford compilers for 386 and 486 chips 
then. I've got the Salford compiler and it compiles at around 40,000+ lines
per minute on a 486-50 !!!! It just murders our mainframe (Dec 5500) :) 
Run time is also extremely impressive, and you get nice features with both
this and the Lahey compilers (i.e. easy to use and good debugger, graphics
support up to 1280x1024 with Salford, fantastic compile diagnostics, ......)
Also as these are 32 bit compilers, no segmentation problems a la MS F77
version 4.1 (I have'nt used 5.1 as I switched to Salford). Sure, these are
somewhat more expensive, but if you want to get your development time down, 
worth every penny. Ask for a demo version and see for yourself.

Have fun,


      /~~~\   !                           
      \___    !---   ___ .    .  ___       ###########################
          \   !     /___> \  /  /___>      # smadden@titan.trl.OZ.AU #
      \___/   \__/  \___   \/   \___       ###########################
From: duong@chestnut.chem.upenn.edu (-3612)
Newsgroups: comp.lang.fortran
Subject: Re: [HEL] what's wrong with the following simple code?
Date: 29 Sep 92 14:57:23 GMT
Organization: University of Pennsylvania


Pardon for my ignorance in my previous posting. The error I got when
compile from the  previous program is followed


f77 -c tt.f
Error on line 8 of tt.f: unbalanced quotes; closing quote supplied
Error on line 8 of tt.f: unbalanced parentheses, statement skipped
Error on line 8 of tt.f: Execution error unclassifiable statement
Error on line 10 of tt.f: Execution error unclassifiable statement
Error on line 27 of tt.f: Execution error unclassifiable statement
Error on line 31 of tt.f: missing statement number 2

Compilation exited abnormally with code 1 at Tue Sep 29 10:50:37

							duc
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: [HELP] what's wrong with the following simple code?
Date: 30 Sep 92 16:36:51 GMT
Article-I.D.: newshost.1992Sep30.163651.25674
Organization: Los Alamos National Laboratory

In article <27755@nntp_server.ems.cdc.com>, mstemper@ems.cdc.com (Michael Stemper) writes:
|> |>[...]
|> |>            equivalence (c,r), (c,ip)        !share data memory
|> |>            open (21, file='ftnmr.dat', form='unformatted',status='new')
|> |>            read (21) i,(R(j),j=1,abs(2*i))
|> 
|> You have defined an array 'r', but nothing called 'R'

In most Fortran's (and *standard* as of Fortran 90) the complier is
not case sensitive.  In fact, I've never seen a Fortran which was
case sensitive.  That is: `R' and `r' are the *same* identifier.
If someone wants to emphasize or de-emphasize something, the use
of case is common.  I don't know why `R' is emphasized above, but
it doesn't bother me.

|> [...]
|> Expecting someone to put the number of data items as the first element
|> in input is bad human factors engineering. The program should read until
|> it encounters EOF or a flag. If a data item count is necessary, the
|> program should count them. Computers count much better than people do.

Since the file is unformatted, the record lengths probably *were* counted
by computer: by the program which wrote the record to begin with (I'm 
assuming the "status='new'" is simply a mistake).

-- 
J. Giles
Newsgroups: comp.lang.fortran
From: simonm@mel.dit.csiro.au (Simon McClenahan)
Subject: Re: What are pointers
Organization: CSIRO DIT (Melb.)
Date: Tue, 6 Oct 92 03:14:36 GMT


In article <1992Oct5.163909.20209@netcom.com>, walt@netcom.com (Walt Brainerd) writes:
|> In article <1992Oct4.225738.18379@hubcap.clemson.edu>, jtbell@hubcap.clemson.edu (Jon Bell) writes:
|> > In article <3OCT199222373032@rosie.uh.edu> math1rb@rosie.uh.edu (92F07486) writes:
|> > >
|> > Uh... if this is a Fortran class, your prof needs to have his head examined.
|> > Fortran doesn't _have_ pointers.  At least standard Fortran doesn't.
|> 
|> Of course, this is sort of a cheap shot, but we must get used to
|> the fact that standard Fortran DOES have pointers.  Fortran 90
|> has been an international standard since early 1991 and is now
|> also an ANSI standard.  It's even possible that this prof is using
|> an implementation of Fortran 90.


It could also be that the prof meant to say "index array" instead of pointers,
i.e.

       x(i)=a(p(i))

where p is an array of indices in a ?

cheers,

--
Simon.McClenahan@mel.dit.csiro.au  \_\_ CSIRO Supercomputing Support Group
CSIRO Division of Information Technology _\_\_\_\_\_\_ tel: +61 3 282 2623
723 Swanston St, Carlton 3053 AUSTRALIA \_\_\_\_\_\_\_ fax: +61 3 282 2600
            	I'm writing a book.  I've got the page numbers done.
Newsgroups: comp.lang.fortran
From: grouleff@daimi.aau.dk (Morten Grouleff)
Subject: WANTED: public domain compiler.
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark
Date: Fri, 2 Oct 92 09:17:33 GMT

Can anybody tell me where I can get a PD compiler for ibm PC-clones ?
A FTP'able one would be fine....

Morten Grouleff
grouleff@daimi.aau.dk
Newsgroups: comp.lang.fortran
From: CCC_KARG@rzmain.rz.uni-ulm.de (ComRam)
Subject: Re: Quickie
Organization: Chaos Computer Club Ulm
Date: Tue, 6 Oct 1992 13:45:16 GMT
X-News-Reader: VMS NEWS 1.24

In <25960@oasys.dt.navy.mil> mulvihil@oasys.dt.navy.mil writes:

>       integer n
>       n=1
>       write(*,n)
>     1 format(2x,'my brain hurts')

How about a little ASSIGN 1 TO n
                   WRITE(*,n)
		 1 FORMAT(blubb)


Newsgroups: comp.lang.fortran
From: bai@msiadmin.cit.cornell.edu (Dov Bai-MSI Visitor)
Subject: Re: F77 Compilers for MS-DOS PC's
Organization: /usr/local/lib/news/organization
Date: Mon, 28 Sep 1992 12:47:25 GMT

In article <1992Sep28.092410.2472@news.Hawaii.Edu> tholen@galileo.ifa.hawaii.edu (Dave Tholen) writes:
>
>Similarly, if the two source files are compiled with Microsoft's compiler
>and the /Op switch, the radix is properly determined and the program gets
>much farther along.  But both die and cannot be restarted properly after
>the overflow occurs.  WATCOM's executables do make it to the end of the
>test, after three (or was it two?) restarts.

If you compile DPARA and SPARA with the -Od (disable optimizations)  
option under MS-FORTRAN 5.0, both executables can be restarted 
properly after being aborted on any of the floating point exceptions. 
SPARA passes with flying colors and DPARA end with 1-flaw, which is 
also very good.
From: aswx266@chpc.utexas.edu (Michael Lemke)
Newsgroups: comp.lang.fortran
Subject: Re: Is this a Compiler Bug ?
Date: 2 Oct 92 23:10:28 GMT
Organization: The University of Texas System - CHPC

In article <KHB.92Oct2134224@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (chiba) writes:
>
>In article <1992Oct2.174512.16640@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>
>   implementation is ASCII, the above program is standard conforming
>   *as is*
>
>Not true. Use of anything not in the FORTRAN character set renders your
>program beyond the scope of the standard. The "escape hatch" for
>constants and comments is that "processor" in the FORTRAN standard
>sense is not the physical CPU, nor the CPU+OS, it is merely that thing
>which handles FORTRAN programs ... *that* processor cannot be assumed
>to handle all of ASCII even if the CPU itself can.
>
>...
>   be solved.  In the above case, there is no reason that `\' should
>   not be simply accepted.
>
>Yes there is. A long standing Unix tradition of usage of \ dating back
>to the first Unix f77 compiler. Changing this behavior by default
>would break some large (but unknown in precise size) set of existing
>codes. 


So then what makes you decide which fraction of existing code you want 
to break:  Those which are standard conform except for exceeding the 
Fortran character set (which code does not use lower case?) or those 
which use the '\' as unnecessary escape for something?  I still don't
see any need for such an escape in Fortran.  We are not programming
Unix or C.  If there is actually such a lot of historic Unix Fortran
around (isn't that done in C anyway?) then add a -historic option or
something.  I really think this should work the other way round if at
all.

-- 
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
Newsgroups: comp.lang.fortran