HDTenEightyP/NetNews huggingface dataset:
From: stryk@Mathematik.TU-Muenchen.DE (Oskar von Stryk)
Subject: Licence for Minpack subroutines
Originator: stryk@sunbulirsch6.mathematik.tu-muenchen.de
Organization: Technische Universitaet Muenchen, Germany
Date: Mon, 23 Nov 1992 15:35:54 GMT


Does anybody know

 + how to get a licence for a commercial usage of the Minpack subroutines
   (written by B.S.Garbow, K.E.Hillstrom, J.J.More, Argonne National Laboratory)
   and
 
 + how much it will cost?

Any help or advice is greatly appreciated!

    Oskar

P.S. I'm posting for a colleague from industry.
+-----------------------------------------------------------------------------+
|  Oskar von Stryk                     stryk@mathematik.tu-muenchen.de        |
|  Mathematisches Institut                                                    |
|  Technische Universit"at             FORTWIHR - The Bavarian Consortium on  |
|  P.O.Box 20 24 20                    High Performance Scientific Computing  |
|  D-W-8000 M"unchen 2, Germany                                               |
+-----------------------------------------------------------------------------+
Newsgroups: comp.lang.fortran
From: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Subject: Re: 3d to 2d mapping
Reply-To: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Organization: MRL - UIUC
Distribution: na
Date: Thu, 19 Nov 1992 01:05:13 GMT

In article <BxxnCt.5M0@cs.dal.ca>, glenn@ug.cs.dal.ca (Glenn McCarville) writes:
|>I want to take a 3 dimensional array and map it onto a 2d array.
|>i.e. Set B(i,j)=A(x,i,j) for all i,j and x is some constant. Can this
|>be done easily? 

the easiest way, if you can do it, is to transpose the array so as
to have the constant index in the last position.

then you can
	call blas_routine(A(1,1,x),...)
where blas_routine expects a 2d array.

in fact, what is passed to the routine is the address of the specified
element of the array, which the routine takes as starting address.
data are stored in columnwise order, so this does exactly what you
want.

if you cannot reorder the indexes, i'm afraid you have to copy
the data into a temporary subarray. 

furio  
--
Furio Ercolessi
Materials Research Laboratory           |   Intl School for Advanced Studies
Univ. of Illinois at Urbana-Champaign   |   Trieste, Italy
furio@uiuc.edu                          |   furio@sissa.it
From: dodd@mycenae.cchem.berkeley.edu (Lawrence R. Dodd)
Newsgroups: comp.lang.fortran
Subject: Re: Legal optimization?
Date: 22 Nov 92 06:56:07
Organization: Dept of Chemical Engineering, Polytechnic Univ, NY, USA
Reply-To: dodd@roebling.poly.edu
NNTP-Posting-Host: mycenae.cchem.berkeley.edu
In-reply-to: iversen@dsfys1.fi.uib.no's message of Sat, 21 Nov 92 11:41:31 GMT


>>>>> "Per" == Per Steinar Iversen <iversen@vsfys1.fi.uib.no> writes:

  Per> One of the students here uses VAX FORTRAN to calculate various things for his
  Per> thesis. Recently he had some problems, which were traced down to a real bug.
  Per> However: A result of the bug was that a square root of a negative REAL occurred.
  Per> Yet this never made the program crash! When either a WRITE statement was 
  Per> inserted on the next line after the SQRT or the optimization was turned off,
  Per> then the program crashed properly... Presumably the optimizer transforms the
  Per> code into something which is OK if the values are *not* negative. At least in 
  Per> this program however the results were just garbage if the negative root occurred.

  Per> The compiler is VAX FORTRAN V5.8-155 under VMS 5.5. So far I always felt safe
  Per> if my programs compiled and ran with 
  Per> FORTRAN/CHECK=ALL/STANDARD=ALL/WARNING=(GENERAL,DECLARATIONS), but I guess I
  Per> should add /NOOPTIMIZE too.

  Per> My question is more philosophical perhaps: Are such transformations of the 
  Per> code actually legal, is the compiler performing within the standard?

Welcome to the world of code optimization!  I don't think that the standard
has any meaning once the optimizer has gotten hold of it. Rule: the optimizer
is only as good as the person that wrote it. Some of them are damn good.  Most
are good at local 10-20 line optimization.  It is when higher level
optimization (i.e., so-called global optimization and inlining) is attempted
that things can go wrong.

Two things that I do to stop the optimizer from screwing me:

  (1) compile and run with and without the optimizer -- obviously, the results
      should be identical -- with unix f77 this can be done with -g typically
      without any -O[1234].

  (2) Keep sub-programs small. This lessens the chance of the optimizer from
      assuming too much.  

I used VMS for five years and discovered no real `bugs' in the optimizer but
with Sun's f77 compiler I have come across three situations (in three years)
where the optimizer produced bad code and in one case code that would crash my
machine.  The addition of one innocuous line to a working subroutine would
cause havoc.

The solution in all three cases was to break up one of the subroutines into a
set of smaller routines.  In general, this is good programming practice but
also helps the optimizer from becoming too cavalier with my code :-)
Newsgroups: comp.lang.fortran
From: jim@accelr8.com (Jim Reiss)
Subject: Fortran to C issues?
Organization: Accelr8 Technology Corporation
Date: Mon, 16 Nov 1992 17:28:33 GMT

In some computation-intensive environments there seems to be a general
feeling that FORTRAN is much better than C for some tasks.  I shudder to
be asking this because rekindling the C/FORTRAN flame war is not what
I want to do...but...is there a good basis for that opinion, and does that
mean that FORTRAN to C translators like f2c and the NAG FORTRAN compiler
are inherently inferior to a FORTRAN to machine language compiler?  If so,
please explain why.  Please try to keep answers from degenerating into
"so there" and religious style comments.  Thank you.
-- 
 Jim Reiss (jim@accelr8.com)    Accelr8 Technology, Denver, Colorado, USA
 Opinions expressed above are mine.  Who else would have them?
From: mcn@eng.cam.ac.uk (M.C. Nowell)
Newsgroups: comp.lang.fortran
Subject: Writing output to MATLAB format
Date: 15 Nov 92 18:01:41 GMT
Organization: cam.eng

Hi,

I am trying to output the data from my fortran program into the MATLAB
format. MATLAB supplies a fortran routine which does this but states
that it doesn't work for the Lahey compiler (which I am using). Has
anyone ever had the desire or need to do this and if so were they
successful and how? Any ideas why the code MATLAB supplies will work
for most compilers except Lahey and a few others?

Thanks in advance for any help,

Mark Nowell
mcn@uk.ac.cam.eng
Newsgroups: comp.lang.fortran
From: dedmunds@selkirk.sfu.ca (Darran Edmundson)
Subject: a question on ATAN function
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Mon, 23 Nov 1992 19:50:28 GMT

I'd like to pose a neophyte question on using the arctan function to
calculate the phase angle of a complex variable (i.e. \theta = atan(v/u)
where u and v are the real and complex parts of my imaginary number
respectively).  Is it sufficient to test for u=0 (i.e. \theta = \pm \pi)
to avoid problems?  What happens if the ratio exceeds range allowed
for doubles or reals?  How do you avoid this problem?

(Now that I think about it, is it better to use arcsin or arccos?)

Thanks for you help.

-- 

Darran Edmundson
darran@chaos.phys.sfu.ca

Newsgroups: comp.lang.fortran
From: alf@tpki.toppoint.de (Alfred Mechsner)
Subject: WANTED : precision test of runtime library
Organization: Toppoint Mailbox e.V.
Date: Sun, 15 Nov 1992 11:08:15 GMT

Hi,

I am looking for a FORTRAN program, which is able to test and check
the precision and the validity range of a FORTRAN - runtime library.

My problem is, that I have to check a runtime library, whether it
will produce under all circumstances and events a "correct" result.

Maybe there exist some source, which will help me in doing the job,
so I would be glad, if someone could give me an hint, where to get it.


Please e-mail to  :  alf@tpki.toppoint.de

Thanks for Your help.

-- 
Alfred Mechsner		alf@tpki.toppoint.de
2300 Kiel 1
From: l@chiron.astro.uu.se (Lars Kamel)
Newsgroups: comp.lang.fortran
Subject: Re: extra 8 bytes
Date: 18 Nov 1992 08:28:33 GMT
Organization: Uppsala University
Distribution: world
NNTP-Posting-Host: chiron.astro.uu.se

In article <1992Nov17.200054.22236@newshost.lanl.gov>, jlg@cochiti.lanl.gov (J. Giles) writes:
|> In article <1e8i03INNecd@corax.udac.uu.se>, l@chiron.astro.uu.se (Lars Kamel) writes:
|> |> I have had the same problem when programming on a VAX/VMS system. Based on
|> |> my expirence, I propose that you change your code to (if your compiler
|> |> allows it):
|> |>       open( 10, file=file1, form='unformatted', recordtype='fixed',
|> |>      +          access='direct', recl=1000)
|> |>       write( 10, rec=1) (real(i),i=1,1000)
|> 
|> Please not that the above conforms to the standard with two exceptions:
|> 
|> 1) the `recordtype' specifier is not standard
|> 
|> 2) technically, the standard only accepts upper case letters ;-)
|> 
|> On most implementations, you can use lower case. On most applications,
|> the record length information is not written to disk for direct access
|> files.  Few implementations hav the recordtype specifier.
|> 
|> Note that a standard conforming implementation is not *required* to
|> omit the record length marks for direct access files.  It's just that
|> most of them do.  If yours doesn't, you'll have to write a non-Fortran
|> filter to get rid of them after Fortran is done.
|> 
|> This subject *should* be covered in the FAQ for this newsgroup.  So
|> far I've not seen one consistently posted though.
|> 
|> -- 
|> J. Giles

1) I did not remember what is standard and what is VAX extensions. Perhaphs
it works without the recordtype specifier, if the compiler doesn't support it.

2) Of course, if your compiler is case-sensitive, use only capital letters.

3) I realize that I forgot to multiply with the four bytes/element. The
recordlength should be specified as RECL=4000.

Lars Kamel (lars@laban.uu.se)
Newsgroups: comp.lang.fortran
From: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Subject: Re: How does one return a logical value...???
Reply-To: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Organization: MRL - UIUC
Date: Thu, 19 Nov 1992 20:10:41 GMT

In article <kf2iy2_00YUo8INXQF@andrew.cmu.edu>, "Bruno W. Repetto" <br0w+@andrew.cmu.edu> writes:
|>You should have the following in your calling (sub)program:
|>
|>       logical CheckActivity
|>.
|>.
|>.
|>         IF (CheckActivity(previous, ROWS, COLS) .EQ.  .TRUE.) THEN
|>           uncontrol = uncontrol + 1
|>         ENDIF

while the declaration certainly has to be there, one also has to use .EQV.
instead of .EQ. as already pointed out in this thread.

but now i was wondering why the writers of the standard 
defined these new operators, .EQV. and .NEQV.
to a first sight, it seems that overloading .EQ. and .NE. should be
possible: the compiler would select the operator by looking at the
operands.  Just as .GT. works for both integer and floats.
Yet, if they did it this way there is probably a good reason.
Does anybody know why?

--
Furio Ercolessi
Materials Research Laboratory           |   Intl School for Advanced Studies
Univ. of Illinois at Urbana-Champaign   |   Trieste, Italy
furio@uiuc.edu                          |   furio@sissa.it
Newsgroups: comp.lang.fortran
From: ejh@khonshu.colorado.edu (Edward J. Hartnett)
Subject: really weird compiler hang!
Organization: CIRES, University of Colorado
Date: 19 Nov 92 09:26:32


This is really a weird one! I had this subroutine that I was trying to
compile this subroutine and it kept hanging in the compile! Here's
what a pared it down to. If I take out the date = ... line, I get tons
of erros of course (since I cut out all the declarations, etc.) but if
I leave it in and compile the following (with a -c to create an object
file but suppress linking) the compiler gets stuck!



      subroutine get_days(LU, h, typenum, filein)
ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
c
      implicit none
c
      structure /cond_samp_hdr/
         integer data_rate, num_chan, num_ind_val
         integer start_jday, stop_jday
         real start_time, stop_time
         character*80 data_type
         character*80 set_name
         character*100 comment1, comment2, comment3
         character*100 reserved
      end structure
c
      record /cond_samp_hdr/ h
c
      date = h.set_name(lnblnk(h.set_name)-7:lnblnk(h.set_name))
      end


Here's what make gives me:
cd /home/khonshu/ejh/cond_samp/atob_src/
f77 -c -e test.f
test.f:
	get_days:


Can anyone explain this bizarre behavior? I'm running this on a Sun
IPC, running 4.1.1, using the Sun fortran compiler.
--
Edward Hartnett			ejh@khonshu.colorado.edu
From: zagar@chester.cms.udel.edu (Randy Zagar)
Subject: Re: extra 8 bytes
Reply-To: zagar@chester.cms.udel.edu
Organization: Marine Studies, University of Delaware
Date: Mon, 23 Nov 1992 17:22:23 GMT

As has been previously mentioned, the extra 8 bytes at
the beginning of your file is record length information.

THIS IS BECAUSE YOUR COMPILER DEFAULTS TO A SEQUENTIAL
ACCESS MODE IF YOU DON'T SPECIFY OTHERWISE.

To really fix your problem, you need to pick a record length
for your I/O to the file and use ACCESS='DIRECT' and RECL=####
in your open statement.  For more info, please check your local
F77 docs for direct access I/O.

I've used this technique several times under different UNIX Fortrans
and have had no problems.  Files written in this way by F77 apps. *can*
be read by C-lang. applications w/ no problems.

-Randy



---

 ____________________________________________________________________________
/                                                                            \
| Randy Zagar                                 Thinking: that waste of time   |
| Internet: zagar@Chester.CMS.UDel.Edu        between seeing something and   |
| Bell-net: 302/831-1139                      knowing what to do about it.   |
\____________________________________________________________________________/


Newsgroups: comp.lang.fortran
From: stryk@Mathematik.TU-Muenchen.DE (Oskar von Stryk)
Subject: Licence for Minpack subroutines
Originator: stryk@sunbulirsch6.mathematik.tu-muenchen.de
Organization: Technische Universitaet Muenchen, Germany
Date: Mon, 23 Nov 1992 15:28:05 GMT


Does anybody know

 + how to get a licence for a commercial usage of the Minpack
   subroutines (written by B.S.Garbow, K.E.Hillstrom and J.J.More,
   Argonne National Laboratory) and

 + how much it will cost?

Any help or advice is greatly appreciated!

Thanx a lot!
               Oskar

P.S. I'm posting for a colleague from industry.

+-----------------------------------------------------------------------------+
|  Oskar von Stryk                     stryk@mathematik.tu-muenchen.de        |
|  Mathematisches Institut                                                    |
|  Technische Universit"at             FORTWIHR - The Bavarian Consortium on  |
|  P.O.Box 20 24 20                    High Performance Scientific Computing  |
|  D-W-8000 M"unchen 2, Germany                                               |
+-----------------------------------------------------------------------------+
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: Fortran to C issues?
Organization: Los Alamos National Laboratory
Date: Mon, 16 Nov 1992 21:56:07 GMT

In article <BxtKJL.2Ir@accelr8.com>, jim@accelr8.com (Jim Reiss) writes:
|> In some computation-intensive environments there seems to be a general
|> feeling that FORTRAN is much better than C for some tasks.  I shudder to
|> be asking this because rekindling the C/FORTRAN flame war is not what
|> I want to do...but...is there a good basis for that opinion, and does that
|> mean that FORTRAN to C translators like f2c and the NAG FORTRAN compiler
|> are inherently inferior to a FORTRAN to machine language compiler?  If so,
|> please explain why.  Please try to keep answers from degenerating into
|> "so there" and religious style comments.  Thank you.

C fails to have any means of expressing the concept that two array
arguments to a procedure are *not* aliased.  This inherently inhibits
optimization on *most* C implementations compared to native Fortran
compilation.  It is true that very modern, time consuming, experimental
compilation techniques can overcome this difficulty (by eliminating
separate compilation - so the compiler can analyze interprocedural
relationships; by having the loader do the last phases of what's
normally considered compilation - so the code generation can occur
*after* an interprocedural analysis even *with* separate compilation; 
or by providing non-C extensions which permit the aliasing information
to be expressed to the compiler).  None of the Fortran to C translators
you mention have any facilities - within themselves - to address this
issue.

Problems involving the translation of onn language to another are
always a result of semantic content of one language's features
not being *directly* representable (if at all) in the other language.
There are other examples of this between Fortran and C, but probably
none so important.  I/O emulation is probably the worst problem other
than aliasing - and I suspect it's a fairly distant second.

-- 
J. Giles
Newsgroups: comp.lang.fortran
From: map@hal.maths.monash.edu.au (Michael Page)
Subject: Re: Jumping from nested subroutine to main directly?
Organization: Mathematics Department, Monash University, Australia
Date: Sat, 21 Nov 1992 22:27:05 GMT

ags@seaman.cc.purdue.edu (Dave Seaman) writes:
>>
>== John H. Chauvin <jchauvin@netcom.com> writes:
>>
>>  Is it possible to transfer control from a nested subroutine directly to the 
>>  main routine without have to execute multiple returns from all the 
>>  subroutines in between?  I would like a way of exiting directly to the main 
>>  routine when a error is detected six or seven subroutines down.
>
>Write a subroutine to do whatever final cleanup is needed. Have
>the main program end with a call to the cleanup routine. Have the
>cleanup routine finish with a STOP statement, so that it never
>returns to the main program.
>
>Now, when an error is detected and you want to bail out, you can
>just call the cleanup routine, knowing it will never return. You
>can even have the routine take an error argument to indicate the
>reason for termination, and have the cleanup take appropriate
>action.

One way to almost do what he wants is to use an ENTRY statement at the 
point he wants to return to in the main program.  However, I suspect he 
wants something a bit more `automatic' than that, but I don't think it 
exists in FORTRAN.  Does it exist in C, Pascal, ..?

(Which also prompts me to ask why the ENTRY statement is so frowned upon 
that it is now deprecated?  Is it superceded by something else?)


--
+------------------------------------------------------------------------------+
 Michael Page, Maths Dept, Monash University, Clayton, Victoria, AUSTRALIA 3168
  email: map@hal.maths.monash.edu.au phone: +61 3 565 4486 FAX: +61 3 565 4403
+------------------------------------------------------------------------------+
Newsgroups: comp.lang.fortran
From: map@hal.maths.monash.edu.au (Michael Page)
Subject: Re: ENTRY in main (was re: Jumping from nested subroutine)
Organization: Mathematics Department, Monash University, Australia.
Date: Mon, 23 Nov 1992 11:48:07 GMT

(bryan d oakley) writes:
>>== Michael Page writes:
>> One way to almost do what he wants is to use an ENTRY statement at
>> the point he wants to return to in the main program.  However, I
>> suspect he wants something a bit more `automatic' than that, but I
>> don't think it exists in FORTRAN.  Does it exist in C, Pascal, ..?
>
> Hmmm... I've been programming FORTRAN for 10ish years (if you count
> college) and NEVER thought to put an ENTRY in the main program,
> though at first glance it seems to be the only time I might consider
> using an ENTRY point (yes, I'm one of the people that frowns :-( on
> the use of ENTRY points).
>
>Question: what does this do to the stack?  If you kept jumping back to
>the main routine everytime you had an error, and never 'returned' from
>the routine causing the error, wouldn't the stack just grow un-
>controllably?  

After I posted, I had this vague recollection that ENTRY could only be 
used in subroutines.  But even if this were true the original author's 
requirement could be simulated by having an entry statement at the end 
of each "level one" subroutine, say called "ENTRY exit<subname>".  I
must confess that the only thing I have ever used ENTRY statements for
is error handling.  (My fatal error messages are all printed out from
a single subroutine with multiple entry points, to avoid cluttering the
code where the error occurs.)

ENTRY statements are a form of global GOTO statement and, much as I
detest and discourage GOTOs, they do have an occasional application,
in particular for error handling.  I'm not encouraging their use but
they do seem to have a place in the language.

> Also, wouldn't this be considered recursion, since a routine subordinate 
> to main (effectively) calls main?  

Recursion is already possible (and legal?) in standard FORTRAN by simply 
having two subroutines which are different only in name that call each 
other.  I have no idea what this does to the stack, though.

--
+------------------------------------------------------------------------------+
 Michael Page, Maths Dept, Monash University, Clayton, Victoria, AUSTRALIA 3168
  email: map@hal.maths.monash.edu.au phone: +61 3 565 4486 FAX: +61 3 565 4403
+------------------------------------------------------------------------------+
Newsgroups: comp.lang.fortran
From: dnl@convex.is.macsch.com (David Lombard)
Subject: Re: How does one return a logical value...???
Organization: MacNeal-Schwendler Corp.
Date: Fri, 20 Nov 92 21:03:24 GMT

In article <BxzC1x.n0s@news.cso.uiuc.edu> ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi) writes:
>In article <kf2iy2_00YUo8INXQF@andrew.cmu.edu>, "Bruno W. Repetto" <br0w+@andrew.cmu.edu> writes:
>
>but now i was wondering why the writers of the standard 
>defined these new operators, .EQV. and .NEQV.
>to a first sight, it seems that overloading .EQ. and .NE. should be
>possible: the compiler would select the operator by looking at the
>operands.  Just as .GT. works for both integer and floats.
>Yet, if they did it this way there is probably a good reason.
>Does anybody know why?
>

The following statement is fairly clear:

	IF( A.EQ.B .EQV. C.EQ.D ) ...

What would you do with this phantom?

	IF( A.EQ.B .EQ. C.EQ.D ) ...

Regards,
DNL

                 MY_COMMENTS = MY_OPINIONS = NOBODY_ELSES;

David N. Lombard    The first thing we do,         The MacNeal-Schwendler Corp
dnl@macsch.com      Let's kill all the lawyers.    815 Colorado Blvd
(213) 259-4911      II Henry VI, IV.ii             Los Angeles, CA  90041
Newsgroups: comp.lang.fortran
From: katragad@risky.ecs.umass.edu (Prasanna B Katragadda)
Subject: Fortran debugger on UNIX/ULTRIX..??????? 
Keywords: Fortran,Debugger
Organization: University of Massachusets, Amherst
Date: Fri, 20 Nov 1992 16:39:28 GMT

Can anybody give me info on FORTRAN debuggers on UNIX or ULTRIX....

Please reply to katragad@ecs.umass.edu

Thanks.


Newsgroups: comp.lang.fortran