HDTenEightyP/NetNews huggingface dataset:
From: rlink@cedar.hao.ucar.edu (Richard Link)
Subject: home directory: better question
Organization: High Alititude Observatory/NCAR, Boulder CO
Date: Sat, 10 Oct 1992 05:02:00 GMT

I guess I did not define my problem very well when I posted an earlier
question on home directory expansions in unix.

My problem is this:

I need to deliver some portable software. It has to run on VMS, UNIX,
and MS-DOS (at least).

The programs need to access invariant database files.

I want to specify these files without hard-wiring the path within the
fortran program, since this would require modification of the
fortran source for every site, which may number in the hundreds.

If I knew where the `home' directory was, this would not be a problem.
Using unix getarg() and command line arguments does not work for VMS,
and I would like to make the code as system-independent as possible.

In VMS, one can do the following in a command shell script (*.com) :

$  user = f$getjpi("","username")               ! /path/.../whoami
$  user = f$extract(0,f$locate(" ",user),user)  ! whoami
$  data_dir:=['user'.dbase]                     ! concatenate directory
$  assign 'data_dir'fname.dat FNAME             ! concatenate filename

This assigns the equivalent of ~/whoami/dbase/fname.dat to a variable
called FNAME within the command shell.

VMS fortran recognizes the assigned file name as an environment variable,
so to open a file, one can use:

      character*48 fname/'FNAME'/
      open(unit=iunit, file=fname, status='old')

Thus, the command shell script gets the username and concatenates the
directory and filename, which is then passed to the fortran program.
Neither the shell script nor the fortran code need to know the explicit
path.

So my question is this: how can I get around specifying the full path
in the fortran code portable across these operating systems?
Or, more realistically, what can I do to make sure that the fortran
programs find the data files in the most portable manner?

Thanks in advance,

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

rlink@diablo.cpi.com
From: jim@nwra.com (Jim)
Newsgroups: comp.lang.fortran
Subject: Sun FORTRAN Compiler Alternatives
Summary: Looking for 3rd-party FORTRAN compilers
Date: 15 Oct 92 19:02:37 GMT
Article-I.D.: nwra.1992Oct15.190237.4874
Distribution: usa
Organization: Northwest Research Associates, Inc.

We are a Sun-based operation with a large number of people using
FORTRAN as their main language.  We are also becoming less and less
happy (if that is possible) with Sun's f77 compiler.  I would be
very interested in reviews, or personal opinions, of f77 (or f90 for 
that matter) compilers currently available (or available in the near 
future) for the Sun 4 / Sparc platform.  If there is interest, I 
will post a summary of what I find out.

Jim
-- 
*------------------------*------------------------------------*
|  Jim Secan             |   Northwest Research Assoc., Inc.  |
|  (jim@zelda.nwra.com)  |   P.O. Box 3027                    |
|  (206) 453-8141        |   Bellevue, WA  98009              |
Newsgroups: comp.lang.fortran
From: jumper@garfield.catt.ncsu.edu (Michael Lanham)
Subject: C & FORTRAN sharing stdout
Organization: North Carolina State University
Distribution: comp
Date: Mon, 12 Oct 1992 20:19:54 GMT

I am using DEC Fortran with  Ultrix 4.2 on a DEC 5000/200.  I cannot get a C
subroutine to print to stdout!  I have discovered that I had been using the
wrong logical unit number for the fortran WRITE statements (ie had been using
0 which is stderr for dec)  I am suppossed to use logical number 6 (stdout).
Printing from fortran works fine, but I cannot get my C routine to access
stdout.  Does anyone have clues? 
He who will not reason, is a bigot; he who cannot is a fool;
and he who dares not is a slave.      --- Sir William Drummond

Michael Lanham       mjlanham@eos.ncsu.edu   &  jumper@catt.ncsu.edu
Newsgroups: comp.lang.fortran
From: 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:21: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
From: mbk@lyapunov.ucsd.edu (Matt Kennel)
Newsgroups: comp.lang.fortran
Subject: Re: cray paranoia
Date: 10 Oct 1992 21:10:38 GMT
Organization: Institute For Nonlinear Science, UCSD
Distribution: world
NNTP-Posting-Host: lyapunov.ucsd.edu
X-Newsreader: Tin 1.1 PL3

fxt@helios.ucsc.edu (oxide owner) writes:
: > 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?

And what if, in fact, you spent megadollars just to always get that last bit
``correct''?  It's still just an approximation, anyway, so if you really
needed to make sure it's right (enough), you'll be using two methods for
computing something critical anyway.

I really don't understand the fetish that some have to get FP arithmetic
"correct", when "correct" is defined as "following one particular model
for arithmetic no exceptions no matter what cost".

I can see how the particular type of cray arithmetic used might make 0.2%
of programs somewhat harder to write than IEEE.  However, it makes Cray
programmers aware of the fact of approximation in FP arithmetic, which doesn't
ever go away no matter how you do it.  People who say Cray is "wrong"
and Sun is "right" mostly make Sun programmers complacent.

--
-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".
Newsgroups: comp.lang.fortran
Newsgroups: comp.lang.fortran

HP fortran implements a rather strange feature which allows a person to 
do arithmetic and relational expressions with character constants. For example:

	program strange
	integer i
	character*1 c
	byte b

	c = '9'
	b = 1
C
C set i to the hex equivalent of the ascii character 9
	i = X'38'
C
C multiply b by the ascii character (why anyone would want to
C is an open question :-)
C
	k = b * '9' 
	if (k .ne. 3249) print *, 'what is going on around here?'
	end

Ignoring the questionable nature of the above program, the question I put
before this august body :-) deals with what happens to the character constant
as it is converted to an integer for the multiplication "b * '9'."  If the
integer is anything larger than a byte, the character constant is blank padded
(on the right) to the size in bytes of the integer by the compiler.  My first
take on this action, is that its wrong to blank pad '9' to '9 ' when
multiplying by a 4 byte integer.  If someone want to multiply by '9' they
should *get* multiplication by '9'.  Also, the value derived by blank padding
'9' would vary depending on the size of an integer (2 or 4 bytes).  

Anyone care to comment (not too sharply I hope) on this behavoir?

best regards,

Jim Bigelow
Colorado Language Lab
Hewlett Packard
Ft. Collins, CO

All opinions expressed herein are mine and do not reflect on HP.


Newsgroups: comp.lang.fortran
From: fairfield@slacvx.slac.stanford.edu
Subject: CORRECTION: reading VAX unformatted data on a Sun?
Organization: Stanford Linear Accelerator Center
Date: Fri, 16 Oct 1992 23:10:25 GMT

Yesterday I wrote:

In article <1992Oct15.145840.1@slacvx.slac.stanford.edu>, fairfield@slacvx.slac.stanford.edu writes:
> In article <1992Oct14.232548.24055@u.washington.edu>, larryw@nori.bioeng.washington.edu (Larry Weissman 5-2011) writes:

[examples of VAX --> IEEE floating point deleted]

> This is WRONG (unless SPARCstations don't use IEEE floats...)!
          ^^^^^
    However I WAS WRONG about Larry being wrong.  Mea culpa.

    Turns out that one does, indeed, need to subtract 2, not 1, from the
VAX exponent to convert to the IEEE exponent: subtract 1 for the change
in bias from 128 to 127, subtract _another_ one because of the normaliza-
tion: VAX normalizes to 0.1bbbbbbb (and suppresses the required "0.1")
while IEEE normalizes 1.bbbbbbb (and suppresses the leading "1.").  Thus
decrementing the high-byte of the float subtracts 2 from the exponent
which is correct.  Note, however, that VAX floats which lie outside the 
IEEE range for single precision floats are not correctly handled by this 
code...

		Sorry :-(,  Ken
-- 
 Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slacvx.Slac.Stanford.Edu
 SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
 ----------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
From: cpg@jet.uk (Dr Chris P Gatcombe)
Newsgroups: comp.lang.fortran
Subject: Re: home directory in unix
Date: 9 Oct 92 08:00:39 GMT
Organization: Joint European Torus

In <1992Oct8.200540.13579@ncar.ucar.edu> rlink@cedar.hao.ucar.edu (Richard Link) writes:

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

If you mean you have a program which a user has to enter a filename,
and they simply enter ~/mydir/myfile.dat, then how about testing 
for the ~ character, and substituting it with the value of the
environment variable $HOME (using getenv) ?

Chris.
-- 
Dr. Chris Gatcombe
Tessella Support Services plc, 3 Vineyard Chambers, Abingdon, OX14 3PX, UK.
Room K1/0/31, JET Joint European Undertaking, Abingdon, OX14 3EA, UK.
E-mail: gatc@tessella.co.uk or cpg@jet.uk
- Disclaimer: Please note that the above is a personal view and should not 
  be construed as an official comment from the JET project.
From: ljeung@sfsuvax1.sfsu.edu (Lawrence Jeung)
Subject: IEEE floating-point arithmetic exceptions
Originator: ljeung@sfsuvax1.sfsu.edu
Organization: San Francisco State University
Date: Tue, 13 Oct 1992 11:47:47 GMT

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.

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.

Lawrence Jeung 
Newsgroups: comp.lang.fortran
From: cflatter@nrao.edu (Chris Flatters)
Subject: Re: The Cray YMP fails paranoia arthmetic test?
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Fri, 9 Oct 92 23:13:21 GMT

In article 14347@leland.Stanford.EDU, ungar@leland.Stanford.EDU (Jeffrey Ungar) writes:
>Extensive debugging revealed that the energy changes calculated on the
>Cray were slightly different from those calculated on the 486. Normally
>this would not cause many problems ( the differences were in the last
>digit or two ) except that a difference that should have evaluated to
>zero became about -1e-13. Unfortunately, this resulted in one less call
>to a pseudo random number generator, which meant the the calculations
>on the two machines would diverge at that point. It was easy to change
>the test used to decide whether to accept a MC step or not to avoid
>potential inconsistency, but the behavior prompted me to test the Cray's
>arithmetic using the paranoia program from netlib.
>
>According to dpara.f the arithmetic has 2 serious defects, one defect,
>and 2 flaws.
>
>According to spara.f the arithmetic has 2 FAILURES (things like 5!=1+4)
>
>The C version uncovers similar problems. What gives?

In short: Cray's floating-point implementation is very poor.  

For example, Cray do not use a guard digit in addition or subtraction.
This means that the subtraction of two nearly equal numbers can cause
a massive loss of precision.  Most computers do use a guard digit that
ensures that the loss of precision is in subtraction is always less than
twice the machine precision.  Paranoia should (rightly) flag this as
a serious defect.

	Chris Flatters
	cflatter@nrao.edu




Newsgroups: comp.lang.fortran
From: larryw@nori.bioeng.washington.edu (Larry Weissman 5-2011)
Subject: Re: reading VAX unformatted data on a Sun?
Organization: University of Washington, Bioengineering
Date: Wed, 14 Oct 1992 23:25:48 GMT

Edward J. Hartnett (ejh@khonshu.colorado.edu, 13 Oct 92 14:38:33) writes:

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

There are serveral issues regarding data conversion.

	- Did you use Fortran sequential or direct I/O? This will determine
	  whether extra characters are added to each record.

	- What data types were written? Do you have a mix of REAL, INTEGER,
	  DOUBLE PRECISION, ...? Do you know what the mix is?

	- If REAL or DOUBLE PRECISION, do you know which type was used?
	  Later VAXes supports different flavors, selectable by compiler
	  switches.

INTEGERS are easy to deal with just by byte swapping.
If you have pure standard REAL's with no record separators, you can use a
program like the one below to convert them. Hope you have a K&R C compiler.

/*
 * convert_simdat: Convert SIMDAT file to xdr form (VAX version)
 * This is not portable - it only works on a SPARCstation!
 *
 * L. Weissman  10Aug90 DG MV/10000 version
 *		29Sep92 VAX version (for Fetrow)
 */

#include <stdio.h>
#include <math.h>

			/* Floating point zero, external form */
#define EXT_ZERO 0x0
			/* byte swap macro */
#define swap(x,y)	{ char c; c = x; x = y; y = c; }

/*
 * vaxfloat: convert VAX floating point data
 */
float vaxfloat(r)
float r;
{
	union u_tag {
	    float r;
	    char  c[4];
	} u;

	u.r = r;
	swap(u.c[0],u.c[1]);			/* VAX byte ordering */
	swap(u.c[2],u.c[3]);
	if(u.c[0]) u.c[0] -= 1;			/* correct the exponent */
	return u.r;
}

int main(argc,argv)
int argc;
char *argv[];
{
	int fmt_flag=0;		/* indicates -f flag */
	int verbose=0;		/* verbose flag */
	char c;
	float f;
	int n=0;		/* number of floats converted */

	while (--argc > 0 && (*++argv)[0] == '-')
	    while(c = *++argv[0]) {
		switch(c) {
		case 'f':
			fmt_flag++;
			break;
		case 'v':
			verbose++;
			break;
		default:
			fprintf(stderr,"-%c is not a valid flag\n",c);
			exit(1);
		}
	    }

	while ( read(0,&f,4) == 4 ) {
	    n++;
	    f = vaxfloat(f);
	    if (fmt_flag)
		fprintf(stderr,"%f\n",f);
/* ---------------------
	    else {
		if (itox_f(&f,1) ) {
		    fprintf(stderr,"Conversion error at longword: %d\n",n);
		    f = EXT_ZERO;
		}
		write(1,&f,4);
	    }
--------------------- */
	}
	if ( verbose )
	    fprintf(stderr,"\n%d floats converted\n",n);
	exit(0);
}
-- 
---------------------------------------------------------------------------
Larry Weissman                         Center for Bioengineering, WD-12
larryw@nsr.bioeng.washington.edu       Univ of Washington, Seattle WA 98195
Phone: (206)685-2011                   FAX: (206)685-3300
From: jac@moonshine.llnl.gov (James A. Crotinger)
Newsgroups: comp.lang.fortran
Subject: Re: reading VAX unformatted data on a Sun?
Date: 14 Oct 92 05:34:21 GMT
Organization: Magnetic Fusion Energy - LLNL


  Check convert_external(3M) [do "man convert_external" on your sun
(make sure you have /usr/lang/man in your MANPATH). I haven't used
these, but I think they're supposed to do what you need.

  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: jac@ds8.scri.fsu.edu (Jim Carr)
Newsgroups: comp.lang.fortran
Subject: Re: The Cray YMP fails paranoia arthmetic test?!
Date: 11 Oct 92 19:52:18 GMT
Reply-To: jac@ds8.scri.fsu.edu (Jim Carr)
Distribution: usa
Organization: SCRI, Florida State University

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

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

That is, unless they have the totally unreasonable expectation that 
they can set X=3. and Y=3. and expect I=X/Y to give 1 for use in 
some test that determines the path through the code...

There is inexact, and then there is wrong.  

Users are well advised to use NINT when using the result of a 
floating divide in an integer context.  

What I have found amusing is to compare the way a Cyber-205 generated 
accumulated round-off error from the way it rounds to smaller values, 
which meant positive numbers got smaller in magnitude and negative 
numbers got larger in magnitude, to the way a Cray biases division 
to be a "bit" smaller than expected.   On my application, the Cray 
won out, but this is not always the case.  Caveat User. 

--
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: aswx266@chpc.utexas.edu (Michael Lemke)
Subject: Re: home directory in unix
Keywords: getenv getarg
Organization: The University of Texas System - CHPC
Date: Sat, 10 Oct 92 01:27:18 GMT

In article <nn1.718669184@Ra.MsState.Edu> nn1@Ra.MsState.Edu (N. Narenthiran) writes:
>
>  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 have always wondered about this but didn't investigate.  After all, a 
UNIX filename can consist of *any* ASCII character (on most
implementations I believe) so a filename with trailing blanks is
perfectly legal (and not too difficult to produce by accident).  How 
would you access such a file if INQUIRE et al. strip trailing blanks?  
Usually removing the blanks is what you want but wasn't Unix' philosophy
something along the lines `you asked for it...'?

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


-- 
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
Newsgroups: comp.lang.fortran
From: rvenable@helix.nih.gov (Richard M. Venable)
Subject: Re: home directory: better question
Organization: National Institutes of Health, Bethesda
Date: Sun, 11 Oct 1992 00:13:54 GMT

In response to article 7392 with all the VMS FORTRAN lore:

I believe there is a way to get arguments from the command line under VMS,
but of course it does not use a call to 'getarg'; that's Unix.  I know of at
least one program developed on a VAX that does read command line arguments.

Second, the 'getenv' call can be used to do exactly what is described in that
article, namely get the value of an environment variable and use it as any
other string:  (see also Article 7369)

	CHARACTER*255 fname, varname
	varname = 'FILEPATH'
		:
	CALL GETENV(varname,fname)
	OPEN (UNIT=20,FILE=fname, ... )

Prior to execution of the program, one simply sets the environment variable:

% setenv FILEPATH ~/.rcfile

I know DOS has environment variables, and probably can pass command line
arguments as well; it may depend on who's version of FORTRAN (IBM,MS,...)
you are using.  I believe you can get command line args and environment
variables in Unix, DOS, and VMS; the calls themselves will be different on
each platform.