HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.lang.fortran
Subject: Re: Question about language of Fortran book
From: <REGHC@CUNYVM.BITNET>
Date: Wednesday, 14 Oct 1992 14:55:02 EDT
Organization: City University of New York/ University Computer Center

I now know that this book is in Turkish.  If anyone is interested in this
book send me email.
From: mac@cis.ksu.edu (Myron A. Calhoun)
Newsgroups: comp.lang.fortran
Subject: Re: The Cray YMP fails paranoia arthmetic test?!
Date: 11 Oct 92 15:45:32 GMT
Organization: Kansas State University
Distribution: usa
NNTP-Posting-Host: depot.cis.ksu.edu

ungar@leland.Stanford.EDU (Jeffrey Ungar) writes:
>While testing a Monte Carlo program recently, I uncovered what appeared
>to be huge inconsistencies between the results calculated in a short....
   .....
>The C version uncovers similar problems. What gives?
                                          ^^^^^^^^^^^
I believe the correct term is "chaos".
--Myron.
-- 
# We preserve our freedoms using four boxes:  soap, ballot, jury, and cartridge.
# Myron A. Calhoun, PhD EE; Assoc. Professor  (913) 539-4448 home
# INTERNET: mac@cis.ksu.edu (129.130.10.5)          532-6350 work, 532-7353 fax
#     UUCP: ...rutgers!depot!mac     Packet-BBS: W0PBV @ K0VAY.#NEKS.KS.USA.NAOM
From: mstemper@ems.cdc.com (Michael Stemper)
Newsgroups: comp.lang.fortran
Subject: Re: Quickie
Date: 12 Oct 92 14:10:02 GMT
Reply-To: mstemper@ems.cdc.com
Organization: Empros Systems International, a division of Ceridian

In article <1992Oct11.011856.4116@ecsvax.uncecs.edu>, urjlew@ecsvax.uncecs.edu (Rostyk Lewyckyj) writes:

|>    write(*,*)msg(n)(:lnblnk(msg(n)))
|>                    ^^^^^^^^^^^^^^^^^
|> What dialect of Fortran is the above construction? 

The construction is standard Fortran 77. If 'string' is of type
character and i,j are of type integer, string(i:j) is a substring
of 'string', starting with character i and going through character j.

However, the function 'lnblnk' is not an intrinsic function in ANSI
standard Fortran. It is a wonderful extension, though. I have written
my own function to do the same thing, because it is a fairly common
need.

-- 
#include <Standard_Disclaimer.h>
Michael F. Stemper
Power Systems Consultant
mstemper@ems.cdc.com
Newsgroups: comp.lang.fortran
From: steve@agropyron.forests (Steve)
Subject: EXTENDED keyword = double?
Date: Fri, 09 Oct 1992 21:43:34 GMT
Reply-To: steve@agropyron.forests
Organization: Sun Microsystems, Inc.
Keywords: syntax, double, extended

I'm working on a model that was written in fortran on a MAC.

My question is, what does the keyword EXTENDED mean?

convext:

       implicit           none

       integer            fred
       
       extended           jim, cathy

       jim = exp(cathy)

I'm assuming it is the equivalent of double.
Anyone know for sure?

thanks
steve
From: desj@ccr-p.ida.org (David desJardins)
Newsgroups: comp.lang.fortran
Subject: Re: The Cray YMP fails paranoia arthmetic test?!
Date: 10 Oct 92 03:39:05 GMT
Organization: IDA Center for Communications Research, Princeton

Jim Carr <jac@ds8.scri.fsu.edu> writes:
>Other than that, almost all of the problems with Cray arithmetic 

                                         million
>can be tracked back to Seymour saving a few $$$ by not having a 
>divide unit in his CPU.                    ^

                                        David desJardins
Newsgroups: comp.lang.fortran
From: ungar@leland.Stanford.EDU (Jeffrey Ungar)
Subject: Re: The Cray YMP fails paranoia arthmetic test?!
Organization: DSG, Stanford University, CA 94305, USA
Distribution: usa
Date: Sat, 10 Oct 92 05:05:46 GMT

In article <1992Oct10.003625.28884@ecsvax.uncecs.edu> urjlew@ecsvax.uncecs.edu (Rostyk Lewyckyj) writes:
>In article <11067@sun13.scri.fsu.edu>, jac@ds8.scri.fsu.edu (Jim Carr) writes:
>> The Cray YMP has several well-documented features that affect its 
>> arithmetic accuracy.  The most serious is the fact that it does not 
>> --
>But real CRAY users don't care. Because real CRAY users want their
>results faster and accuracy is less important.

And, apparently, they don't eat quiche.

>Just recalculate
      ^^^^^^^^^^^
>the results in a different way and compare the answers to see if
>they are close enough. After all floating point calculation is
>never exact. 

I guess CRAY should divide all those MFLOP ratings by two, since you
have to run each program twice! :-) Come to think of it, that was
just about standard practice on those CDC 7(?)600's, wasn't it?

Real CRAY users *do* care about accuracy as well as speed. In the
case of this Monte Carlo program, all results were statistically equivalent,
but the individual samples were different. The solution was to
make sure the random number generator was called for each step, whether
a new number was needed or not. This ensured the sequences used to
accept or reject a step were the same on all platforms.

Jeff Ungar
From: spxsjm@thor.cf.ac.uk (Mr S J Morris 92)
Newsgroups: comp.lang.fortran
Subject: Problems printing numbers in SUN Fortran
Summary: I get garbage!
Date: 8 Oct 92 08:21:03 GMT
Organization: University of Wales College at Cardiff
X-Mailer: Cardiff Computing Maths PP Mail Open News Gateway

I've found a particularly wierd problem when trying to print out numbers
in SUN Fortran. I have a program which looks schematically something
like:

      program intest
      implicit double precision (a-h,o-z)
      double complex result
      call int3d(............,result,...)
      print *,'result=',result
      stop  
      end

      subroutine int3d(............,result,...)
      implicit double precision (a-h,o-z)
      double complex result
      .
      .
      result=[lots of gubbins here]
      print *,'result=',result
      return
      end

(I include the type declarations because these are what I'm interested
in using - I still get the problem if I use simpler ones.)

The problem is this: when I run the program, the value of 'result' gets
printed perfectly from within the subroutine; however, when the main
program tries to print it out the result is a lot of garbage. Most (not
all) of the garbage consists of a nice formatted table of numbers, as
though the compiler thinks that 'result' is now an array.

I've tried all the usual experiments with this: moving 'result' around
within the parameter list, making 'int3d' a function instead of a
subroutine, formatting the output statements, writing to disk,
dimensioning 'result' to be an explicit one-element array, changing its
name to alternatives beginning with various letters of the alphabet,
doing array-bound checking on the whole program, the works, indeed, but
still it's there.

Incidentally, although written for the SUN, the program runs perfectly
on a VAX - no problems at all! As for the problem on the SUN, I'm
baffled now, and so is our Systems Manager. Is this a bug on SUN
Fortran, or am I doing something obvious and stupid? Help, please,
anybody in the know...!

Thanks,
Steve Morris.
Newsgroups: comp.lang.fortran
From: maine@altair.dfrf.nasa.gov (Richard Maine)
Subject: Re: Allocatable arrays in Type definition (Fortran 90 question)
Organization: NASA Dryden, Edwards, Cal.
Date: Wed, 14 Oct 1992 04:24:49 GMT

On Wed, 14 Oct 1992 00:42:52 GMT, phychenk@nuscc.nus.sg (Chen Kan (Dr)) said:

Chen>        I am using NAG fortran 90 compiler on Dec workstations. I have a
Chen> problem compiling Matrix type defined in "Programmer's Guide to Fortran
Chen> 90" by Walter S. Brainero et el. Here is the type defintion

Chen>            Type Matrix
Chen>                integer::M,N  
Chen>                real, dimension(:,:),allocatable::A
Chen>            End Type Matrix

Chen> The compiler complains that it is an ill-defined type. If I use ordinary
Chen> array in the definition of A, then everything works fine, also if I use
Chen> allocatable array declaration outside of type definition, no problem as
Chen> well. Is there any incompatibility between user-defined type and
Chen> allocatable array? (Pointers in User-defined type works without a
Chen> problem).

The standard does not allow allocatable arrays in user-defined types.
As Chen noted, you can use pointers, which achieve essentially the same
thing.   Allocatable arrays and pointers have a lot of overlap in
functionality.  I've taken to using pointers most places because
there are a few places where allocatables can't be used (user-defined
types is one; dummy arguments is another).

I'm too tired at the moment to drag out the exact text in the standard
that states this.  As I recall, it was not stated explicitly that
allocatables weren't allowed.  Instead, there is a list of what
syntax is allowed in derived type definitions and the "allocatable"
attribute is conspicuous by its omission (which is easy to overlook).

Walt's "Programmer's Guide.." book has several oversights like this.
It is in need of a second edition to fix them.  This is not meant as
criticism of Walt, whom I both like and respect (Hi, Walt).  Keep in
mind that the book was written before any compilers were written to
check any of the code on.  It is very easy to miss things like this in
that kind of situation.  For instance, I wrote some code using
allocatables in derived types myself.  I didn't figure out that this
wasn't legal until my code didn't compile and I went back to carefully
study the relevant part of the standard before submitting a bug
report.  (After studying the standard, I refrained from submitting the
bug report).

--
--
Richard Maine
maine@altair.dfrf.nasa.gov

Newsgroups: comp.lang.fortran
From: cflatter@nrao.edu (Chris Flatters)
Subject: Re: IEEE floating-point arithmetic exceptions
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Tue, 13 Oct 92 15:53:34 GMT

In article 18454@csus.edu, ljeung@sfsuvax1.sfsu.edu (Lawrence Jeung) writes:
>I've been running a hydrodymanic code on a Sun SPARCstation I, and each
>time, I get the following message each time:
>
>	Note: the following IEEE floating-point arithmetic exceptions
>	occurred and were never cleared; see ieee_flags(3M):
>	Inexact; Underflow;
>	Sun's implementation of IEEE arithmetic is discussed in the
>	Numerical Computation Guide.
>
>I've read the man pages on ieee_flags and the Numerical Computation
>Guide and learned enough to use ieee_flags to clear the message and even
>ieee_handler to trap signals (like SIGFPE?).  I also ran the code from
>the dbx debugger and used the command "catch FPE".  But for some reason,
>these techniques work some of the times.  And to add to the  frustration, 
>they are sometimes mutually exclusive.  What is happening?  Perhaps, I do 
>not have a good enough understanding of IEEE arithmetic.  I also have a 
>suspicion that the workstation I'm using doesn't use gradual underflow.

SPARC chipsets fully support IEEE-754.  This means that denormalized numbers
are support (ie. underflow is gradual).  However, the underflow flag indicates
that the result of an operation is smaller than the smallest normalized number.
By default the underflow flag will only be raised if there is also a loss of
precision (which is fairly often when returning a denormalized result) and so
tends to go with the inexact flag.

>
>I've also been reading about the interesting "paranoia over Cray
>arithmetic".  I thought it had some connection to my problem.  One of my
>colleagues (who probably knows only just a little bit more about Suns
>and Crays than I) says that most programmers on Suns ignore messages like 
>the one I got.  But in light of the discussion about Cray arithmetic in 
>this newsgroup, I'm not willing to do that.  However, because I'm somewhat 
>new to working on Suns and Crays, maybe I'm worrying too much, and I 
>should follow my co-worker's advice.

Whether you wish to ignore the message or not depends on your application.
If your application is not sensitive to round-off errors you can safely ignore
it.  If your application is unstable with respect to round-off errors then you
need to pay attention to it.

	Chris Flatters
	cflatter@nrao.edu
From: martelli@cadlab.sublink.org (Alex Martelli)
Newsgroups: comp.lang.fortran
Subject: Re: How do I make MS Fortran 5.1 use lots of memory?
Date: 6 Oct 92 11:20:40 GMT
Organization: CAD.LAB S.p.A., Bologna, Italia

bauwens@acs.ucalgary.ca (Luc Bauwens) writes:
	...
:Or get a Watcom 386 compiler.  It comes with a DOS extender that will

VERY good advice.  Sure beats struggling with Mickeysoft "tools"...

:access most of his memory under DOS, if he doesn't want to
:use Windows or OS/2.  But I find it much nicer to compile
:in the OS/2 environment.  The compiler will probably have
:to do lots of swapping to disk if it got to live in a 640k
:environment.

You're wrong here: the WATCOM Fortran/386 compiler comes with a
protected-mode version, using its own extender, which can exploit
extended memory for the compilation process itself - no swapping.
-- 
Email: martelli@cadlab.sublink.org                   Phone: ++39 (51) 6130360
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: ++39 (51) 6130294
From: martin@hal.com (Rick Martin)
Newsgroups: comp.lang.fortran
Subject: fortran code
Date: 8 Oct 92 14:09:15 GMT
Reply-To: martin@hal.com (Rick Martin)
Organization: HaL Computer Systems, Inc.; Campbell, CA
NNTP-Posting-Host: deli.hal.com

I am turning to the net to help me out. I am the Project Lead for QA of
Compilers and Language Tools here at HAL Computer Systems and I have a
FORTRAN compiler that I need to qualify. 

Admittedly, I have not programmed in FORTRAN since my college days and I
need code to run through the compiler. Currently we have obtained a test
suite called FCVS (FORTRAN Compiler Verification Suite?). Mainly, does
anyone know of public domain or commercially available FORTRAN test
suites? 

Additionally, I am looking for some real applications, such as
simulations, modeling or numerical analysis programs that are
traditionally implemented in FORTRAN. 

Please reply by email; I will summarize for others who are interested.
Thanks in advance!
-- 
 Rick Martin                   |     "Time was created to prevent 
 martin@hal.com                |      everything from happening at
 HaL Computer Systems          |      once!"
 (408) 379-7000 ext. 1085      |
 1315 Dell Avenue              |		unknown
 Campbell, CA 95008            |
From: REGHC@CUNYVM.BITNET
Newsgroups: comp.lang.fortran
Subject: Question about language of Fortran book
Date: 8 Oct 92 18:23:05 GMT
Organization: City University of New York/ University Computer Center

This book that I have is in a language unrecogizable to me.  Is there someone
that could help me.
The book is PROGRAMLAMA VE FORTRAN 77
                Taner Derbentli
                Kipas Dagitimcilik
                Istanbul 1985


     Bir programlama dilini ogrenmek ile programlamay ogrenmek birbirini

tamamlayici olmakla birlikte ayni anlama gelmez.  Birincisi bir dizi deyim ve

kurali ogrenmek demektir.  Bu, kisa sureli bir caba ile saglanabilir.


Above is a brief desciption of the book.
From: lionel@quark.enet.dec.com (Steve Lionel)
Newsgroups: comp.lang.fortran
Subject: Re: vax I/O
Date: 10 Oct 92 15:25:14 GMT
Organization: Digital Equipment Corporation


In article <9OCT199214341251@elroy.uh.edu>, math1rb@elroy.uh.edu
(David Meyers)  writes...
>I've got what seems to be simple problem, but I can't get it to work. What I
>need to do is have the user of the program type in their data file to run on my
>program. Now I don't know how many characters long the file name is going to be.
>I've tried the following 2 ways:
> 
>	character name*80
>	read *,name
>	open(unit=1,file=name,status='old')
>and also
>	character name*80
>	read (5,102) name
>102 	format(a80)
>	open(unit=1,file=name,status='old')
> 
>I guess this should be a pretty easy problem for someone out there to solve.
>This compiles/links without errors, but the runtime error says something about
>no access or something? Any ideas?
> 

There is nothing wrong with your code, though for the first case, the
user must enclose the file name in apostrophes.  The string will be padded
with blanks to the length of your variable, and the trailing blanks will
be ignored.  (Though 255 would be a better length for the variable, as
that is the maximum filename length).  I'm not sure exactly what error
you're getting, but perhaps you don't have read/write access to the file
in question.  If you only want to read the file, try adding the keyword
READONLY to the OPEN statement.

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
From: am299bv@sdcc15.ucsd.edu (Ravinder Bhumbla)
Newsgroups: comp.lang.fortran
Subject: Re: Frequently Asked Questions [Got it!]
Date: 14 Oct 92 13:11:12
Organization: UC San Diego, AMES Department
Distribution: usa
Reply-To: rbhumbla@ames.ucsd.edu (Ravinder Bhumbla)
NNTP-Posting-Host: sdcc15.ucsd.edu
In-reply-to: am299bv@sdcc15.ucsd.edu's message of 14 Oct 92 02:21:55

I wrote:

#    Could someone send me a copy of the Frequently Asked Questions

Thanks,
	I have already received two copies.  So please don't send me
any more.

Ravi
Newsgroups: comp.lang.fortran
From: schultz@unixg.ubc.ca (Stewart Schultz)
Subject: ABSOFT Fortran ---> f77?
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Fri, 9 Oct 1992 01:02:49 GMT

I have a fairly large source in Macintosh ABSOFT Fortran,
and I want to compile it with f77 on our Sun. I get a couple
errors, and the compilation fails.  I don't know Fortran at
all, but I assume there are a few small differences, and the
translation shouldn't be too hard.

Can anybody help me out on this?

Thanks,
Stewart Schultz   schultz@unixg.ubc.ca
From: phd85@keele (D.H. Holden)
Newsgroups: comp.lang.fortran
Subject: Writing COMPLEX numbers: need help.
Date: 16 Oct 92 12:39:37 GMT
Organization: Keele University, England


	Can anyone exlpain the following, when the following code is
	compiled on a SUN4 running sunOS4.1 and then run it crashes with
	a segmentation fault, I cant see why since when run in dbx I can
	print out all the values of the array elements and they are fine.
	The error definitely occurs at the write (3) com  statement.
	When this was compiled on a sequent mainframe the error did not
	occur. Also if I replace the write (3) com with a do loop that
	write's out each element individually it runs fine. 

	INTEGER i,j
	COMPLEX  COM(36,72)
	CHARACTER FILE3*20

	DO 10 i=1,36
	   DO 5 j=1,72
		COM(i,j)=(1.5,2.5)
 5	   CONTINUE
 10	CONTINUE

	FILE3 = "test"
      OPEN   (UNIT  =3,
     1        FILE  =FILE3,
     2        STATUS='UNKNOWN',
     3        ACCESS='SEQUENTIAL',
     4        FORM  ='UNFORMATTED')
C.....

      WRITE  (3) COM
	CLOSE(3)
      PRINT * , ' End'
	END
C.....

          Any help apreciated gratefully.

		    Dave
--
Dave.
phd85@uk.ac.keele.seq1
Newsgroups: comp.lang.fortran
From: john@aquarius.unm.edu (John Prentice)
Subject: Re: The Cray YMP fails paranoia arthmetic test?!
Date: Mon, 12 Oct 92 16:11:09 GMT
Organization: Dept. of Physics & Astro, University of New Mexico, Albuquerque
Distribution: usa

In article <1992Oct10.003625.28884@ecsvax.uncecs.edu> urjlew@ecsvax.uncecs.edu (Rostyk Lewyckyj) writes:
>In article <11067@sun13.scri.fsu.edu>, jac@ds8.scri.fsu.edu (Jim Carr) writes:
>> [regarding poor floating point results on the Cray]...
>But real CRAY users don't care. Because real CRAY users want their
>results faster and accuracy is less important. Just recalculate
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^
>the results in a different way and compare the answers to see if
>they are close enough. After all floating point calculation is
>never exact. 

I trust at least some of this is meant tongue in cheek :-) .  Seriously
though, the imprecise arithmetic on the Cray has worried people since the
early days of the Cray 1.  We are doing some long term planetary integrations
(several million years, requiring billions of iterations).  The accumulated
errors because of imprecise arithmetic are a source of major concern in
such calculations, so much so that many people in the field won't even 
touch a Cray (instead they put up with slower workstations which may take
months to do the calculations, but they do it right).  

The CFT77 compiler has a compiler option (the r option) to force rounding.
I assume you pay a performance penalty when you use it however.  Anyone
know for sure?

John
-- 
Dr. John K. Prentice                      
Partner, Quetzal Computational Associates    
3200 Carlisle N.E., Albuquerque, NM   87110-1664
Phone: 505-889-4543  E-mail: john@aquarius.unm.edu -or- jkprent@cs.sandia.gov
Newsgroups: comp.lang.fortran
From: syo@Comtech.com (Sinan Y. Othman)
Subject: FTP site for a Fortran Compiler
Organization: Comtech Labs Inc, Palo Alto
Distribution: usa
Date: Tue, 13 Oct 1992 16:12:17 GMT


I have not seen the FAQ file for this newsgroup so pardon the possible
redundancy of this question:

Is there an FTP site from which I can get a Fortran Compiler to run in a unix
environment?

Thanks.

Sinan Othman
syo@comtech.com
Newsgroups: comp.lang.fortran
From: wjb5106@rigel.tamu.edu (Walter Barnett)
Subject: Re: passing arrays as parameters
News-Software: VAX/VMS VNEWS 1.41    
Organization: Texas A&M University
Date: Fri, 16 Oct 1992 16:16:00 GMT

In article <16OCT92.07182890.0071@VM1.MCGILL.CA>, UBCF@MUSICB.MCGILL.CA (UBCF) writes...

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

What I do is put the dimension values on a common block and then pass 
the arrays and their run-time sizes as parameters.  For example,

	program junk
	dimension a(100,100),x(100),b(100)
	common/dim/ndim
	ndim=100
	n=5   ! or whatever
	call subjunk (a,x,b,n)
	.
	.
	.

	subroutine subjunk (a,x,b,n)
	common/dim/ndim
	dimension a(ndim,ndim),x(ndim),b(ndim)
	.
	.
	.


_______________________________________________________________________
Walter Barnett        Aerospace Engineering        Texas A&M University 
Newsgroups: comp.lang.fortran
From: rlink@cedar.hao.ucar.edu (Richard Link)
Subject: home directory in unix
Organization: High Alititude Observatory/NCAR, Boulder CO
Date: Thu, 8 Oct 1992 20:05:40 GMT

I would like to specify file names as ~/rlink/file.name
instead of specifiying the complete path /home/.../rlink/file.name
Evidently, csh does not pass on the ~/ to the fortran program.
How can I do this?

Thanks in advance,

Dr. Richard Link
Senior Physicist
Computational Physics, Inc.
2750 Prosperity Avenue, Suite 600
Fairfax, VA 22031

(703) 204-1301		(voice)
(703) 204-9121		(FAX)
rlink@diablo.cpi.com	(Internet)
Newsgroups: comp.lang.fortran