HDTenEightyP/NetNews huggingface dataset:
From: gerardo@ferris.cray.com (Gerardo Cisneros)
Subject: Re: The Cray YMP fails paranoia arthmetic test?!
Originator: gerardo@ferris
Organization: Cray Research, Inc.
Distribution: usa
Date: 13 Oct 92 10:01:28 CDT


In article <bpmpmr=@lynx.unm.edu>, john@aquarius.unm.edu (John Prentice) writes: 
> 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?

No performance penalty is incurred.  The only operation affected by the
r option is multiplication, because there is a "rounded floating-point
product" instruction which the compiler uses instead of the regular
floating-point product when -r is specified.
-- 
Gerardo Cisneros		|Cray Research de M'exico, S.A. de C.V.
gerardo.cisneros@cray.com	|Camino a Sta. Teresa 480-A #302
(+52+5)622-8584 		|14020 Tlalpan, D.F., MEXICO
 Anything I said sound like an opinion? Then it's no one's but my own.
Newsgroups: comp.lang.fortran
From: brandes@gmd.de (Thomas Brandes)
Subject: Translation of Data Parallel Fortran to Message Passing Programs
Keywords: Data Parallelism, CM Fortran
Organization: GMD, Sankt Augustin, Germany
Date: Thu, 15 Oct 1992 13:53:23 GMT


___________________________________________________________________

         THE  A D A P T O R  DATA PARALLEL PROGRAMMING TOOL
___________________________________________________________________

             -----------------------------------
               Announcing Adaptor Version 0.1

                       October 1992
             -----------------------------------


Adaptor (Automatic DAta Parallelism TranslatOR) is a tool that transforms
data parallel programs written in Fortran with array extensions, parallel
loops, and  layout directives  to parallel programs with explicit message
passing.

Adaptor is a big package that consists of:

 o the interactive source to source transformation tool XAdaptor
 o the distributed array library (DALIB)
 o documentation files in Postscript format,
 o example programs.

The source language of ADAPTOR can be defined shortly in the following way:

 o Fortran 77 with some restrictions,
 o with many array extensions of Fortran 90 (inclusive dynamic arrays
   and intrinsic functions for arrays),
 o with some features of Connection Machine Fortran (timing, random numbers),
 o with layout directives to specify the data distribution.

ADAPTOR is not a compiler but a source to source transformation that
generates Fortran 77 host and node programs with message passing.
The new generated source codes have to be compiled by the compiler of the
parallel machine. The following parallel machines are supported:

  * Alliant FX/2800
  * iPSC/860
  * Net of SUN 4 Workstations (based on PVM)
  * Net of IBM Risc Workstations (based on PVM)
  * Parsytec GCel
  * Meiko Concerto

The software packages, documentations files in PostScript, and a number of
example programs are available via "anonymous ftp" from:

    ftp.gmd.de    (129.26.8.90)
    in subdirectory    gmd/adaptor

Read the Installation Guide (iguide.ps) carefully to install the
package on your machine.

Please send remarks and bug reports to: brandes@gmdzi.gmd.de

--
===================================================================
Thomas Brandes                         e-mail: brandes@gmdzi.gmd.de
GMD, I1.HR, Schloss Birlinghoven, D-5205 St. Augustin, West Germany
===================================================================
From: am299bv@sdcc15.ucsd.edu (Ravinder Bhumbla)
Newsgroups: comp.lang.fortran
Subject: Frequently Asked Questions
Followup-To: poster
Date: 14 Oct 92 02:21:55
Organization: UC San Diego, AMES Department
Distribution: usa
Reply-To: rbhumbla@ames.ucsd.edu (Ravinder Bhumbla)
NNTP-Posting-Host: sdcc15.ucsd.edu

Could someone send me a copy of the Frequently Asked Questions
posting?  I forgot to save it when it was posted recently and now I
can't find it at the FAQ archives at rtfm.mit.edu
(pit-manager.mit.edu).

By the way, could the person maintaining the FAQ cross post it to
news.answers if he isn't doing it already?

Thanks,
Ravi
From: sandee@Think.COM (Daan Sandee)
Newsgroups: comp.lang.fortran
Subject: Re: home directory in unix
Date: 9 Oct 1992 17:37:57 GMT
Organization: TMC
Distribution: world
NNTP-Posting-Host: telecaster.think.com
Keywords: getenv getarg

In article <nn1.718647279@Ra.MsState.Edu>, nn1@Ra.MsState.Edu (N. Narenthiran) writes:
|>   I tried to do this.  For example I made the filename
|>  "/my_home/my_login/dir/filename"  which I checked and found to be the
|> correct Unix full path.  But, I still could not use an INQUIRE on this
|> file.  The system is a the sun Fortran compiler f77 on a Sun machine.
|>  (and an SGI Iris 4.0 (/4.1 ?) with the default compiler.)

Am I missing something ? This is SunOS (4.1 or something)

louis>pwd
/users/sm1/sandee/hydflo/orig
louis>cat t.f
      character*60 fn,string
      logical found
c get home directory
      call getenv('HOME',string)
      print *,'home= ',string
c add /filename after last non blank
      fn=string(1:index(string,' ')-1)//'/newsrc'
      print *,'fn= ',fn
      inquire (file=fn,exist=found)
      print *,'found= ',found
      open(9,file=fn)
      read (9,*),string
      print *,' first line in file :'
      print *,string
      end

louis>f77 t.f
t.f:
 MAIN:
louis>ll ~/newsrc
-r--------  1 sandee      58347 Oct  9 13:23 /users/sm1/sandee/newsrc
louis>a.out
home= /users/sm1/sandee
fn= /users/sm1/sandee/newsrc
found=   T
 first line in file :
rec.birds:

louis>rm ~/newsrc
rm: override protection 400 for /users/sm1/sandee/newsrc? y
louis>a.out
home= /users/sm1/sandee
fn= /users/sm1/sandee/newsrc
found=   F
list read: [-1] end of file
logical unit 9, named '/users/sm1/sandee/newsrc'
lately: reading sequential list external IO
part of last format: ext list io
part of last data: |
Abort
louis>


Daan Sandee                                           sandee@think.com
Thinking Machines Corporation
Cambridge, Mass 02142                                 (617) 234-5044
Newsgroups: comp.lang.fortran
From: walt@netcom.com (Walt Brainerd)
Subject: Fortran Journal
Keywords: fortran
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Thu, 15 Oct 1992 16:45:53 GMT

FYI: Contents of the Sep/Oct _Fortran Journal_ include:

  o  A preliminary review of the $99 Salford Fortran 90
     compiler for the PC.
     -- Chuck Ritz

  o  Building Libraries with Fortran 90--
     How the new features of F90, such as optional
     and keyword arguments will make it easier
     to write, and especially to use, F90 libraries.
     -- Jeremy Du Croz

  o  Highligts of the Septermber High Performance
     Fortran Meeting
     -- Rex Page

  o  A test suite for Fortran 90
     -- Walt Brainerd

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: fxt@helios.ucsc.edu (oxide owner)
Newsgroups: comp.lang.fortran
Subject: re: cray paranoia
Date: 10 Oct 1992 15:39:30 GMT
Organization: UCO/Lick Observatory
Distribution: world
NNTP-Posting-Host: helios.ucsc.edu


> jac@ds8.scri.fsu.edu (Jim Carr):
> The Cray YMP has several well-documented features that affect its 
> arithmetic accuracy.  
> 
> The Cray also lacks guard digits. 
> 
> Other than that, almost all of the problems with Cray arithmetic 
> can be tracked back to Seymour saving a few $$$ by not having a 
> divide unit in his CPU. 


> urjlew@ecsvax.uncecs.edu (Rostyk Lewyckyj) :
> 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. 

oh, very fast and possibly very wrong. "just recalculate in a different way"?
so, not only does one have to two methods for computing something critical, 
one has to run each method (cpu and $ just went up by a factor of two) 
and go through a perhaps laborious comparison of the computations. this is 
outrageous; i dont believe this. are there any "real" cray users who will go 
on record as saying accuracy takes a backseat to speed? if so, please state
what it is you compute, and hopefully its not something practical like 
earthquake proof freeway overpass systems or klystron trigger devices :)
(i can see the headline: 67 die in freeway collapse; designer blames 
lack of guard digits).

fxt
Newsgroups: comp.lang.fortran
From: ejh@khonshu.colorado.edu (Edward J. Hartnett)
Subject: reading VAX unformatted data on a Sun?
Organization: CIRES, University of Colorado
Date: 13 Oct 92 14:38:33


Hi! I have some VAX tapes with unformatted data on them and I need to
get them into my Sun. I heard that VAX data is big-endian, or
little-endian, and the Sun is the opposite. Is that true? Any good
fortran way to solve this problem? I'll summarize if anyone else is
interested.

			Thanks,
				Ed Hartnett
--
Edward Hartnett			ejh@khonshu.colorado.edu
From: wilson@moonshine.llnl.gov (Mike Wilson )
Newsgroups: comp.lang.fortran
Subject: Re: GreenHills (e-mail) address sought.
Date: 8 Oct 92 20:46:08 GMT
Organization: Magnetic Fusion Energy - LLNL

ishikawa@ds5200.personal-media.co.jp (Chiaki Ishikawa) writes:


>I am trying to reach a company that publishes compilers for UNIX
>machines.  The company is called, I think, GreenHills.  One of my
>colleagues tried snail (postal) mails, but somehow they seemed to have
>gone into a black hole, and we didn't hear from them at all.

>Will someone kindly let me know the e-mail address or possibly a
>(new?) postal address we should try?

I don't believe that greenhills does direct marketing.  You want to
talk to their Marketing front end called Oasys.  phone # = 617-862-2002.

-mike
From: fox@rudolf.nscl.msu.edu (Ron Fox)
Newsgroups: comp.lang.fortran
Subject: Re: Adjustable arrays
Date: 9 Oct 92 12:36:49 GMT
Reply-To: fox@rudolf.nscl.msu.edu (Ron Fox)
Organization: National Superconducting Cyclotron Lab.

--
In article <1992Oct8.172214@trc.amoco.com>, zkdc05@trc.amoco.com
(Kelly >
>In article <533@rama.UUCP>, bcs@rama.UUCP (Brian Spollen) writes:
>> In article <1992Oct5.171833.16706@magnus.acs.ohio-state.edu>,
>cpaulse@magnus.acs.ohio-state.edu (Chris D Paulse) writes:
>>   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).
>
>You are correct, but don't blame this on Fortran's infinite
>flexibility.  Many
>procedural languages allow it.  Run time bounds checking is
>expensive.
>This is what compiler options and analysis tools are for.
>
>>   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
>
>The following code also compiles on the Sun:
>
>#include <stdio.h>
>void main() {
>int *idum;
>idum[3] = idum[1] + idum[2];
>}
>
>Sorry...just couldn't resist...
>
>Kelly
>-- 
>Kelly D. Crawford             | Amoco Production Research | These are
>my own
>kcrawford@trc.amoco.com       | 4502 East 41st Street     | opinions,
>not
>phone: (918) 660-4043         | Tulsa, OK  74102          |
>Amoco's...
>          >>> *** This line intentionally left blank *** <<<
>

  Yeah, and in the FORTRAN case at least you could do:

FORTRAN/CHECK=BOUNDS
and the program would crash at run time.  The VMS C compiler doesn't
have an option to do run time bounds checking and in fact can't since
the array reference could in fact be an alias to a pointer to an object
of indeterminate size.
	RF.

Ron Fox                     | FOX@MSUNSCL.BITNET      | Where the name 
NSCL                        | FOX@RUDOLF.NSCL.MSU.EDU | goes on before
Michigan State University   | MSUHEP::RUDOLF::FOX     | the quality
East Lansing, MI 48824-1321 |                         | goes in.
USA
Newsgroups: comp.lang.fortran
From: HUSFELD@usmv01.usm.uni-muenchen.de (Husfeld, Dirk)
Subject: Re: For HP and IBM RISC hosts, how to get cpu times from Fortran?
Summary: Code for getting elapsed CPU time in HPUX Fortran
Organization: University Observatory Munich, FRG 
Date: Tue, 13 Oct 1992 15:53:47 GMT
X-News-Reader: VMS NEWS 1.20

In <BvzBHq.Ap6@udecc.engr.udayton.edu> theld@udecc.engr.udayton.edu writes:

> Hello:
> 
> We have a code (all Fortran) that runs on several platforms.  I want to
> add a routine that returns the total elapsed cpu time for the run (not 
> elapsed wall-clock time).  In the routine I'll put some 
> platform-specific code that gets this value somehow.  I know how to do 
> this for most of the targeted platforms, but I haven't found info on how 
> to do this for an HP 9000/700 or for an IBM R/S 6000.  Any suggestions?
> 

HPUX Fortran has no function for the CPU time.  You have to write your
own in C.  This is the code I'm using:

/* second() -- function returning CPU time elapsed since first call */

#include      <time.h>

float second( void )
{
	return ( (float)clock()) / CLOCKS_PER_SEC );
}

Compile it with
	cc -Aa -c second.c
and link the resulting object file second.o into your Fortran code.

A few notes on this:
a)  The Fortran code should declare the function as
	real    second
    (real = real*4) It returns the CPU time in seconds (You haven't guessed
    that, right?).
b)  Since the underlying C routine `clock()' starts running on the first
    reference to it and not from the start of the job, you may need to place
    a dummy invokation of `second' at the beginning of the Fortran program.
c)  IMPORTANT:  For some mysterious reason, HP decided to let the C function
    `clock()' return microseconds although the resolution of the clock is
    only 20 milliseconds or so.  Therefore, about 35 minutes are enough to
    exceed the return type (long int = 4 bytes) so the time value wraps
    around.  Very annoying.  I wrote an extra layer to the time function
    that adds an offset to the time returned by `second' and increments the
    offset by 2147.48 seconds each time a wraparound is detected.  That
    doesn't fix the problem but helps PROVIDED this function is called
    frequently enough.

Dirk Husfeld

Institute of Astronomy and Astrophysics     Tel.:(FRG) 89  92 20 94 40
Scheinerstrasse 1                           Fax :(FRG) 89  92 20 94 27
8000 Munich 80, FRG
Email: husfeld@astronomie.physik.uni-muenchen.dbp.de     (X.400)
 or    husfeld@usm.uni-muenchen.de                       (Internet)
From: jac@ds8.scri.fsu.edu (Jim Carr)
Newsgroups: comp.lang.fortran
Subject: Re: The Cray YMP fails paranoia arthmetic test?!
Date: 9 Oct 92 21:38:47 GMT
Reply-To: jac@ds8.scri.fsu.edu (Jim Carr)
Distribution: usa
Organization: SCRI, Florida State University

The Cray YMP has several well-documented features that affect its 
arithmetic accuracy.  The most serious is the fact that it does not 
have a divide unit, using reciprocal and multiply instead.  The 
reciprocal uses a method that never gives the last bit correctly, 
and thus the Cray will always give different answers than a machine
with an IEEE divide unit.  

Specifically, X/Y always tends to be too small.  Real division in 
an integer context (I=X/Y) can be particularly troublesome.  The 
Cray does not have an integer multiply or divide; however, the 
code it generates for I/J is set up to give the correct answer 
while FLOAT(I)/FLOAT(J) does not.  Division by 3 is especially bad. 

The Cray also lacks guard digits. 

Other than that, almost all of the problems with Cray arithmetic 
can be tracked back to Seymour saving a few $$$ by not having a 
divide unit in his CPU. 

--
J. A. Carr                                    |  "The New Frontier of which I  
jac@gw.scri.fsu.edu                           |  speak is not a set of promises
Florida State University  B-186               |  -- it is a set of challenges."
Supercomputer Computations Research Institute |   John F. Kennedy (15 July 60)
Newsgroups: comp.lang.fortran
From: jkorpela@lk-hp-16.hut.fi (Jukka Korpela)
Subject: Re: EXTENDED keyword = double?
Organization: Helsinki University of Technology, Finland
Date: 12 Oct 92 06:22:16 GMT

I tried to reply by mail, but it bounced back (.forest isn't
an Internet top-level domain). This is what I have to say:

	What does the keyword EXTENDED mean?

The manual knows it for sure :-).
I don't know which manual, since there are various Fortran
implementations for Mac.
But as an educated guess, I'd say it almost certainly isn't
the equivalent of "double" (double precision). More probably
it is extended (quadruple) precision real type. I don't
know what type, if any, you could use for it on your computer
(which you didn't specify), but several compilers support
extended precision reals in the IBM style, i.e. under
the name real*16. Of course, the characteristics (accuracy,
range) of extended precision reals vary from one implementation
to another, just as for normal real and double precision
types.

* Jukka "Yucca" Korpela, Manager of User Support
* Helsinki University of Technology (HUT) Computing Centre, Finland
* Internet mail address: Jukka.Korpela@hut.fi
From: jrbd@craycos.com (James Davies)
Newsgroups: comp.lang.fortran
Subject: Re: The Cray YMP fails paranoia arthmetic test?!
Date: 12 Oct 92 23:03:17 GMT
Distribution: usa
Organization: Cray Computer Corporation

In article <1992Oct10.050546.12565@leland.Stanford.EDU> ungar@leland.Stanford.EDU (Jeffrey Ungar) writes:
>
>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.

Not to defend Cray arithmetic, but I'd be a little bit leery of a Monte 
Carlo program that got widely varying results from different random number 
sequences (or that required that they be non-random, as you seem to be 
saying ;-)
From: pld@hpfcso.FC.HP.COM (Paul Dineen)
Date: Tue, 6 Oct 1992 19:28:49 GMT
Subject: Re: FORMAT overhead
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.lang.fortran

> reading 100000 records;  sample record: "         1234 -0.7654321"
> free format (eg. READ(1,*) ...)			 7.14 s
> no field sizes (eg. FORMAT(1X,I,F))		        15.28 s
> field sizes (eg. FORMAT(6X,I7,1X,F10.7)		16.47 s
> This surprised me;  I would have thought that the more well-specified
> the file format is, the less overhead there would be in translating the
> data.

  I would think so too.  I tried the first and last examples on an 
  HP 9000/750 (9.0 release), and got 7.06s and 6.22s.
From: pld@hpfcso.FC.HP.COM (Paul Dineen)
Date: Tue, 13 Oct 1992 16:30:03 GMT
Subject: Re: vax I/O
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.lang.fortran

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

 Could be several things:
   1. The use of 'name' is unrelated -- the user simply doesn't have proper 
      file access privileges.  This sounds likely based on your "no access" 
      comment.
   2. The user is typing in the name of a file that doesn't already
      exist (so status='old' is a problem).
   3. The user is typing in a name that's longer than 80 characters (unlikely)
      so it gets truncated.
Newsgroups: comp.lang.fortran
From: nn1@Ra.MsState.Edu (N. Narenthiran)
Subject: Re: home directory in unix
Keywords: getenv getarg
Organization: Mississippi State University
Date: Fri, 9 Oct 1992 22:19:44 GMT


  Thanks to the following for taking the time to respond to my posting.
      maine@altair.dfrf.nasa.gov (Richard Maine)
      mwilson@max.arc.nasa.gov (Michael A. Wilson)

  The problem was that I had leading blanks in my filename.  When
these were removed, the program works fine.  I wonder if there are
compilers that do not accept trailing blanks too.  I was told that
they should be removed in the responses I received.  But, this works
with trailing blanks in the Sun & SGI default f77 compilers and in
the Lahey compiler on a PC.

have a nice day.
naren.

Newsgroups: comp.lang.fortran
From: phychenk@nuscc.nus.sg (Chen Kan (Dr))
Subject: Allocatable arrays in Type definition (Fortran 90 question)
Organization: National University of Singapore
Date: Wed, 14 Oct 1992 00:42:52 GMT

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

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

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

Anyone has experiences on this?                          

                                   Kan

From: cunniff@hpfcso.FC.HP.COM (Ross Cunniff)
Date: Fri, 9 Oct 1992 15:44:20 GMT
Subject: Re: Quickie
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.lang.fortran

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

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

Ross Cunniff
Hewlett-Packard Graphics Software Lab
cunniff@fc.hp.com
Newsgroups: comp.lang.fortran