HDTenEightyP/NetNews huggingface dataset:
From: lionel@quark.enet.dec.com (Steve Lionel)
Newsgroups: comp.lang.fortran
Subject: Re: Adjustable arrays
Date: 7 Oct 92 15:47:26 GMT
Article-I.D.: e2big.1992Oct7.154726.10898
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH


In article <1992Oct5.171833.16706@magnus.acs.ohio-state.edu> 
cpaulse@magnus.acs.ohio-state.edu (Chris D Paulse) writes:
|>
|>   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.
|>

This is a widely-implemented extension to the FORTRAN-66 standard which
causes arrays with a last dimension bound of 1 to be treated as if they
were assumed-size arrays (last dimension bound of * in FORTRAN-77).  It's
rarely documented in compiler manuals, but it's necessary to make a lot of
old code work properly when bounds checking features are in use.  Digital's
Fortran compilers, for example, implement this extension.

I recommend replacing the "1" with a "*", then use normal FORTRAN-77 syntax
to add additional bounds as you need.
--

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
From: Peter.Hammond@brunel.ac.uk (Peter D Hammond)
Newsgroups: comp.lang.fortran
Subject: Re: Command Line Parameters
Date: 12 Oct 92 08:10:27 GMT
Organization: Brunel University, Uxbridge, UK
X-Newsreader: TIN [version 1.1 PL6]

David Gaudine (david@donald.concordia.ca) wrote:
: Can someone tell me how to read command line parameters from FORTRAN
: under UNIX?  (Specifically ULTRIX, but some portability would be nice).
: 
	{and some other stuff}

With Sun FORTRAN there is an extrinsic library function (is that the correct
terminology?) called getarg(i, char) which returns the i'th argument in 
the string char. I believe similar routines exsist in other vendors' libraries.
There is also a function iargc which returns the number of command line
arguments.

For example:

	program demo

	integer		i	! Counter
	character*20	arg(3)	! The arguments
	integer		iargc	! Number of args. function
	integer		args	! The number of args.

	args = iargc()
	if (args .lt. 1) then
		call getarg(0, arg(1)) ! Put the prog. name in arg(1)
		write (0,*) "usage: ", arg(1), "arg1 [arg2 [arg3]]"
		call exit (2)
	endif

	do 10 i = 1, args
		call getarg (i, arg(i))
 10	continue

 C And now, the rest of the program......


Hope this is of some use, though I know portability is limited.

-- 
BFN, Pete.

 Dept. Materials Technology | Dont pay any attention. | You sometimes have to  
 Brunel University          | Its only my opinion.    |    listen to
 Uxbridge                   |                         | A lot of useless talk.
 Middx, UB8 3PH, UK.        |                         |         N. Peart. (RUSH)
Newsgroups: comp.lang.fortran
From: joelw@convex.com (Joel Williamson)
Subject: Re: passing arrays as parameters
Date: Fri, 16 Oct 1992 14:45:45 GMT
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In article <16OCT92.07182890.0071@VM1.MCGILL.CA> UBCF@MUSICB.MCGILL.CA (UBCF) writes:
>
>
>     dimension A(100,100),x(100),b(100)
>     .
>     .
>     {read in current value of size, N}
>     call routine (A,b,N)
>
>then the program doesn't work. What I'd like to know is is there any
>way that I can run this under the fortran 77 standard without
>manually changing the dimensions and recompiling for each case? Since
>I've got about 70 different cases that I have to test, I don't really
>want to have to run the program 70 times. Anyway, thanks in advance.

You haven't shown how A is initialized.  Presumably it is initialized in
the calling routine.  If so, try

	call initialize (A,N)
	   	...

	subroutine initialize(A,N)
	dimension A(N,N)
		...

This will initialize A as an array of the same shape as the dummy
argument of 'routine.'

>
>Scot Hughes
>UBCF@MUSICB.MCGILL.CA
>scot@emf.lan.mcgill.ca

Hope this helps,

Joel Williamson
--
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.lang.fortran
Subject: Re: cray paranoia
Date: 11 Oct 92 01:39:21 GMT
Organization: CWI, Amsterdam

In article <1b7gseINNlrl@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
 > And what if, in fact, you spent megadollars just to always get that last bit
 > ``correct''?  It's still just an approximation, anyway, so if you really
 > needed to make sure it's right (enough), you'll be using two methods for
 > computing something critical anyway.
Right, but see below.
 > 
...
 > I can see how the particular type of cray arithmetic used might make 0.2%
 > of programs somewhat harder to write than IEEE.  However, it makes Cray
 > programmers aware of the fact of approximation in FP arithmetic, which doesn't
 > ever go away no matter how you do it.  People who say Cray is "wrong"
 > and Sun is "right" mostly make Sun programmers complacent.

It does not make your programs harder to write, it makes your error
analysis more difficult.  When doing error analysis you have to start
somewhere, and that somewhere is mostly the base arithmetic which is
correct in so-and-so many binary digits.  Based on that you can (in
many cases) give an estimate of the error bounds in your final result.
Getting the arithmetic right gives you a good start: base operations
have an error of at most 2^(-53).  You can take the mantissa size as
a base for your error analysis.  Not so on the Cray.  The relative
error on a multiplication is not bounded by 2^(-48) as it would be if
proper rounding was done, nor 2^(-47) as it would be if improper rounding
within bounds was done, but 2^(-46); the last bit can be incorrect.
For division it is worse, the relative error can be 5 ULPs, leaving you
with a relative error bound of 2^(-45).  So if you look at the machine
as a machine with 45 bits of precision (plus some extra on occasion)
you are alright, but where can I find that in Cray's literature?  And
also, that sometimes extra precision can make it more difficult.
Given this, going from single precision to double precision is
extremely difficult (it must be done in software, there is no hardware
support).  I have heard reports that Cray did not get it right, and
that on occasion the results of your double precision program will be
worse than those of your single precision program.  (Some memories,
the CDC 205 64-bit arcsine gave 18 bits of precision.  Less than the
32-bit version, which was good in 22 bits.)

(And of course some people do not like it when 3.0/3.0 != 1.0.)

I agree that you should look at the results of Kahan's Paranoia with
reservation.  It just tries to find out how much the arithmetic
deviates from optimal arithmetic, and does well in that aspect.
But if you are willing (as is Cray) to give up 3 bits of precision
just for speed, go with it (which is just what I do), but be aware of
what you are doing.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
From: schultz@unixg.ubc.ca (Stewart Schultz)
Newsgroups: comp.lang.fortran
Subject: Re: ABSOFT Fortran ---> f77? SOLVED
Date: 10 Oct 1992 01:19:18 GMT
Organization: University of British Columbia, Vancouver, B.C., Canada
NNTP-Posting-Host: unixg.ubc.ca

Only two (nontrivial) changes were necessary to make this
conversion.  The ABSOFT version used unit 9 as standard input;
this was fixed by changing read(9 to read(* and write(9 to
write(* .  ABSOFT also used unit 6 to write to a file; this
was fixed by changing all instances of write(6 to write(8,
open(6 to open(8, and close(6 to close(8.

There were a couple instances of several commands on a single
line as well (allowed by ABSOFT, not by f77).

Thanks to Keith Bierman, Ian MacPhedran, Edwin Vollebregt,
Richard Ball, and Steve Ellner.

-Stewart Schultz
From: UBCF@MUSICB.MCGILL.CA (UBCF)
Newsgroups: comp.lang.fortran
Subject: passing arrays as parameters
Date: 16 Oct 92 11:39:02 GMT
Organization: McGill University


     I've got a bit of a problem with a program I'm working on. I have
to use some external routines (ie LINPACK) to solve a set of equations
in a program I'm writing using the VSFORT 2.0 compiler, which implements
the F77 standard. I'm trying to solve Ax=b, where A is a matrix and x
and b are vectors. I have to pass A and b to the routines, which then
solve for x. The problem is that I'm trying to write a general purpose
routine, since the size of x can vary anywhere from 5 to 100. At the
start of the program I tried to declare

       DIMENSION A(100,100),x(100),b(100)

so that all of my cases would be covered. The problem is that the
external routine crash and burn unless A,x and b are dimensioned to
exactly the size that they have for the current case. What I mean, is
that if the current size is 5, everything blows up unless the
initial declaration of the variables is A(5,5),x(5),b(5). What I don't
understand is that the external routine also requires that you pass
the CURRENT dimensions of the variables. So, if I initially have

     dimension A(100,100),x(100),b(100)
     .
     .
     {read in current value of size, N}
     call routine (A,b,N)

then the program doesn't work. What I'd like to know is is there any
way that I can run this under the fortran 77 standard without
manually changing the dimensions and recompiling for each case? Since
I've got about 70 different cases that I have to test, I don't really
want to have to run the program 70 times. Anyway, thanks in advance.

Scot Hughes
UBCF@MUSICB.MCGILL.CA
scot@emf.lan.mcgill.ca
Newsgroups: comp.lang.fortran
From: jumper@garfield.catt.ncsu.edu (Michael Lanham)
Subject: stdout & *: can C and FORTRAN share them?
Organization: North Carolina State University
Distribution: comp
Date: Mon, 12 Oct 1992 18:25:23 GMT

I am still working on a conversion between old fortran code and C.  The
fortran code enables the users to either print to stdout(tty) or to a file
depending on user input.  The write statements look something like:
write (outfil,350); where outfil=0 for tty output and the unit number for file
output.  I also have some C code called by the fortran code.  The C also needs
to write to stdout.  the way I am trying is this:
fprintf(yyout,"%s",mystring) where yyout = stdout for tty output and a
different file pointer otherwise.

So far, it does not work!  Is Fortran not allowing C access to files it opens?
I have tried having the program write to tty and to file but neither seems to
be working.  What gives?


He who will not reason, is a bigot; he who cannot is a fool;
and he who dares not is a slave.      --- Sir William Drummond

Michael Lanham       mjlanham@eos.ncsu.edu   &  jumper@catt.ncsu.edu
Newsgroups: comp.lang.fortran
From: urjlew@ecsvax.uncecs.edu (Rostyk Lewyckyj)
Subject: Re: Quickie
Summary: No! Write(*,'(A)')message(n) is better
Organization: UNC Educational Computing Service
Date: Sat, 10 Oct 1992 18:59:57 GMT

In article <9080039@hpfcso.FC.HP.COM>, cunniff@hpfcso.FC.HP.COM (Ross Cunniff) writes:
> Lawrence Mulvihill writes:
> >Silly fortran question 980678
> >
> >      integer n
> >      n=1
> >      write(*,n)
> >    1 format(2x,'my brain hurts')
> >    2 format(.....
> >    .
> >    .
> >    .
> >
> >
> >Does not work.  How to fix?  Suggest IF statements and I bite you.
> 
> At least two people responded with the solution:
> 
>       integer n
>       assign 1 to n
>       write(*,n)
>     1 format(2x,'my brain hurts')
>     2 format(.....
>     .
> 
> but note that the assign statement is not terribly flexible (on purpose):
> you cannot say something like:
> 
>       read(*,*)i
>       assign i to n
> 
The gist of the problem was how does one choose the write statement
that will be executed. For this the ASSIGN just obfuscates the code
One would need something like a computed go to to reach the ASSIGN
and then branch away after the write.
      go to(100,200 ...)n
999   go to 99999 ! error exit
100   ASSIGN 1 to n
      write(*,n)
1     format( ... )
      go to 9999
200   .....
 ....
9999  continue
One might just as well branch directly to a write statement with
a hard coded format statement
> It will get you a syntax error for your troubles.  I personally prefer the
> character array solution proposed by a few people:
> 
>       character*80 fmts(nfmts)
>       data fmts /
>      +'(2x,''my brain hurts'')',
>      +'(...
>      +/
>       n = 1
>       write(*,fmts(n))
> 
I vote in favour of putting the messages in an array and then
writing the chosen message with a simple alph format.
    WRITE(*,'(A)')message(n)
I belI keeps the what is to be written and how it is to be written clearer.
Think of the general form of the write statement
    WRITE(where,how)what


-----------------------------------------------
  Reply-To:  Rostyslaw Jarema Lewyckyj
             urjlew@unc.oit.unc.edu    (ARPA,SURA,NSF etc. internet)
          or urjlew@unc.bitnet
          or urjlew@ecsvax.UUCP 
       tel.  (919)-962-6501

Newsgroups: comp.lang.fortran
From: ungar@leland.Stanford.EDU (Jeffrey Ungar)
Subject: The Cray YMP fails paranoia arthmetic test?!
Organization: DSG, Stanford University, CA 94305, USA
Distribution: usa
Date: Fri, 9 Oct 92 19:23:44 GMT

While testing a Monte Carlo program recently, I uncovered what appeared
to be huge inconsistencies between the results calculated in a short
run on a 486 PC and those calculated for the same test data on the Cray.
To make matters more confusing, the results calculated on an RS/6000
were different from both of these runs. All sorts of nightmares came
to mind, such as wild pointers (this was a combined C-F77 program), etc.

Extensive debugging revealed that the energy changes calculated on the
Cray were slightly different from those calculated on the 486. Normally
this would not cause many problems ( the differences were in the last
digit or two ) except that a difference that should have evaluated to
zero became about -1e-13. Unfortunately, this resulted in one less call
to a pseudo random number generator, which meant the the calculations
on the two machines would diverge at that point. It was easy to change
the test used to decide whether to accept a MC step or not to avoid
potential inconsistency, but the behavior prompted me to test the Cray's
arithmetic using the paranoia program from netlib.

According to dpara.f the arithmetic has 2 serious defects, one defect,
and 2 flaws.

According to spara.f the arithmetic has 2 FAILURES (things like 5!=1+4)

The C version uncovers similar problems. What gives?

Jeff Ungar
--------------------------------------------------
"I usually don't expect this sort of behavior from
 a major appliance" -- B.M. in Ghostbusters
Newsgroups: comp.lang.fortran
From: hayes@bach.udel.edu (Hayes Williams)
Subject: Fortran code maintenance problem.
Organization: University of Delaware
Date: Sun, 11 Oct 1992 18:54:59 GMT


Dear Fortran Net-World,

Our research group has a problem.  We have a set of codes of about
80,000 lines which is in the process of development.  Unfortunately
the development centers are separated by significant physical and 
hardware barriers.  We have three main sites, one in America and two
in Poland.  The site in America does production runs on an IBM RS6000/950
running Aix and IBM3090 under CMS/XA.  The sites in Poland run on an 
IBM RS6000/550, a 320,  and so-called "super" PC's (486/33 and 50 Mhz 
type).  Note the variety of operating systems (UNIX and DOS) and fortran 
compilers.  These sites are connected by email and of course real mail.  

Our problem is maintaining the codes.  When, for example, one Polish 
site makes changes to the code, the American site would like to 
minimize the effort in reinstalling the changes.  So we need some 
kind of software maintenance program.  I've looked at the FAQ and 
seen some tantalizing references, for instance, SCCS on unix
for maintaining code on one system.  Also a utility which merges and
demerges text and fortran code to aid with documentation. 

One of our main requirements is probably K.I.S.S. (Keep It Simple Stupid). 

I'd be interested in tales of similar situations including do's and
don'ts.  Any suggestions would be much appreciated and read carefully.  
Please email me any responses and I will post a summary to the net.

Sincerely,

Hayes Williams
williams@mp.bartol.udel.edu
Newsgroups: comp.lang.fortran
From: dnl@convex.is.macsch.com (David Lombard)
Subject: Re: passing arrays as parameters
Organization: MacNeal-Schwendler Corp.
Date: Fri, 16 Oct 92 20:41:38 GMT

I can't believe some of the answers for the question about
initializing and passing variably dimensioned arrays!  Surely some of 
you were being facetious!  

The CLEANEST way to handle the problem, as one reasonable response stated,
is to call an initialization routine and pass the start of A and its dimension.

For example:

      program fred

	parameter(
     &	  maxdim=100,
     &	  maxsiz=maxdim*maxdim)

	dimension
     &	  A(maxsiz), b(maxdim)

	write(*,*) 'Dimension?'
	read(*,*) N
	if( N.lt.1 .or. N.gt.maxdim ) then
	  write(*,*) 'N out of range 1 to ',maxdim
	  call exit
	endif
	call rdarr( A, N, N )
	call rdarr( b, N, 1 ) !or call rdarr( b, 1, N )
	call routine( A, b, N )

	...

      end

      subroutine rdarr( a, m, n )

	dimension
     &	  a(m,n)

	do  i=1,m
	  read(*,*) (a(i,j),j=1,n)  ! Note the `transposed' read.
	enddo

      end

The leading dimension (LDA) technique is useful to allow hard dimensions to 
work AND to allow an array to be sized to avoid memory bank conflicts and `
the like (an advanced topic).

If `routine' requires LDA, then the call would be:

	call routine( A, N, b, N )
c                     A
c                        LDA
c                           B
c                              N

Remember,
	K I S S

Regards,
DNL
******************************************************************************
*               MY COMMENTS == MY OPINIONS != ANYBODY ELSES                  *
******************************************************************************
* David N. Lombard                               The MacNeal-Schwendler Corp *
* dnl@macsch.com                                 815 Colorado Blvd           *
* (213) 259-4911                                 Los Angeles, CA  90041      *
******************************************************************************
From: mstemper@ems.cdc.com (Michael Stemper)
Newsgroups: comp.lang.fortran
Subject: Re: Quickie
Date: 8 Oct 92 21:53:18 GMT
Reply-To: mstemper@ems.cdc.com
Organization: Empros Systems International, a division of Ceridan

In article <1992Oct8.021427.8589@ecsvax.uncecs.edu>, urjlew@ecsvax.uncecs.edu (Rostyk Lewyckyj) writes:
|> In article <1992Oct6.134516.25053@wega.rz.uni-ulm.de>, CCC_KARG@rzmain.rz.uni-ulm.de (ComRam) writes:
|> > 
|> > How about a little ASSIGN 1 TO n
|> >                    WRITE(*,n)
|> > 		 1 FORMAT(blubb)
|> > 
|> 
|> There have been two other suggestions:
|> Store the formats in character arrays and WRITE(*,fmt(n))  and
|> Store the messages in arrays and write them with a common format 
|> WRITE(*,'(A)')msg(n). (Please check if there must be a field
|> width for the A format item Aw ).

If no width is specified, the width of the item (trailing blanks and
all) will be used.

|> I prefer either of these two over the ASSIGN, because to get to
|> the ASSIGN one would need something like a COMPUTED GO TO
|>       GO TO (100,200,.....),n
|> 999   GOTO 99999 ! Error escape
|> 100   ASSIGN 1 TO n
|>       GO TO 9999
|> .........
|> 9999  WRITE(*,n)

The much-maligned ASSIGN statement is an executable statement. It may
be reached in normal sequential program flow without use of any GOTO's
(computed or otherwise). The example ComRam gave will work as shown.

Use of CHARACTER arrays to store the formats is the preferred way to
take care of this problem, however.

-- 
#include <Standard_Disclaimer.h>
Michael F. Stemper
Power Systems Consultant
mstemper@ems.cdc.com
From: pld@hpfcso.FC.HP.COM (Paul Dineen)
Date: Thu, 8 Oct 1992 02:44:37 GMT
Subject: Re: Calling FORTRAN from C; Losing sleep.
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.lang.fortran

> My cc gave a 'function undefined' error. Here are the programs. 
> I need urgent help to solve a major problem.
> 
> ******C code*****
> 
> #include<stdio.h>
> main(int argc, char *argv[]){
> 	int sm, a1, a2;
> 	a1 = atoi(argv[1]);
> 	a2 = atoi(argv[2]);
> 	sum(&a1, &a2, &sm);
> 	printf("%d + %d = %d\n", a1, a2, sm);
> }
> 
> 
> *****FORTRAN code****
> 
> c	nice program
> 	call sum(A1, A2, S)
> 	stop
> 	end
> 	subroutine sum(A1, A2, S)
> 	S = A1 + A2
> 	return
> 	end

 When I slapped this code onto my HP and compiled, I got some unresolved
 externals for Fortran I/O routines that were needed because of the STOP
 statement.  But, the question is, if you're only using the sum
 subroutine in that file, why do you have a main program?  Presumably
 it's also a stand-alone program.  So, on an HP, you'd either remove the
 Fortran main program, or you'd use -lcl on the cc line.  Of course, the
 details are probably different on the system you're using, but that's a
 start.
Newsgroups: comp.lang.fortran
From: FC138001@ysub.ysu.edu (Phil Munro)
Subject: Re: Adjustable arrays
Organization: Youngstown State University
Date: Fri, 9 Oct 1992 13:23:58 GMT

In article <533@rama.UUCP>
bcs@rama.UUCP (Brian Spollen) writes:
 
>  A possibility previously unexpressed here:
>
>  Fortran, in its infinite, uh, flexibility, typically allows accessing of
>  arrays beyond what the declaration indicates, so the array may, in fact,
>  not be adjustable at all.  Hence, declaring the array with a * may not
>  be appropriate (only if the variable involved is an argument to the
>  subroutine).
>
>  For example, the following code will compile (on the Sun and VAX):
>
>      PROGRAM TEST
>      INTEGER IDUM(1)
>      IDUM(3) = IDUM(1) + IDUM(2)
>      STOP
>      END
>
>  Note that IDUM is not an argument.  Also note that this will produce
>  very unreliable results when executed, and I advise always matching
>  the dimension of a local variable to its possible uses, unless you
>  deliberately intend to give someone else maintenance nightmares in the
>  future.
 
  In some cases it is quite convenient to have an expandable dimension.
I maintain and use a program under VS Fortran which has a variable which
can be dynamically expanded using operating system memory.  That is, an
assembler routine is called to check for, and get, system memory outside
the program load, and return the array arguments needed for a particular
variable.
 
  There is no way to know what those array arguments will be, so the
base program *must* allow array arguments beyond some set value.  Of
course this kind of memory management must be carefully done!!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  FC138001@ysub.ysu.edu  Phil Munro       Youngstown State University
  Electrical Engineering Department           Youngstown  Ohio  44555
Newsgroups: comp.lang.fortran