HDTenEightyP/NetNews huggingface dataset:
From: ejh@khonshu.colorado.edu (Edward J. Hartnett)
Subject: Re: Quickie
Organization: CIRES, University of Colorado
	<EJH.92Oct10160448@khonshu.colorado.edu>
	<1992Oct11.011856.4116@ecsvax.uncecs.edu>
Date: 11 Oct 92 16:32:46

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

   > 
   > Yes, I should have done this:
   > 
   > 	write(*,*) msg(n)(:lnblnk(msg(n)))
   > 
   > This will only print the message to the last non-blank, i.e. it won't
   > print trailing blanks. In this circumstance, using '(a)' and * have
   > the same effect. Note that if you have an implicit none satement at
   > the top of you program, the function lnblnk will have to be declared
   > as an integer.
   > --
   > Edward Hartnett			ejh@khonshu.colorado.edu
   > 
      write(*,*)msg(n)(:lnblnk(msg(n)))
		      ^^^^^^^^^^^^^^^^^
   What dialect of Fortran is the above construction? 

I've used this on the Convex and Sun. I think I've also used it on one
compiler each on the Mac and PC (I don't program them in FORTRAN much,
so I can't be certain). LNBLNK() is a function that
returns the number of the last non-blank in a string, and I was under
the impression that it was pretty common, but I could be wrong.
I wouldn't be hard to write one, of course, if it wasn't included with
your compiler.

STRING(a:b) will return the string's contents from a to b. That's
part of the standard, isn't it? And usually (in my limited experience
in porting Fortrna between machines) if you leave out the a it will
assume you want to start at the beginning of the string, and similarly
for b and the end of the string. Thus, STRING(:LNBLNK(STRING)) will
give you the string from the beginning to the last non-blank of that
string, i.e. it will trim the blanks from the string. Actaully I never
gave much thought to how portable it was, but I should think it would
work for most compilers.
--
Edward Hartnett			ejh@khonshu.colorado.edu
From: lionel@quark.enet.dec.com (Steve Lionel)
Newsgroups: comp.lang.fortran
Subject: Re: reading VAX unformatted data on a Sun?
Date: 14 Oct 92 00:31:33 GMT
Organization: Digital Equipment Corporation


In article <EJH.92Oct13143833@khonshu.colorado.edu>, ejh@khonshu.colorado.edu 
(Edward J. Hartnett) 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.
> 

Sun systems uses big-endian integers and IEEE floating point.  VAX uses
little-endian integers and VAX floating point.  The integers can be
converted with byte swapping, but for the floating data you'll need
to do more elaborate conversions.

Current versions of DEC Fortran on the RISC ULTRIX platform and future versions
on OpenVMS (VAX and AXP) and OSF/1 AXP platforms can read and write data in
big-endian integer and IEEE floating formats by means of an OPEN statement
option (as well as IBM System\370, Cray, little-endian IEEE (a native AXP
format), VAX D and VAX G formats).   If you have access to DEC Fortran on a
DECstation, you could do the conversion that way, otherwise you'll have to find
some data conversion routines (I've seen some posted to this newsgroup in the
past, but have never tried them.)

I understand that this may not be too helpful, but it's at least a start
to know what you've got and where you want to end up. 

(DEC, OpenVMS, VAX, ULTRIX and AXP are trademarks of Digital Equipment 
Corporation)

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
Newsgroups: comp.lang.fortran
From: urjlew@ecsvax.uncecs.edu (Rostyk Lewyckyj)
Subject: Re: Quickie
Organization: UNC Educational Computing Service
Date: Thu, 8 Oct 1992 02:14:27 GMT

In article <1992Oct6.134516.25053@wega.rz.uni-ulm.de>, CCC_KARG@rzmain.rz.uni-ulm.de (ComRam) writes:
> In <25960@oasys.dt.navy.mil> mulvihil@oasys.dt.navy.mil writes:
> 
> >       integer n
> >       n=1
> >       write(*,n)
> >     1 format(2x,'my brain hurts')
> 
> How about a little ASSIGN 1 TO n
>                    WRITE(*,n)
> 		 1 FORMAT(blubb)
> 
> 


There have been two other suggestions:
Store the formats in character arrays and WRITE(*,fmt(n))  and
Store the messages in arrays and write them with a common format 
WRITE(*,'(A)')msg(n). (Please check if there must be a field
width for the A format item Aw ).
I prefer either of these two over the ASSIGN, because to get to
the ASSIGN one would need something like a COMPUTED GO TO
      GO TO (100,200,.....),n
999   GOTO 99999 ! Error escape
100   ASSIGN 1 TO n
      GO TO 9999
.........
9999  WRITE(*,n)

-----------------------------------------------
  Reply-To:  Rostyslaw Jarema Lewyckyj
             urjlew@uncmvs.acs.unc.edu    (ARPA,SURA,NSF etc. internet)
          or urjlew@unc.bitnet
          or urjlew@ecsvax.UUCP 
       tel.  (919)-962-6501
From: scocc@thor.cf.ac.uk (Chris Cook)
Newsgroups: comp.lang.fortran
Subject: Fortran in a DEC Ultrix environment : Upcasing?
Date: 15 Oct 92 14:16:17 GMT
Organization: University of Wales College of Cardiff, Cardiff, Wales, UK

I'm a relative novice to implementing Fortran in a Unix environment.  As
such, I can't figure out how to access the TOUPPER or similar function
from within a Fortran programme.  Could someone please let me know how
it's done, complete with compilation flags.

	Many thanks,

                           Chris Cook - Postmaster

_____________________________________________________________________________
| E-mail     : CookC@Cardiff.AC.UK      |      Mail: University of Wales    |
| Phone      : +44 222 874875           |               College of Cardiff, |
| (Direct)   : +44 222 874214           |              40-41 Park Place,    |
| Fax        : +44 222 874285           |      Cardiff, CF2 3BB, UK         |
|_______________________________________|___________________________________|
Newsgroups: comp.lang.fortran
From: khb@chiba.Eng.Sun.COM (chiba)
Newsgroups: comp.lang.fortran
Subject: Re: IEEE floating-point arithmetic exceptions
Date: 14 Oct 92 16:16:41
Organization: Sun MegaSystems
NNTP-Posting-Host: chiba
In-reply-to: ljeung@sfsuvax1.sfsu.edu's message of Tue, 13 Oct 1992 11:47:47 GMT


In article <1992Oct13.114747.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.

Either Inexact or Underflow alone is typically harmless. The two
together is harmless for the vast majority of applications and
programmers .... however, for those deeply involved in numerical
analysis it is a sign that they should do some thinking.

   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

It would be nice to have a complete description (probably offline) of
what you are doing. It is possible (though not likely) that you have
found a bug. It is most likely that we did not provide tutorial enough
IEEE material in the documents.

   suspicion that the workstation I'm using doesn't use gradual
   underflow.

Unless you turned it off; you have it. It is part of IEEE 754 and the
SPARC ISA. 

How does one turn it off?

	1) compile -fnonstandard (which is implied by -fast)
	2) add a call to nonstandard_arithmetic() to your program
           (or the obsolete call to abrupt_underflow)

Had you done so, the IEEE retrospective message above would have
reflected it .. unless you cleverly turned gradual underflow back on
before exiting.... which seems unlikely.

Unlike the problems with CRI arithmetic (years ago Kahan proposed
addition of a guard digit to correct the worst errors) these warnings
are very unlikely to cause you grief. Not impossible, however, which
is why they are provided.
--
----------------------------------------------------------------
Keith H. Bierman    keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM
SunPro 2550 Garcia MTV 12-40             | (415 336 2648) fax 964 0946
Mountain View, CA 94043  <speaking for myself, not Sun*> Copyright 1992

Newsgroups: comp.lang.fortran
From: ejh@khonshu.colorado.edu (Edward J. Hartnett)
Subject: Re: Quickie
Organization: CIRES, University of Colorado
	<1992Oct8.021427.8589@ecsvax.uncecs.edu>
	<28870@nntp_server.ems.cdc.com>
Date: 10 Oct 92 16:04:48

In article <28870@nntp_server.ems.cdc.com> mstemper@ems.cdc.com (Michael Stemper) writes:

   In article <1992Oct8.021427.8589@ecsvax.uncecs.edu>, urjlew@ecsvax.uncecs.edu (Rostyk Lewyckyj) writes:
   |> In article <1992Oct6.134516.25053@wega.rz.uni-ulm.de>, CCC_KARG@rzmain.rz.uni-ulm.de (ComRam) writes:
   |> > 
   |> > How about a little ASSIGN 1 TO n
   |> >                    WRITE(*,n)
   |> > 		 1 FORMAT(blubb)
   |> > 
   |> 
   |> There have been two other suggestions:
   |> Store the formats in character arrays and WRITE(*,fmt(n))  and
   |> Store the messages in arrays and write them with a common format 
   |> WRITE(*,'(A)')msg(n). (Please check if there must be a field
   |> width for the A format item Aw ).

   If no width is specified, the width of the item (trailing blanks and
   all) will be used.

Yes, I should have done this:

	write(*,*) msg(n)(:lnblnk(msg(n)))

This will only print the message to the last non-blank, i.e. it won't
print trailing blanks. In this circumstance, using '(a)' and * have
the same effect. Note that if you have an implicit none satement at
the top of you program, the function lnblnk will have to be declared
as an integer.
--
Edward Hartnett			ejh@khonshu.colorado.edu
From: fairfield@slacvx.slac.stanford.edu
Newsgroups: comp.lang.fortran
Subject: Re: reading VAX unformatted data on a Sun?
Date: 15 Oct 92 22:58:40 GMT
Article-I.D.: slacvx.1992Oct15.145840.1
Organization: Stanford Linear Accelerator Center

In article <1992Oct14.232548.24055@u.washington.edu>, larryw@nori.bioeng.washington.edu (Larry Weissman 5-2011) writes:
[...]
> 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!
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  Really???
[...]
> 			/* 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;                 |
> }                                 |
                                    |
This is WRONG (unless SPARCstations don't use IEEE floats...)!

The exponent field does NOT fall within byte boundaries in either the IEEE
or the VAX fp format.  To correct the above algorithm, you would need to to
a circular shift left one bit on u.r, do the decrement on u.c[0], then
circular shift right one bit.  (Since this is a FORTRAN newsgroup, I don't
have to pretend to know C, right, but on my VAX, I can use the intrinsic
ISHFTC ;-).  The algorithm is otherwise correct owing little-endian to big-
endian byte order conversion, the unusual (even from VMS' perspective!) field
placement in the VAX fp (implemented for "compatibility" mode with the earlier
PDP-11 fp format/16-bit architecture) and the fact that the VAX biases the
exponent by 128 rather than by 127 as in IEEE.

--
 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...
Newsgroups: comp.lang.fortran
From: hsue@ellis.uchicago.edu (marc jacobson)
Subject: Help Wanted: How to run Fortran on VMS?
Reply-To: hsue@midway.uchicago.edu
Organization: none to speak of
Distribution: usa
Date: Sat, 17 Oct 1992 01:17:47 GMT

Hi, 
I dont know the commands to run Fortran on VMS.  Does anyone can help?
Please Email me.

THank!


Newsgroups: comp.lang.fortran
From: jtbell@hubcap.clemson.edu (Jon Bell)
Subject: Re: EXTENDED keyword = double?
Organization: Presbyterian College, Clinton SC
Date: Mon, 12 Oct 1992 19:02:43 GMT

In article <JKORPELA.92Oct12082216@lk-hp-16.hut.fi> jkorpela@lk-hp-16.hut.fi (Jukka Korpela) writes:
>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?
>

On the Mac, EXTENDED generally means the 80-bit extended precision
floating point format which is defined by SANE (the Standard Apple Numerics
Environment).  Language Systems Fortran allows you to declare REAL,
DOUBLE and EXTENDED variables, which give you 32, 64 and 80 bits
respectively.  

Jon Bell / Physics & Comp. Sci. / Presbyterian College / Clinton SC USA
From: david@donald.concordia.ca (David Gaudine)
Newsgroups: comp.lang.fortran
Subject: Command Line Parameters
Date: 9 Oct 92 19:48:09 GMT
Organization: ORGANIZATION!! HERE? You must be kidding

Can someone tell me how to read command line parameters from FORTRAN
under UNIX?  (Specifically ULTRIX, but some portability would be nice).

Is that clear enough?  I mean, if I have a program called "prog" and an
input file called "data", I want to be able to run the program by typing
"prog data".  Like argc and *argv[] in a C program.
-- 
---------------------------------------------------------------------------
David Gaudine, Concordia University, Montreal has a very unimaginative sig.
---------------------------------------------------------------------------
Newsgroups: comp.lang.fortran
From: zkdc05@trc.amoco.com (Kelly D. Crawford)
Subject: Re: Quickie
Originator: zkdc05@church
Organization: Amoco Production Company, Tulsa Research
Date: Mon, 12 Oct 1992 15:36:23 GMT


In article <EJH.92Oct11163246@khonshu.colorado.edu>, ejh@khonshu.colorado.edu (Edward J. Hartnett) writes:
> In article <1992Oct11.011856.4116@ecsvax.uncecs.edu> urjlew@ecsvax.uncecs.edu (Rostyk Lewyckyj) writes:
> 
>    > 
>    > Yes, I should have done this:
>    > 
>    > 	write(*,*) msg(n)(:lnblnk(msg(n)))
>    > 
>    > This will only print the message to the last non-blank, i.e. it won't
>    > print trailing blanks. In this circumstance, using '(a)' and * have
>    > the same effect. Note that if you have an implicit none satement at
>    > the top of you program, the function lnblnk will have to be declared
>    > as an integer.
>    > --
>    > Edward Hartnett			ejh@khonshu.colorado.edu
>    > 
>       write(*,*)msg(n)(:lnblnk(msg(n)))
> 		      ^^^^^^^^^^^^^^^^^
>    What dialect of Fortran is the above construction? 
> 
> I've used this on the Convex and Sun. I think I've also used it on one
> compiler each on the Mac and PC (I don't program them in FORTRAN much,
> so I can't be certain). LNBLNK() is a function that
> returns the number of the last non-blank in a string, and I was under
> the impression that it was pretty common, but I could be wrong.
> I wouldn't be hard to write one, of course, if it wasn't included with
> your compiler.
> 
> STRING(a:b) will return the string's contents from a to b. That's
> part of the standard, isn't it? And usually (in my limited experience
> in porting Fortrna between machines) if you leave out the a it will
> assume you want to start at the beginning of the string, and similarly
> for b and the end of the string. Thus, STRING(:LNBLNK(STRING)) will
> give you the string from the beginning to the last non-blank of that
> string, i.e. it will trim the blanks from the string. Actaully I never
> gave much thought to how portable it was, but I should think it would
> work for most compilers.

The syntax is standard.  The function lnblnk is not a standard intrinsic, so
you may have to write it yourself on systems that do not support it.  There
is nothing nonstandard about using such a function...

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 *** <<<
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.lang.fortran
Subject: Re: For HP and IBM RISC hosts, how to get cpu times from Fortran?
Date: 13 Oct 92 22:26:00 GMT
Organization: CWI, Amsterdam

In article <1992Oct13.155347.15401@news.lrz-muenchen.de> HUSFELD@usmv01.usm.uni-muenchen.de (Husfeld, Dirk) writes:
 > HPUX Fortran has no function for the CPU time.  You have to write your
 > own in C.  This is the code I'm using:
 > 
What is wrong with the following (which I have in my source tree, although I
have no access to HP machines quite some time)?
      REAL FUNCTION GTIME()
      INTEGER T(4)
      EXTERNAL TIMES
      CALL TIMES(T)
      GTIME = (T(1) + T(2)) / 100.0
      RETURN
      END
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
Newsgroups: comp.lang.fortran
From: john@aquarius.unm.edu (John Prentice)
Subject: Re: cray paranoia
Date: Mon, 12 Oct 92 16:19:17 GMT
Organization: Dept. of Physics & Astro, University of New Mexico, Albuquerque

In article <1b7gseINNlrl@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
>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.
>

I was a bit surprised to see someone from a nonlinear science institute
making this comment.  You are correct that not all problems are sensitive
to incorrect rounding, but there most certainly are those that are.  In
particular, if you are trying to calculate the onset of chaos, or something
like the Lyapunov exponent, you damn sure need to be sure that the computer
arithmetic is not the reason you are getting divergence in your results.
It would seem to me that with our recent (but belated) realization that the
world around us is nonlinear, not to mention with the advent of gigaflop
systems capable of running enough iterations for all this to matter, we
should be getting much more worried about computer arithmetic than ever
before.  

Sure, floating point arithmetic is inherently an approximation.  However,
that is not a reason to accept unnecessarily losing precision because
the system is failing to do proper computer arithmetic.  48 bits isn't
all that much precision, I don't care to waste it. 

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
Xref: sparky comp.lang.fortran:3901 comp.lang.c:14688 vmsnet.admin:437 comp.unix.questions:11909 comp.unix.xenix.sco:3081
From: michaelb@wshb.csms.com ( WSHB Operations Eng)
Newsgroups: comp.lang.fortran,comp.lang.c,vmsnet.admin,comp.unix.questions,comp.unix.xenix.sco
Subject: Fortran compiler or f2c translator
Date: 8 Oct 92 17:42:55 GMT
Followup-To: poster
Organization: WSHB, Herald Broadcasting Syn., Inc., Cypress Creek, SC, USA

Help! I've got an old Fortran program that is for VMS. I want to get it
running on an SCO Xenix box, but I don't know too much about Fortran, nor
do I have a Fortran compiler. The source code is one giant file, not a
bunch of small modules like I'm used to, and it's a little over 400 pages
long once I print it out.

Does anyone have any recommendations about how to proceed. I know there is
a translator named f2c available on some archive. Does it really work very 
well with something this size. I really can't spend the time to sit down 
and piece it together by myself, even if I had the experience in C to try 
something so foolish. I do have gcc if it would be better than cc to deal 
with the output of f2c.

As an alternative, is there some Fortran compiler out there I could grab
off an archive and get working. Or would I be forced to buy a comercial
compiler? Is Fortran standard enough that I could probably get it running
on Xenix without a lot of debugging if I can get a compiler?

Or, maybe, is it cheaper to just get an old microvax from somewhere and get
it running in the environment it was designed for? How many $$ would I be
looking at to get a used machine and licenses to get it going?

Thanks in advance,
Michael
-- 
Michael Batchelor--Systems/Operations Engineer #compliments and complaints
WSHB - An International Broadcast Station of   #   letterbox@csms.com
       Herald Broadcasting Syndicate, Inc.     #technical questions and reports
michaelb@wshb.csms.com         +1 803 625 5552 #   letterbox-tech@csms.com
Newsgroups: comp.lang.c
From: phil@dnbf01.bram.cdx.mot.com (Phil Longstaff)
Subject: Re: Volatile variables and optimization
Reply-To: phil@dnbf01.bram.cdx.mot.com (Phil Longstaff)
Organization: Motorola Codex, Mississauga, Ontario
Date: Fri, 16 Oct 1992 14:07:48 GMT

In article <chupchup.719226966@piggy>, chupchup@ferkel.ucsb.edu (Robert Earl) writes:
|>votava@fndaud.fnal.gov (Margaret Votava) writes:
|>
|>| 	I've got a simple question about the correct behavior of the ANSI
|>| C compiler regarding volatile variables. I have a memory location that I 
|>| simply want to read. I don't want to do anything with the result; it is
|>| just a hardware location that needs to be touched.
|>
|>| 	The following piece of code will access the location when compiled
|>| without optimization, but is optimized out when optimization is turned on in 
|>| the compilation command.
|>
|>| 	I thought the point of volatile was to *always* fetch the value
|>| from memory.
|>
|>| int junk()
|>| {
|>| 	volatile unsigned short *mem_addr;
|>
|>Your problem is that the pointer object itself is volatile, rather
|>than what you wanted, which is the object to which "mem_addr" points.
|>Try this instead:
|>
|>unsigned short *volatile mem_addr;

In this application, does it matter whether the pointer or the object pointed
to is volatile?  In the latter case, the value needs to be read because it is
volatile and may change.  In the former case, the pointer may now point at a
different object, so the value must be read.  In either case, the value must be
read.