HDTenEightyP/NetNews huggingface dataset:
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Small Language Wanted
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 27 Aug 1992 04:52:19 GMT

mbk@lyapunov.ucsd.edu (Matt Kennel) writes:

>UweKloss@lionbbs.bs.open.de ( Uwe Kloss) writes:
>: > In addition, C has nothing equivalent to Fortrans **
>: > operator nor does it have complex types.

Note however that C++ does have complex types.
C++ has a pow() function instead of an ** operator.
Admittedly this is less convenient syntactically,
even though exactly the same code will be generated.
Some people on comp.lang.c++ have been proposing to add
an exponentiation operator to C++.

>: > And arrays, C has no true array type
>: > like Fortran does (One must use pointers to pointers ... to pointers).
>: Did you ever try:     int a[12][34];
>: And             :     a[x][y] = somewhat;
>
>Yes, but try to use "a" in a subroutine.

void subroutine(int a[12][34]) {...}

If there are problems, could you please explain them better?

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.fortran
From: cflatter@nrao.edu (Chris Flatters)
Subject: Re: Scientists as Programmers (was Re: Smal
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Sun, 30 Aug 1992 23:24:09 GMT

In article IAy@mentor.cc.purdue.edu, hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>This statement is too broad.  Modularization is not a problem for the
>scientist, but it can be a major time-waster if the current software is
>used.  Subroutine calls are, at this time, and for the foreseeable future,
>quite expensive.  This was not the case when Fortran and Algol were first
>produced; there were few registers then, transfer was the fastest instruction,
>and context switching cost less than one multiplication.

Subroutine calls are not that expensive.  Here are some examples.

		function call+return		double precision fp operation
		(average time in us)		     (average time in us)

SPARCstation IPX	 0.115					0.146
25 MHz 386SX/387SX	 1.75					3.37

(IPX timing from Sun C++ 2.1 using -O4; 386SX/387SX timing taken from
GNU C 1.39 with -O under 386BSD 0.1).  Unless the work carried out in
a subroutine is trivial the overhead of a function call can be discounted.

>I have deliberately violated types to get the job done.  In fact, I see no
>good way out of it.  Now there might be some point to informing the programmer
>that types are violated, but very definitely not to insist on it, or to force

It is rarely necessary to violate type constraints in a strongly typed language.
When it is necessary it is possible to localize the code that does this.  Most
typesafe languages provide mechanisms to avoid the constraints of the type
system in these rare cases (eg. the WORD data type in Modula 2).

>Also, mathematicians especially use lots of operators.  Despite what the CS
>gurus say, allowing the introduction of additional functions is not the
>same thing.  Also, mathematicians and scientists are accustomed to using
>whatever syntax they like, as long as it does not lead to confusion.  But
>the CS people insist that only the standard operators are to be allowed to
>use infix notation, and all others must be prefix, except in reverse Polish
>systems, in which all must be postfix.  

Restrictions on the introduction of new operators arise from practical
considerations.  The introduction of a new infix operator changes the
syntax of the language significantly.

	Chris Flatters
	cflatter@nrao.edu
From: ankruger@icaen.uiowa.edu (Anton Kruger)
Newsgroups: comp.lang.fortran
Subject: Book: Efficient FORTRAN Programming for sale
Date: 4 Sep 92 18:47:52 GMT
Followup-To: ankruger@icaen.uiwa.edu (Anton Kruger)
Distribution: na
Organization: Iowa Computer Aided Engineering Network, University of Iowa

I have about 9 copies of my book:

              Efficient Fortran Programming
              John Wiley, 1991, 184 pages

for sale. The list price is $34.95 and I am selling it for $25, postage
included. If you are interested send a check/money order to:

             Anton Kruger
             215 Marengo Road #2
             Oxford, IA 52322

or contact me via e-mail. A review of the book appears in the March 1991 issue
of the ACM publication Fortran Forum.



-- 
-------------------------------------------------------------------------------
Anton Kruger                                           ankruger@icaen.uiowa.edu
Newsgroups: comp.lang.fortran
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Small Language Wanted
Organization: Los Alamos National Laboratory
Date: Fri, 28 Aug 1992 18:13:27 GMT

In article <1992Aug28.153021.1358@newshost.lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes:
|> In article <9224117.23480@mulga.cs.mu.OZ.AU>, fjh@cs.mu.OZ.AU (Fergus Henderson) writes:
|> |> [...]
|> |> The compiler must generate code that has the *same effect* as
|> |> simply converting to double and then calling pow(), but it is
|> |> quite free to substitute any equivalent code which may be more
|> |> efficient, for example by converting the call to a couple of inline
|> |> multiplications.
|> 
|> The above is literally true only if it's the language standard `pow'
|> function that's being called.  If a user supplied `pow' is to be used
|> it would probably be quite inapproptiate for the compiler to optimize
|> the call in the way described here.  [...]

I apologise for posting this incorrect statement.  In fact, all library
function names in ANSI standard C are reserved - the user can't define
his own.  So the above comment only applies to old K&R implementations
which allow the user to do so.  (It's what I get for remembering an old
public review copy of the C standard better than the final version.)

This policy of C will probably come back to haunt them: suppose the next
standard wants to add new functions to the standard library?  Reserving
the names will result in breaking any user codes which happen to have
functions with those new names.

-- 
J. Giles
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Small Language Wanted
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 27 Aug 1992 19:30:40 GMT

jlg@cochiti.lanl.gov (Jim Giles) writes:

>try:
>
>   void subroutine(n, m, a[n][m]) {...}
>
>Like for writing something as trivial as a matrix multiply routine
>which can multiply conformable arrays of any size:
>
>   void mat_mult(i, j, k, a[i][k], b[i][j], c[j][k])
>   {... /* returns `a' since arrays are passed by reference */ ...}
>
>Actually, this could be done by eliminating a *single* constraint in 
>the C standard - that is, the one which requires array sizes in declarations
>to be constant-expressions instead of allowing expressions in globals and/or 
>preceeding parameters.  I don't have the rationale document in from of me,
>so I don't know why they left that constraint in (or if the explained at
>all).

The constraint does make life quite a bit easier for compiler writers, which
was presumeably the reason it was there in the first place.

There *are* two possible remedies for this, although both have their
disadvantages. The first one is quite simple: gcc allows exactly the
construct you refer to. If you are willing to stick to the one compiler
(which *is* quite portable) then you can write code exactly like the
above. gcc even allows you to pass the array name before the array dimension,
so long as you forward-declare the dimension parameter, like thus:
    mat_mult(int i, j, k; /* forward declaration of parameters */
	     int a[i][k], int b[i][j], c[j][k], int i, int j, int k);

The other solution is to use a C++ matrix class. Then you don't even need
to bother passing the dimensions, and you can even use natural mathematical
notation - ie. a = b * c, instead of mat_mult(i, j, k, a, b, c).

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: jpr@lhdsy1.lahabra.chevron.com (John C. Prestridge)
Newsgroups: comp.lang.fortran
Subject: Help for rs6k passed arrays (old fortran)?
Date: 3 Sep 92 18:08:20 GMT
Organization: Chevron, La Habra, CA


Excuse me if this question was asked before.
 
In some old fortran programs, the array dimension is passed to the subroutine
with a argument size of 1,   For Example:
                
       DIMENSION A(10)
       DATA A/ 10*0.0 /
       CALL ABC(A)
       .
       .
       END
       SUBROUTINE ABC(A)
       DIMENSION A(1) 
       A(1) =  1.0 
       A(5) =  3.1         <-- a warning is generated for each a(i) where i>1
       A(7) =  5.5         <-- a warning is generated
       A(9) =  7.4         <-- a warning is generated
       A(10)= 10.0         <-- a warning is generated
       RETURN
       END
 
In many machines, the compilation of such a routine would not give compilation
errors and/or warnings, but on the rs6000 a warning is given about a CONSTANT
SUBSCRIPT IS OUT OF BOUNDS for each such occurrence in the code.  In many large
codes there are very large numbers of such occurrences.  Is there some method
to tell the compiler that the code is an earlier FORTRAN, so that such warnings 
would not be generated?    
 
Thanks for your help ...              John Prestridge
                                      (jpr@chevron.com) 
 

-- 
 -------------------------------------------------------------------------
   John Prestridge                           Internet:   jpr@chevron.com
   Chevron Oil Field Research Company                             
   P.O. Box 446, La Habra, CA 90633-0446
From: burley@geech.gnu.ai.mit.edu (Craig Burley)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 90 Advocacy
Date: 26 Aug 92 16:35:56 GMT
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
In-reply-to: sla@fast.ucsc.edu's message of 25 Aug 92 21:20:12 GMT

In article <17e86cINNma7@darkstar.UCSC.EDU> sla@fast.ucsc.edu (Steve Allen) writes:

   Herein I see a great problem.  I'd love to see Fortran survive and thrive.
   I do not see how that can happen if Fortran 90 compilers do not become almost
   as cheap as and available on as many platforms as GNU's GCC.  Craig Burley's
   admirable efforts to create GNU Fortran 77 demonstrate just how many man years
   are required.

   How can Fortran 90 be advocated best?  How can it get enough momentum to
   justify its introduction into High School computer classrooms?

Actually, the design and implementation hasn't taken a super long time --
and has included some F90 stuff.  Of the three years I've been a volunteer
working on GNU Fortran, about one year or more has been spent doing other
things -- waiting for equipment, contracting, hassling with administrative
issues, and so on.  And a lot of learning, that should help with an F90
when and if funding becomes available to do that.  Cutting the code has been
fairly easy so far!  On the other hand, my understanding of the F77 standard
was already pretty solid when I began, and my understanding of the F90
standard, despite reading it many times and offering useful (incorporated...)
changes to it to the X3 committee, is still pretty pitiful.  Also, F90 places
more demands on the GNU back end than does F77.
--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)
Newsgroups: comp.lang.fortran,comp.unix.cray
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Small Language Wanted
Organization: Los Alamos National Laboratory
Date: Fri, 28 Aug 1992 15:30:21 GMT

In article <9224117.23480@mulga.cs.mu.OZ.AU>, fjh@cs.mu.OZ.AU (Fergus Henderson) writes:
|> [...]
|> The compiler must generate code that has the *same effect* as
|> simply converting to double and then calling pow(), but it is
|> quite free to substitute any equivalent code which may be more
|> efficient, for example by converting the call to a couple of inline
|> multiplications.

The above is literally true only if it's the language standard `pow'
function that's being called.  If a user supplied `pow' is to be used
it would probably be quite inapproptiate for the compiler to optimize
the call in the way described here.  The C standard calls for some
more arcane rules involving which header files are present and how they
are defined to determine whether such optimizations are allowed.

-- 
J. Giles
From: john@aquarius.unm.edu (John Prentice)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 90 Advocacy
Date: 27 Aug 92 16:38:36 GMT
Organization: Dept. of Physics & Astro, University of New Mexico, Albuquerque

In article <1992Aug27.085114.2339@news.uni-stuttgart.de> ucaa2385@ruscvx.rus.uni-stuttgart.de (Peter Hermann) writes:
>
>Fortran comes closer and closer to Ada but will never reach it.

I don't see Fortran even on the same evolutionary path as Ada and I am
rather thankful for it!  Look at the yawn that Ada has created out there
in computing land and you can see that I am not alone in thinking that it
was a nice idea gone awry.

John
-- 
Dr. John K. Prentice                      
Partner, Quetzal Computational Associates    
3200 Carlisle N.E., Albuquerque, NM   87110-1664; 505-889-4543
john@aquarius.unm.edu -or- jkprent@cs.sandia.gov -or- prentice@rufous.cs.unm.edu
Newsgroups: comp.lang.fortran
From: walt@netcom.com (Walt Brainerd)
Subject: Fortran Journal
Date: Thu, 27 Aug 92 23:06:20 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Keywords: Fortran

FYI: Contents of the Jul/Aug _Fortran Journal_ include:

  o  How to do storage management in Fortran 77
     and some connections with object-oriented
     programming
     -- Peter Roth of the David Taylor Research Center

  o  Highligts of the June and July High Performance
     Fortran Meeting
     -- Rex Page of Amoco

Coming in the next issue:

  o  A report on an update of the Microsoft Fortran
     compiler that allows the output of graphics
     while running Windows

If you would like information about the _Fortran Journal_,
please send me e-mail.
-- 
Walt Brainerd                walt@netcom.com
Unicomp, Inc.                +1-415-949-4052
235 Mt. Hamilton Ave.        +1-415-949-4058 (fax)
Los Altos, CA 94022 USA      "F90--Fortran for the '90s"
From: jpr@lhdsy1.lahabra.chevron.com (John C. Prestridge)
Newsgroups: comp.lang.fortran
Subject: Clarification of: Help for rs6k passed arrays (old fortran)
Date: 3 Sep 92 22:42:59 GMT
Organization: Chevron, La Habra, CA

As a clarification of my previously posted request earlier today, 
There are very many old fortran codes being ported from other machines
to the RS6000 and it is not very efficient to edit each program to
change the 1 as a dimension in a passed array to a *.  Thanks to the
several persons who have already replied. 
 
                     John Prestridge  :-)  
                     (jpr@chevron.com)
 

-- 
 -------------------------------------------------------------------------
   John Prestridge                           Internet:   jpr@chevron.com
   Chevron Oil Field Research Company                             
   P.O. Box 446, La Habra, CA 90633-0446                        
Xref: sparky comp.lang.fortran:3293 comp.unix.cray:257
From: d-lewart@uiuc.edu (Daniel S. Lewart)
Newsgroups: comp.lang.fortran,comp.unix.cray
Subject: Re: CRAY-YMP single precision machine constants.
Date: 31 Aug 92 07:53:13 GMT
Reply-To: d-lewart@uiuc.edu (Daniel S. Lewart)
Organization: University of Illinois at Urbana
Originator: dslg0849@uxa.cso.uiuc.edu

ssp2537@tamsun.tamu.edu (Satya Srinivas Padavala) writes:

>      I am wondering if any knowledgeable soul could help me with the following
> problem. I have been using in my code, BLAS (Basic Linear Algebra Subprograms),
> which are routines called by public domain math packages such as LINPACK,
> EISPACK etc. I have recently started working on a CRAY-YMP and am need of the
> following machine constants for single precision for that machine.

>  1) Smallest positive magintude
>  2) Largest positive magnitude
>  3) Smallest relative spacing
>  4) Largest relative spacing
-------------------------------------------------------------------------------
*
*
*
*     Print machine constants, by Daniel S. Lewart (d-lewart@uiuc.edu).
*
      print 200, r1mach(1)
      print 210, r1mach(2)
      print 220, r1mach(3)
      print 230, r1mach(4)

200   format ( 'Smallest positive magnitude =', 1p, e17.9 )
210   format ( 'Largest positive magnitude  =', 1p, e17.9 )
220   format ( 'Smallest relative spacing   =', 1p, e16.9 )
230   format ( 'Largest relative spacing    =', 1p, e16.9 )

      end
-------------------------------------------------------------------------------
Smallest positive magnitude = 3.667207735-2466
Largest positive magnitude  = 2.726870339+2465
Smallest relative spacing   = 7.105427358E-15
Largest relative spacing    = 1.421085472E-14
-------------------------------------------------------------------------------
Daniel Lewart
d-lewart@uiuc.edu
Newsgroups: comp.lang.fortran
From: anselmo@cumesb.mech.columbia.edu (Andrew P. Anselmo)
Subject: copying files in FORTRAN on using Sun Fortran
Organization: Columbia University Department of Mechanical Engineering
Date: Fri, 28 Aug 1992 19:54:15 GMT
X-Posted-From: cumesb.mech.columbia.edu
X-Posted-Through: sol.ctr.columbia.edu


Sorry to intrude on the scientists can/cannot program  issue, but a small
technical problem...

How easy is it to submit unix commands while in a Fortran program?

I basically need to copy a file (without knowing the format or what's
inside) to another; I've RTFM, but I can't seem to track it down.

Thanks.

-A.
-- 
-----------------------------------------------------------------------------
 Andrew Anselmo / Department of Mechanical Engineering / Columbia University   
   236A SW Mudd Building 212-854-2965 / anselmo@cumesb.mech.columbia.edu 

Newsgroups: comp.lang.fortran
From: i2041101@rzphy1.rz.tu-bs.de (Paulini)
Subject: Re: Does your f77 compiler accepts this?
Organization: TU Braunschweig, Informatik, Bueltenweg, Germany
Date: Tue, 25 Aug 1992 21:37:54 GMT

In article <BtJyIM.1p2@mentor.cc.purdue.edu>, ags@mentor.cc.purdue.edu 
(Dave Seaman) writes:
|> 
|> The paragraph in question is concerned with complex *constants*.
|> 
|> 	(2.0,3.0) is an example of a complex constant.
|> 	(X,X) is not a constant, and is not legal Fortran.
|> 
|> If X is a real number, then the complex number X + iX is given in Fortran by
|> 
|> 	CMPLX(X,X)
|> 
|> where CMPLX is a required intrinsic function in the ANSI standard.
|> 
|> Each of the statements
|> 
|> 	WRITE (*,*) X
|> 	WRITE (*,*) (X)
|> 	WRITE (*,*) CMPLX(X,X)
|> 
|> is legal Fortran, but
|> 
|> 	WRITE (*,*) (X,X)
|> 
|> is not.
|> 
|> 
|> -- 
|> Dave Seaman
|> ags@seaman.cc.purdue.edu

(X,X) is a constant if 'X' is defined in a PARAMETER-declaration. Then

	WRITE (*,*) (X,X)

is legal, otherwise not.

-- 
Joachim Paulini                            Phone  0531-391-5190  (voice)
                                           Fax    0531-391-5833
TU Braunschweig                            e-mail i2041101@ws.rz.tu-bs.de
Institut f. Theoretische Physik
Mendelssohnstrasse 3 / 3300 Braunschweig / Germany
From: dtm@castle.ed.ac.uk (D Muxworthy)
Newsgroups: comp.lang.fortran
Subject: Re: Any free descriptions of Fortran 90 features available ?
Date: 4 Sep 92 08:10:36 GMT
Organization: Edinburgh University

In article <186stiINNdq1@darkstar.UCSC.EDU> sla@umbra.ucsc.edu (Steve Allen) writes:
[earlier attributions deleted]
>>(Jim Giles) writes:
>>>What exactly *is* the copyright requirement on the standard?  My copy of
>>>ISO/IEC 1539:1991(E) contains no copyright declaration at all.
>>Eh?  Page ii contains the following:
>>"(C) ISO/IEC 1991
>>All rights reserved.  No part of this publication may be reproduced or ...
>
>Interesting.  The copy I have of said document has no such notice on page ii.
>This does not mean that I will be dropping it into the copier hopper...

Just to clarify: the official ISO Swiss printing has the copyright
message on the inside front cover, which otherwise is the first page of
contents.
David Muxworthy
From: toon@moene.indiv.nluug.nl (Toon Moene)
Newsgroups: comp.lang.fortran
Subject: Re: scientists as programmers (was: Small Language Wanted)
Date: 26 Aug 92 20:52:39 GMT
Organization: Moene Computational Physics, Amsterdam, The Netherlands

In article <1992Aug26.102735.12519@wl.com> schuette@wl.com (Wade Schuette)  
writes:

[ ... Lots of stuff on language debate / programming proficiency
      deleted ... ]
> Or maybe, this: if you had ONE thing you could try to get across, that 
> would make sense to that audience in that time frame, what would it be?

The number of floating point numbers representable in N bits is strictly  
less than the number of integers representable in N bits.

(Explanation: (why - this should be obvious) Scientists (at least the  
people I work with) take the - infortunate - FORTRAN declaration of  
floating point variables as REALs as a testimony that they have some  
relation to the notion of the set of real numbers - silly sounds of  
course: they're only a finite subset of the rationals ...)

--
Toon Moene (toon@moene.indiv.nluug.nl)
Kantershof 269, 1104 GN  Amsterdam, The Netherlands
Tel.: + 31 20 6982029; Fax: + 31 20 6003411
No Disclaimers; a NeXT at home protects against this occupational hazard.
From: okuyama@pioneer.arc.nasa.gov (Darin Okuyama YR)
Subject: call graph tool
Summary: call graph tool
Keywords: call graph tool
Organization: NASA Ames Res. Ctr. Mtn Vw CA 94035
Date: Wed, 2 Sep 92 14:02:56 GMT

Does anyone know of a widely available tool
that will produce a call graph of a FORTRAN
program by reading its source.

Darin Okuyama
NASA Ames Research Center
From: jrbd@craycos.com (James Davies)
Newsgroups: comp.lang.fortran
Subject: Re: Size of executables
Date: 3 Sep 92 23:31:39 GMT
Organization: Cray Computer Corporation

In article <9209031948.AA10327@ros6.gsfc.nasa.gov> mukai@ROS6.GSFC.NASA.GOV (Koji Mukai) writes:
>
>One recent post compared the size of executables between Fortran and C,
>in passing.  That has reminded me of something I've noticed a long time
>ago:  the size of the executable files are very different between VAX/VMS
>(PROG.EXE) and UNIX (a.out) versions.
{...}
>I don't have detailed numbers but the Sun Fortran versions tend to
>be 4-10 times bigger than the VAX/VMS version, whenever I checked.
>
>(1) Why?   (Just curious)

Shared libraries make a big difference.  Both Sun and VMS have shared 
libraries enabled by default, but apparently VMS does a more thorough
job of shoving stuff into the shared part.

>(2) Can I make the Sun executables any smaller (the above numbers are
>after strip)?  Am I missing some compiler switches or something?

You could make them *bigger* by specifying -Bstatic.  This would be
a way of finding out how much space the shared libraries are saving you.
For example, linking with -Bstatic (on a sparc) increases the stripped 
executable size of a C hello-world program from 16K to 98K.  However, the
printf library support alone accounts for about 75K of that 98K.

>(3) Are there any penalties for big executables, apart from the obvious
>need for more disk space?  Or for that matter, any advantages?

Using shared libraries might allow different processes to share read-only
code pages, so system memory might get better used, and load time might
be less since they wouldn't have to get paged in initially by your program.
Newsgroups: comp.lang.fortran