HDTenEightyP/NetNews huggingface dataset:
From: ungar@leland.Stanford.EDU (Jeffrey Ungar)
Subject: Re: Small Language Wanted
Organization: DSG, Stanford University, CA 94305, USA
Date: Fri, 28 Aug 92 06:38:02 GMT

In article <DAVIS.92Aug28015332@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu  (John E. Davis) writes:
>
>In a previous article <DAVIS.92Aug27211418@pacific.mps.ohio-state.edu> I
>presented a C program which demonstrates that simply including math.h into a C
>program does not guarantee that `float y, x = 2.0; int i = 4; y = pow(x,i)'
>will produce the correct value for y as a previous poster suggested:

        [deleted]
>
>It has been pointed out to me by several people that this is compiler
>dependent and the a true ansi compliant answer will produce the correct
>answer. This is because instead of a declaration like:
>
>the ANSI declaration would read:
>
>                   extern double pow(double, double);
>
>This has the effect of performing the correct typecasts before calling the
>function `pow'.
>But then this behavior contradicts something else the other poster said:

     [compiler could use different methods for different argument
      types, like putting x*x inline for pow(x,2)]

>Are there really any existing C compliers out there that perform such
>optimizations?       

Yes. The Cray standard C compiler does this (and has "comformant arrays" and
complex data types as well) unless you turn off extensions -- it also
vectorizes all of these functions. The Watcom C compiler does not do this
but can place math functions inline in your code using 80387 instructions
like fsin and fsqrt (but it's up to you to ensure that no exceptions occur).

>
>--
>     _____________
>#___/John E. Davis\_________________________________________________________
>#
># internet: davis@amy.tch.harvard.edu
>#   bitnet: davis@ohstpy
>#   office: 617-735-6746
>#

P. Jeffrey Ungar     ungar@Embezzle.stanford.edu
From: hou@agouron.com (Xinjun Hou)
Newsgroups: comp.lang.fortran
Subject: AIX FORTRAN (xlf) questions
Keywords: FORTRAN, bugs, features
Date: 25 Aug 92 18:01:38 GMT
Organization: Agouron Pharmaceuticals, Inc., San Diego, CA

1) xlf
I have trouble using the SNGL function on a RS/6000-520.  The compiler
gives error message for a statement demonstrated below:

      PROGRAM FOO
        EH = SNGL(5.0)
      END

The "%xlf foo.f" gave following messages:
>
>  2.14   1513-041: (S) Arguments of the wrong type were specified for\
>  the INTRINSIC function sngl.
>** foo   === End of Compilation 1 ===
>1501-511  Compilation failed for file foo.f.
>

Neiter does it accept EH = SNGL(A) where A is a real*4

It compiled OK with 5.0 is changed to 5.0D0.  It seems like that SNGL
requires a double precision argument, but the reference manual of xlf
says that SNGL can take any real arguments (XLF ref manual p160)

2) .o files

   It appears that the .o file will not be removed if the compilation
   failed.  This could cause a problem for make. Is this a bug or a
   feature?

   
Any help would be appreciated.

 - 
-- 
Xinjun Jason Hou                                       010110000110100101101110
Agouron Pharmaceticals, Inc                            011010100111010101101110
hou@agouron.com                                        010010000110111101110101
Newsgroups: comp.lang.fortran
From: davis@pacific.mps.ohio-state.edu ("John E. Davis")
Subject: Re: Small Language Wanted
Reply-To: davis@pacific.mps.ohio-state.edu  (John E. Davis)
Organization: "Dept. of Physics, The Ohio State University"
	<H.3lvmyc56w&A@lionbbs.bs.open.de>
	<1992Aug27.181926.5677@alchemy.chem.utoronto.ca>
	<9224107.5975@mulga.cs.mu.OZ.AU>
Date: Fri, 28 Aug 1992 02:14:18 GMT

In article <9224107.5975@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
   [...]
   Well, you are wrong.
   [...]
   Furthermore, when it sees

           pow(a,i)

   in your code, and "i" happens to be an integer then it can emit code to
           - call the standard pow() function after convertin
             i to a double
           - call a special function the calculates doubles to
             integer powers
           - calculate the exponentiation using inline code.
   Ie. it can make EXACTLY the same optimizations that Fortran compilers
   make when they see a**i.
   In other words, the _ONLY_ differences between an operator and a function are
           (1) the syntax is different
           (2) for the function, you should include the appropriate header file
               before using it.
   [...]
   Any function that is part of the standard library is a "built-in" function.


Hmm... don't bet on it.  Let's see:

/* t.c --- A small program which demonstrates one reason why Fortran is better
   than C for numerical work.  It also shows that the above poster is wrong.

    To build:  save this file with the name t.c.  Then issue the shell
    command:

            %  cc t.c -lm

    Note that -lm is passed to the linker for linking with the math library. */
       
#include <stdio.h>
#include <math.h>  

int main()
{
    int i;
    float x, y;

    x = 2.0;
    i = 4;

    /* i and x should be cast to double for this to work properly */
    y = pow(x, i);

    (void) fprintf(stdout, "%f = pow(%f, %d)\n", y, x, i);
    return(0);
}
   
[8:52pm] /net/pacific/4/davis>cc t.c -lm
[pacific]
[8:52pm] /net/pacific/4/davis>./a.out
1.000000 = pow(2.000000, 4)


This was compiled on a sun sparc station.

Also note that all the comments and documentation in the world couldn't have
saved this program.
--
     _____________
#___/John E. Davis\_________________________________________________________
#
# internet: davis@amy.tch.harvard.edu
#   bitnet: davis@ohstpy
#   office: 617-735-6746
#
Newsgroups: comp.lang.fortran
From: mstemper@ems.cdc.com (Michael Stemper)
Newsgroups: comp.lang.fortran
Subject: Re: Help. Need Help in writing this program.
Date: 25 Aug 92 17:59:22 GMT
Reply-To: mstemper@ems.cdc.com
Organization: Empros Systems International, a division of Ceridian

In article <1992Aug24.183954.24423@uceng.UC.EDU>, pviswana@uceng.UC.EDU (Prashanth V.) writes:
|> 
|> The input is the number of Branch instructions the fortran program
|> must contain.
|> 
|> Ouput a fortran program that will contain the specified number of 
|> branch instructions. Is this possible in Fortran?
|> 
Well, it depends on what you mean by branch instructions. If you mean
that your program is to generate another program that has a specified
number of GO TO statements, would the following be an acceptable output
of your program, given an input of 4?

      PROGRAM ANSWER
*
      GO TO     1
    1 CONTINUE
*
      GO TO     2
    2 CONTINUE
*
      GO TO     3
    3 CONTINUE
*
      GO TO     4
    4 CONTINUE
*
      STOP
      END

This was generated with a program that took about two minutes to write
and test. If this is not what your professor is looking for, let us
know the remainder of the homework problem's stated constraints.

If you need hints on how to write something like this, 
'DO loop', 'READ', 'WRITE', 'FORMAT' are good hints.

If you want the program that generated the above program, email me any
time after September 6.

In answer to your question about is this possible in FORTRAN, there is
a general concept called a Turing Machine. You will learn about this
in later classes. A simple explanation is:

" A Turing Machine (TM) is a mathematical representation of the most
  powerful computer it will ever be possible to build. With the
  model of a TM, you can PROVE whether certain things can or cannot
  (even theoretically) be done. A computer language may be said to
  be TM equivalent if it can do everything that a TM can do."

All languages that are TM equivalent can solve the same set of
problems. FORTRAN, C, PASCAL, LISP (to name only a few) are all
TM equivalent. Therefore, what can be done in one of them can be
done in another - no more, no less.

-- 
#include <Standard_Disclaimer.h>
Michael F. Stemper
Power Systems Consultant
mstemper@ems.cdc.com
From: mbk@lyapunov.ucsd.edu (Matt Kennel)
Newsgroups: comp.lang.fortran
Subject: Re: Small Language Wanted
Date: 26 Aug 92 21:19:19 GMT
Organization: Institute For Nonlinear Science, UCSD
NNTP-Posting-Host: lyapunov.ucsd.edu
X-Newsreader: Tin 1.1 PL3

UweKloss@lionbbs.bs.open.de ( Uwe Kloss) writes:
: > In addition, C has nothing equivalent to Fortrans **
: > operator nor does it have complex types.
: The differeces between code the compiler generates and
: the one that is linked as a library or inserted by the
: preprocessor.

So? Again somebody telling us that we don't really want what
we say we want.

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

: 
: 
: > Yes Fortran is still superior to C for what it is intended to do:
: > Numerical Work.
: This is mainly because, as you said, there's much 'canned solutions'.

Perhaps, again, there's a reason, besides compatibility, why canned
solutions are STILL being written de novo in Fortran?


--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".
From: burley@geech.gnu.ai.mit.edu (Craig Burley)
Newsgroups: comp.lang.fortran
Subject: Re: Summary:LynxOS 680x0 Fortran Compilers
Date: 28 Aug 92 15:43:13 GMT
Article-I.D.: geech.BURLEY.92Aug28114313
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
In-reply-to: system@convax.iar.nrc.ca's message of 27 Aug 92 14:15:18 GMT

In article <0095FB7A.0ECEBF20@convax.iar.nrc.ca> system@convax.iar.nrc.ca (Jim.Jordan) writes:

   3) FSF is developing a Fortran compiler for their GNU software suite. This 
      will ready for beta test shortly.
				   : Craig Burley: burley@gnu.ai.mit.edu
				   : GNU FORTRAN mailing list:
				     info-gnu-fortran-request@prep.ai.mit.edu

Make that "ready for _alpha_ test shortly".  Beta test comes after we shake
out the really obvious blatant bugs, and is a public release; alpha test
is a private release.  Beta test might be several months away, who can tell?
--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)
Newsgroups: comp.lang.fortran
From: bhso@fou.tr.statoil.no (Bjorn Halvor Solberg)
Subject: Re: Small Language Wanted
Reply-To: bhso@fou.tr.statoil.no
Organization: Statoil R&D, Trondheim
Date: Tue, 1 Sep 1992 11:36:10 GMT

In article <DAVIS.92Aug27211418@pacific.mps.ohio-state.edu>,
davis@pacific.mps.ohio-state.edu ("John E. Davis") writes:
> In article <9224107.5975@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU
(Fergus James HENDERSON) writes:
>    Any function that is part of the standard library is a "built-in"
function.

Well, I would rather say that any function that is properly prototyped is a
"built-in" function.

> Hmm... don't bet on it.  Let's see:
[... program deleted ...]

> [8:52pm] /net/pacific/4/davis>cc t.c -lm
> [pacific]
> [8:52pm] /net/pacific/4/davis>./a.out
> 1.000000 = pow(2.000000, 4)
> 
> 
> This was compiled on a sun sparc station.
> 
> Also note that all the comments and documentation in the world couldn't have
> saved this program.

The above simply proves you don't have an ANSI C compiler, or at least not ANSI
C header files. I compiled the same program on a Solbourne which is SPARC
compatible, and got this result:

16.000000 = pow(2.000000, 4)

The only thing I did was to exchange "#include <math.h>" with "double
pow(double, double);", because our header-files aren't ANSI C yet either. Need
an upgrade. :-)  Conclusion:  The compiler needs to know the types of the
arguments the function takes (naturally), and once it knows that it is
perfectly
able to do type conversion itself.

>      _____________
> #___/John E. Davis\_________________________________________________________
> #
> # internet: davis@amy.tch.harvard.edu
> #   bitnet: davis@ohstpy
> #   office: 617-735-6746
> #

BJorn.
From: rouff@kong.gsfc.nasa.gov (Chris Rouff - 522.1)
Newsgroups: comp.lang.fortran
Subject: VAX to Sun Fortran port problems
Summary: Need SMG$ equivalent routines
Keywords: Vax Fortran, SMG$ routines
Date: 27 Aug 92 14:49:32 GMT
Followup-To: comp.lang.fortran
Organization: Goddard Space Flight Center

I'm porting a Fortran program from VAX VMS to Sun Unix.  I've run across
some VAX specific libraries for doing ascii terminal based I/O called
Screen Management Routines (SMG$).  Does anyone know if there is an
equivalent set of routines in the Sun Unix environment?

Thanks in advance.

Chris Rouff
rouff@kong.gsfc.nasa.gov
Newsgroups: comp.lang.fortran
From: rlove@den.mmc.com (Robert B. Love 7-1842)
Subject: F77/Unix Buffers
Keywords: buffers, f77, io, files
Organization: Martin Marietta Astronautics, Denver
Date: Wed, 26 Aug 1992 04:52:20 GMT

All help appreciated.




-- 

/s/  R.B. Love
MMAG, Launch Vehicle Software
rlove@.den.mmc.com
From: pld@hpfcso.FC.HP.COM (Paul Dineen)
Date: Sun, 30 Aug 1992 22:48:18 GMT
Subject: Re: F77/Unix Buffers
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.lang.fortran

>10:52 pm  Aug 25, 1992        comp.lang.fortran                Note 162 of 162
>                              F77/Unix Buffers                 No responses
>rlove@den.mmc.com Robert B. Love 7-1842 at Martin Marietta Astronautics, Denver
>
> All help appreciated.
> 
> 
> 
> 
> -- 
> 
> /s/  R.B. Love
> MMAG, Launch Vehicle Software
> rlove@.den.mmc.com

  All questions welcomed.
Newsgroups: comp.lang.fortran
From: jac@moonshine.llnl.gov (James A. Crotinger)
Newsgroups: comp.lang.fortran
Subject: Re: Small Language Wanted
Date: 1 Sep 92 21:20:21 GMT
Organization: Magnetic Fusion Energy - LLNL

If you use Sun's ANSI C compiler, this works fine:

    gandalf:jac(tmp)> acc -o tc tc.c
    gandalf:jac(tmp)> tc
    16.000000 = pow(2.000000, 4)

It also works if you compile with a C++ compiler. However, I don't
believe either of these compilers did the optimization in question,
even after replacing 'i' with '4'. Doing 'nm' on the executable showed
various entries having to do with logs and exponentials. I don't think
these would have been there if the optimization had been done, but I'm
not certain. They also appear in a similar executable based on the
same program rewritten in Fortran.

  (One interesting note is that the Fortran executable was 188K while
the C++ executable was only 32K. Fortran brings in a lot of unnecessary
garbage for such a simple program. Granted this has nothing to do with
real programs. It is just an parenthetical note 8-).)

  Jim
--
-------------------------------------------------/\--------------------------
James A. Crotinger     Lawrence Livermore N'Lab // \ The above views are mine
jac@moonshine.llnl.gov P.O. Box 808;  L-630 \\ //---\  and are not neces-
(510) 422-0259         Livermore CA  94550   \\/Amiga\  sarily those of LLNL.
From: svanhout@cmsa.gmr.com (Sid VanHouten CT90)
Newsgroups: comp.lang.fortran
Subject: All those duplicate posts...
Date: 26 Aug 92 12:56:21 GMT
Reply-To: svanhout@cmsa.gmr.com (Sid VanHouten CT90)
Organization: General Motors Research Labs

--
Sorry about all the duplicate posts about date, time etc.
mxrn is a behaving badly this morning.

Sid VanHouten                svanhout@cmsa.gmr.com (internet)
General Motors Research Labs    (313)986-1958 (phone)
Warren, MI 48090-9055           (313)986-2995 (fax)
Newsgroups: comp.lang.fortran
From: pawlak@vxdesy.desy.de
Subject: Re: Small Language Wanted
Organization: (DESY, Hamburg, Germany)
Date: Fri, 28 Aug 1992 10:26:30 GMT

In article <9224102.1936@mulga.cs.mu.OZ.AU>, fjh@cs.mu.OZ.AU (Fergus Henderson) writes:
> mjs@hubcap.clemson.edu (M. J. Saltzman) writes:
> 
>>In article <9224014.17999@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>>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.
>>                       ^^^^
>>Complex types can be implemented as a class...
> 
> The complex type is a standard part of C++.
> Saying that C++ does not have a complex type is like
> saying that C does not have any I/O.
> In my opinion, the fact that it can be implemented using
> the language rather than being a built-in special feature of
> the language is an ADVANTAGE.

Pardon me, but does C have any I/O? It seems to me that all it has are
functions with side-effects... Having things that 'can be implemented'
instead built-in features leads to: 1) having them implemented by various
people in incompatible ways, 2) making the programs larger, and thus harder
to read, as any program using such thing has to declare it first.

OK, don't take the above very seriously, I just wanted to show you the other
side of the coin...
					Michal
.sig
#include .sig
<ESC>append FROM .sig
ADD FINALLY THIS [....] .sig!!!
OK, OK, forget it...
From: morgan@sitka.fnal.gov (Morgan Burke)
Subject: Re: Size of executables
Organization: Fermi National Accelerator Laboratory, Batavia IL
Date: Fri, 4 Sep 1992 00:20:16 GMT

>     VAX/VMS  HELLO.EXE: 6 blocks ~3 kbytes
>     Sun f77  a.out: ~49 kbytes
>     Sun cc   a.out: ~16 kbytes
>(1) Why?   (Just curious)

Two reasons that I can think of:
   -- VAXes are CISC machines and require fewer instructions to
      accomplish the same task as a RISC machine like a SparcStation
   -- VMS makes use of shared libraries, so that portions
      of your code may not actually be contained in your .EXE file

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

I don't program on Suns, but SGI does have an option to use shared 
libraries.

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

You may suffer a paging penalty, if the control flow of your code 
jumps all over the place (ie. in and out of virtual memory).  There
will also be a small start-up penalty as the image is read, of course.

-- Morgan Burke (morgan@reg.triumf.ca)
From: DEANRE@bscf.uga.edu (ROBIN DEAN)
Newsgroups: comp.lang.fortran
Subject: Analysis of covariance program
Date: 26 Aug 92 12:42:22 GMT
Organization: University of Georgia, USA
X-News-Reader: VMS NEWS 1.20

I am interested in finding a program (and/or writing my own) that
will do analysis of covariance in the normal format of an ANOVA
table.  Does anyone know of a good reference and/or program that
would be useful for this sort of thing?  Any and all help would
be very much appreciated.
                            Thanks,
                            Rob
                            deanre@bscf.uga.edu
Newsgroups: comp.lang.fortran
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Any free descriptions of Fortran 90 features available ?
Organization: Los Alamos National Laboratory
Date: Wed, 2 Sep 1992 17:24:50 GMT

In article <1992Sep2.112919.19291@eagle.lerc.nasa.gov>, sshws@convx1.lerc.nasa.gov (Herb Schilling) writes:
|> 
|> Hello,
|> 
|>  I understand that the Fortran 90 standard is not free. I was wondering 
|> if there is a brief description of Fortran 90's features that I could get for 
|> free. I would like to pass it out to students in an in-house Fortran class
|> I teach. I just want to let them know what's coming. Thanks in advance. 
|> I will summarize any responses I get.

What exactly *is* the copyright requirement on the standard?  My copy of
ISO/IEC 1539:1991(E) contains no copyright declaration at all.  Further,
since Mr. Schilling is using the information only for instructional
purposes, I thought it was permitted for him to make copies (at least
of excerpts) with impunity.  Is this not the case?

Anyway, it seems to me that *any* restriction of the distribution of
the standard is contrary to the very purpose of the standard.  It's
like charging people to read advertising.

-- 
J. Giles
From: svanhout@cmsa.gmr.com (Sid VanHouten CT90)
Newsgroups: comp.lang.fortran
Subject: getting date, time, and pwd
Date: 26 Aug 92 12:43:47 GMT
Reply-To: svanhout@cmsa.gmr.com (Sid VanHouten CT90)
Organization: General Motors Research Labs

--
I'm having a little trouble figuring out how to get the date, time and 
working directory from a FORTRAN program running on an RS/6000.  Anyone know
of a way to get this info?
Thanks...

Sid VanHouten                svanhout@cmsa.gmr.com (internet)
General Motors Research Labs    (313)986-1958 (phone)
Warren, MI 48090-9055           (313)986-2995 (fax)
From: burley@geech.gnu.ai.mit.edu (Craig Burley)
Newsgroups: comp.lang.fortran
Subject: Re: F77, array passing question, dimensions.
Date: 26 Aug 92 16:38:30 GMT
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
In-reply-to: russell@sun.soe.clarkson.edu's message of 26 Aug 92 03:20:18 GMT

In article <1992Aug26.032018.20430@news.clarkson.edu> russell@sun.soe.clarkson.edu (David Russell) writes:

      Given an array dimensioned to lets say 10 in a calling routine,
   and given the fact that only the first three values are needed in
   the called routine, is there any advantage or disadvantage to
   dimensioning the array to only 3 in the called routine.

Generally, no.  Most implementations will just pass the address of the
first element of the array, which is contiguous in memory.  A few
implementations might involve passing the data values themselves; F77
permits this; but they are quite rare.  If you find yourself running
on such an implementation, you could EQUIVALENCE the 10-element array
to a 3-element one and pass the latter.
--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)
Newsgroups: comp.lang.fortran
From: ucaa2385@ruscvx.rus.uni-stuttgart.de (Peter Hermann)
Subject: Re: Fortran 90 Advocacy
Organization: User ruscvx Comp.Center (RUS) University of Stuttgart, Germany
Date: Thu, 27 Aug 1992 08:51:14 GMT

In article <BURLEY.92Aug26123556@geech.gnu.ai.mit.edu> burley@geech.gnu.ai.mit.edu (Craig Burley) writes:
>changes to it to the X3 committee, is still pretty pitiful.  Also, F90 places
>more demands on the GNU back end than does F77.

Fortran comes closer and closer to Ada but will never reach it.
It is like a goggomobil with more and more patches
wanting to become a mercedes.

regards,
Peter Hermann
Newsgroups: comp.lang.fortran
From: btbg1194@uxa.cso.uiuc.edu (Bradley T Banko)
Subject: Robustness of MS Fortran 5.x & Vax extensions?
Organization: University of Illinois at Urbana
Date: Fri, 4 Sep 1992 03:59:27 GMT

I am starting on a project to convert some several thousand line 
RSX11/VMS Vax Fortran programs to run on a PC, and I am planning to
use MS Fortran 5.1.  I would  appreciate comments about MSF 5.x's
robustness in dealing with Vax code... including special types like
"BYTE" and out of order DATA/COMMON statements.

Any comments are welcome.  Thanks.

Brad Banko
b-banko@uiuc.edu


-- 
Brad Banko;  Dept of Physics;  U of Illinois;  b-banko@uiuc.edu, KB8CNE
=========================================================================
	Tatiana Gutsu for President!