HDTenEightyP/NetNews huggingface dataset:
From: thompson@atlas.socsci.umn.edu (T. Scott Thompson)
Subject: Re: Problems printing numbers in SUN Fortran
Reply-To: thompson@atlas.socsci.umn.edu
Organization: Economics Department, University of Minnesota
Date: Thu, 8 Oct 1992 15:36:26 GMT

spxsjm@thor.cf.ac.uk (Mr S J Morris 92) writes:

>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 compiled and ran the following program with no problems on a Sparc 1:

      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=(1.0d0,1.0d0)
      print *,'result=',result
      return
      end

(Well, actually there were some undefined entry points referenced.
But the program ran.)

The output produced was:

result=  (    1.0000000000000,    1.0000000000000)
result=  (    1.0000000000000,    1.0000000000000)

No funny stuff that I can see.

Can you show us a small, _complete_ program that reproduces the
problem?  Maybe you really have found a bug.
--
T. Scott Thompson              email:  thompson@atlas.socsci.umn.edu
Department of Economics        phone:  (612) 625-0119
University of Minnesota        fax:    (612) 624-0209
From: lees@cps.msu.edu (John Lees)
Newsgroups: comp.lang.fortran
Subject: SunOS F77 linking question
Date: 14 Oct 92 11:47:20 GMT
Distribution: usa
Organization: Department of Computer Science, Michigan State University
Originator: lees@ahmeek.cps.msu.edu

Using Sun F77 1.4 under SunOS 4.1.2, I am having a problem with _MAIN_
being undefined when trying to call a fortran routine from a c program.
The problem goes away with -Bstatic, but I would like to figure out
what is going on. The problem occurs with the simplest of programs,
such as those shown in Chapter 14 of the Users' Guide.

Invoking "f77 -dryrun c.o f.o" shows that the frontend is emitting
"-u _MAIN_". Why? Trying to link using cc or ld causes other problems.

Sorry, we're not a fortran shop. Our only use of fortran is in libraries
such as eispack and linpack.

Thanks for any help. Please email.
----------                                                     O
 John Lees, Pattern Recognition & Image Processing Laboratory OoO
 Systems Analyst & Lab Manager, Computer Science Department   /O  one
 A714 Wells Hall, MSU, East Lansing, Michigan, 48824-1027     |   world
 lees@pixel.cps.msu.edu, lees@msuegr.bitnet, CIS 74106,1324  (|)  one
   M i c h i g a n   S t a t e   U n i v e r s i t y         _|_  people
Newsgroups: comp.lang.fortran
From: ankruger@icaen.uiowa.edu (Anton Kruger)
Subject: FORTRAN Book for sale...
Date: Wed, 14 Oct 1992 18:38:04 GMT
Distribution: na
Organization: Iowa Computer Aided Engineering Network, University of Iowa

I have 2 copies left of my book:

              Efficient Fortran Programming
              John Wiley, 1991, 184 pages

for sale. The list price is $34.95 and I am selling for $25, postage included.
If you are interested, send a check/money order to:

             Anton Kruger
             215 Marengo Road #2
             Oxford, IA 52322

A review of the book appears in the March 1991 issue of the ACM publication
Fortran Forum.  Please contact me by e-mail to make sure that copies are
left before you mail any money.



-- 
-------------------------------------------------------------------------------
Anton Kruger                                           ankruger@icaen.uiowa.edu
Xref: sparky comp.lang.fortran:3894 comp.sys.sun.apps:2176 comp.unix.misc:3896 comp.sys.sun.misc:4560
From: ishikawa@ds5200.personal-media.co.jp (Chiaki Ishikawa)
Newsgroups: comp.lang.fortran,comp.sys.sun.apps,comp.unix.misc,comp.sys.sun.misc
Subject: GreenHills (e-mail) address sought.
Date: 8 Oct 92 11:01:55 GMT
Reply-To: ishikawa@personal-media.co.jp
Followup-To: comp.lang.fortran
Organization: Personal Media Corp., Tokyo Japan


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?

Please reply by e-mail.
Thank you in advance for your help.


 Chiaki Ishikawa,  Personal Media Corp.,  MY Bldg, 1-7-7 Hiratsuka,
 Shinagawa, Tokyo 142, JAPAN. FAX:+81-3-5702-0359, Phone:+81-3-5702-0351
 UUNET: ishikawa@personal-media.co.jp
Newsgroups: comp.lang.fortran
From: math1rb@elroy.uh.edu (92F07486)
Subject: vax I/O
News-Software: VAX/VMS VNEWS 1.41    
Organization: University of Houston
Date: Fri, 9 Oct 1992 19:34:00 GMT

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?


************************************************************************
**                            **                                      **
**   David C. Meyers          **  "I'm looking California,            **
**                            **    and feeling Minnesota..."         **
**   MATH1RB@JETSON.UH.EDU    **                  - Cornell           **
**                            **                                      **
************************************************************************


Newsgroups: comp.lang.fortran
From: pmontgom@math.orst.edu (Peter Montgomery)
Subject: CDC rounding (was: The Cray fails arithmetic test?)
Organization: Oregon State University Math Department
Distribution: usa
Date: Tue, 13 Oct 1992 17:15:15 GMT

In article <b!np-5-@lynx.unm.edu> john@aquarius.unm.edu (John Prentice) writes:

>One shocking thing was that the same code, run on the same type of CDC computer
>but at different installations, would give very different results.  Different
>to the extent that with one compiler, you would see rod failure, with another,
>you wouldn't.  The source of the discepencies was that different installations
>had set different compiler defaults for how to handle rounding.  Kinda spooky.
>Whether this was all due to poor numerics that let the errors grow unreasonably
>fast or something physical about the nature of reactor fuel rod failure (i.e.,
>chaos), I haven't a clue.  I would certainly first consider just bad numerics,
>but I can also cite very simple physical systems which would exhibit the same
>behavior due to chaos.  Either way however, these are good examples of the need
>to consider error propagation and growth in numerical methods and to be
>concerned about computer arithmetic.

        CDC's FTN compiler allowed one to choose rounding or not on the
compiler line.  As a CDC systems programmer, I often compiled programs
both with and without rounding, or with and without optimization.
If results differed, then I could save both object (LGO) files.
Subsequently I would mix subroutines from one
compilation with subroutines from the other, determining
which half of the code had the guilty module
(assuming only one is responsible).  A binary search would
isolate the trouble maker, after which a study of the algorithm
or of the compiler-generated code would often pinpoint the problem.
For example, one might be estimating a derivative as

        f(x + h) - f(x)
        --------------
                h

where h is too small; using

        f(x + h) - f(x - h)
        -------------------
                 h

with larger h might give better results.
Or one might be using J = INT(0.1*FLOAT(I)),
a dangerous way to divide I by 10.

        Today's systems often use one call to specify
the rounding mode for subsequent IEEE operations rather
than having the rounded mode embedded into the instruction.
Putting the rounding mode directly into the instruction
(as CDC did) allows such debugging, and (with compiler support)
allows source programs to mix operations with different
roundings, such as when doing interval arithmetic.

-- 
        Peter L. Montgomery              Internet: pmontgom@math.orst.edu
        Dept. of Mathematics, Oregon State Univ, Corvallis, OR 97331-4605 USA
``Who do you trust?''  Those whom I trust know English spelling and grammar.
Our economy needs more business, not more Bushiness.
From: bigelow@hpfcso.FC.HP.COM (Jim Bigelow)
Date: Wed, 14 Oct 1992 22:05:42 GMT
Subject: Re: For HP and IBM RISC hosts, how to get cpu times from Fortran?
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.lang.fortran

In comp.lang.fortran, theld@udecc.engr.udayton.edu (Thomas W Held (S)) writes:

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

Try libU77 routine etime (elapsed execution time of calling process) available
with the 9.0 Series 700 compiler.  For earlier version of the complier try
accessing the system call "times"

Jim Bigelow
Hewlett Packard
Ft. Collins CO

Do not take my opinions to be those of HP.
From: khb@chiba.Eng.Sun.COM (chiba)
Newsgroups: comp.lang.fortran
Subject: Re: Writing COMPLEX numbers: need help.
Date: 16 Oct 92 10:24:36
Organization: Sun MegaSystems
NNTP-Posting-Host: chiba
In-reply-to: phd85@keele's message of 16 Oct 92 12:39:37 GMT


>....complex write ....

The code provided runs fine with f77v2.0.1 and f77v1.4. While you
identified the OS, you did not identify the compiler release.

It sounds like the problem may be installation specific, so let's do
the followup offline.
--
----------------------------------------------------------------
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: hehmsoth@rrzn.uni-hannover.dbp.de (Hans-Heinrich Hehmsoth)
Subject: Re: The Cray YMP fails paranoia arthmetic test?!
Organization: Regionales Rechenzentrum fuer Niedersachsen
Distribution: usa
Date: Mon, 12 Oct 1992 12:21:59 GMT

In article <1992Oct9.192344.14347@leland.Stanford.EDU> ungar@leland.Stanford.EDU (Jeffrey Ungar) writes:
>From: ungar@leland.Stanford.EDU (Jeffrey Ungar)
>Subject: The Cray YMP fails paranoia arthmetic test?!
>Date: Fri, 9 Oct 92 19:23:44 GMT
>While testing a Monte Carlo program recently, I uncovered what appeared
>to be huge inconsistencies between the results calculated in a short
>run on a 486 PC and those calculated for the same test data on the Cray.
>To make matters more confusing, the results calculated on an RS/6000
>were different from both of these runs. All sorts of nightmares came
>to mind, such as wild pointers (this was a combined C-F77 program), etc.
>
>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?
>
>Jeff Ungar
>--------------------------------------------------
>"I usually don't expect this sort of behavior from
> a major appliance" -- B.M. in Ghostbusters


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hans-Heinrich Hehmsoth           voice: +511 762 5136
RRZN                             fax  : +511 762 3003
Schlosswender Str. 5             email: hehmsoth@rrzn.uni-hannover.dbp.de
3000 Hannover 1           
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Newsgroups: comp.lang.fortran
From: lau@hydra.rose.brandeis.edu ()
Subject: Need HELP for 'backspace' problem in Watcom/os2
Organization: Brandeis University
Date: Fri, 9 Oct 1992 21:26:33 GMT

During the port of a large FORTRAN program that runs under Unix and
VMS to OS/2 2.0 I ran into a problem with the BACKSPACE command.  The
compiler used is WATCOM FORTRAN 9.01, patchlevel b.

Sometimes the BACKSPACE statement rewinds the file instead of what it
is supposed to do.  Unfortunately, I am unable to reproduce the
problem in a simple testcase.  WATCOM told me that a known bug with
the BACKSPACE command has been fixed in the patchlevel we have.  The
only thing I am sure of is that it is the BACKSPACE statement that
causes the problem:

       bla,bla !some 100000 lines of code
csbdeb
       read(unit,'(a80)') line  ! so I know where we are in 'unit'
       write(6, '(a80)')  line  ! - exactly where I think we are
csbdeb
       backspace(unit=unit)
csbdeb
       read(unit,'(a80)') line  ! where are we now?
       write(6,'(a80)')   line  ! beginning of file, no wonder we bombs out
csbdeb
      bla,bla  !some more 100000 lines of code

It would be very helpful to know whether any one has experienced
similar problems with the WATCOM compiler and / or with the operating
system.  Alternatively, does anyone have FORTRAN code that uses the
BACKSPACE statement extensively, yet is short enough that I could try
building it into a testcase.

Thanks in advance for any help

Please post AND email lau@tammy.harvard.edu or boresch@tammy.harvard.edu

-Frankie
Newsgroups: comp.lang.fortran
From: rvenable@helix.nih.gov (Richard M. Venable)
Subject: Re: home directory in unix
Keywords: getenv getarg
Reply-To: rvenable@helix.nih.gov (Richard M. Venable)
Organization: National Institutes of Health
Date: Fri, 9 Oct 1992 18:55:39 GMT

Try getting rid of the '2X' in the format statement for the internal read;
most implementations won't tolerate leading blanks in a string used as a
parameter for FILE=, whether it's in an OPEN or an INQUIRE statement.

BTW, there's a minor bug in my posting; I neglected to remove the '~' char.
From: reid@ss6.cps.msu.edu (Dr Richard J. Reid)
Newsgroups: comp.lang.fortran
Subject: Fortran Usage in CS1?
Date: 8 Oct 92 13:57:36 GMT
Organization: Department of Computer Science, Michigan State University
Originator: reid@ss6.cps.msu.edu


Among the 253 schools that have responded to our survey, the
following have indicated they are using

Fortran

in their CS1 course.

Do you know of any additions or corrections?

Thanks,

Dick

*************************** Fortran ********************************

Colorado School of Mines
Colorado Technical College (FORTRAN and Karel)
Indiana-Purdue, Indianapolis
Penn State (If entering through College of Engineering)
Rutgers, Camden
University of Benin, Nigeria
Newsgroups: comp.lang.fortran
From: urjlew@ecsvax.uncecs.edu (Rostyk Lewyckyj)
Subject: Re: The Cray YMP fails paranoia arthmetic test?!
Organization: UNC Educational Computing Service
Distribution: usa
Date: Sat, 10 Oct 1992 00:36:25 GMT

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


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: Tue, 13 Oct 92 06:36:27 GMT

In article <1992Oct12.230317.22480@craycos.com> jrbd@craycos.com (James Davies) writes:
>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 ;-)

Ahem. If the results from a MC program are statistically equivalent, then
they are THE SAME! On the other hand, if the individual samples are different
on different computers, it can still make your blood run cold. After all,
*why* is it happenning? It didn't do this before!

When I test the program, I select the random number seed value so that I
can reproduce individual calculations to make sure any new modifications
haven't screwed them up. It never makes sense to randomize the seed value
when testing, (or whenever the number of runs is small).

To avoid more helpful comments :-) here was the test:

    if ( de<0 || random(&idum)<exp(-de/kT) ) { ....

For a typical MC simulation on a system with a continuous configuration
space, de==0 would be, shall we say, *rare*. However, I introduced some
constraints that would hold some particles fixed by setting the trial
displacement to zero, which meant de==0 for some steps [1]. The 486
machine got zero; the Cray got -1e-13. One called random(), the other 
did not, but both accepted the step. Subsequent steps began to look
quite different even though the same distribution is generated.
The revised code is

   if ( random(&idum)<exp(-de/kT) ) { .... (no penalty for my application)

If I had not noticed that the samples were different, there would
be no harm done. I did notice it, and I can't let sh*t like that go
by without understanding what the problem is (was). Otherwise, why 
would I ever have confidence in my calculations? (not that I don't 
have gnawing doubts :-)

[1] The way the program calculates de makes it quite a mystery that
    any computer would find de!=0 for these cases, but I haven't looked
    into it in detail---it's no longer important to me.

Jeff Ungar
------------------------------------------------------------------
"A foolish inconsistency is the hobgoblin of Cray computers."-- me
           ...but at least the damn thing is fast...
From: sasdzr@borel.unx.sas.com (David F. Ross)
Newsgroups: comp.lang.fortran
Subject: Fortran and RPC
Date: 8 Oct 92 18:09:09 GMT
Organization: SAS Institute Inc.
Originator: sasdzr@borel.unx.sas.com


Is it possible to use RPC (Remote Procedure Calls) with Fortran?  
Can anyone suggest a paper to read on this subject?

Thanks,
David
-- 
-------------------------------------------------------------------------------
David Ross   				SAS Institute, Inc.
(919)677-8000x7136 			sasdzr@unx.sas.com

"I looked up the word 'Basketball Player' in the dictionary and you know what
it said?  NOT YOU." - Sydney, White Men Can't Jump
-------------------------------------------------------------------------------
Newsgroups: comp.lang.fortran
From: lionel@quark.enet.dec.com (Steve Lionel)
Subject: Re: Mutiplication with character constants
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH
Date: Fri, 16 Oct 92 16:43:42 GMT


In article <9080042@hpfcso.FC.HP.COM>, bigelow@hpfcso.FC.HP.COM 
(Jim Bigelow) writes:
|>
|>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
|>

This "feature" is present in many compilers and is for compatibility with
FORTRAN-66 which did not have type CHARACTER.  Consider the character constant
to be treated, in a numeric context, as if it were a Hollerith constant.  What
gets used is the bits you get from the ASCII characters, blank-padded if
necessary.  I admit that you'd probably prefer that this NOT work, but
there are still an awful lot of "dusty deck" FORTRAN-66 programs out there
and compiler developers have been necessarily accomodating to them.
--

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: prener@watson.ibm.com (Dan Prener)
Subject: Re: For HP and IBM RISC hosts, how to get cpu times from Fortran?
Date: Mon, 12 Oct 1992 07:40:02 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center, Hawthorne, New York

In article <BvzBHq.Ap6@udecc.engr.udayton.edu> theld@udecc.engr.udayton.edu (Thomas W Held (S)) writes:

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

For the IBM RS/6000, look at the routine MCLOCK() in the FORTRAN (xlf)
documentation.  It returns CPU time in units of 1/100 second.
--
                                   Dan Prener (prener@watson.ibm.com)