Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watdcsu.UUCP
Path: utzoo!watmath!watnot!watdcsu!herbie
From: herbie@watdcsu.UUCP (Herb Chong - DCS)
Newsgroups: net.lang
Subject: Re: What language do you use for scientific programming?
Message-ID: <1612@watdcsu.UUCP>
Date: Fri, 16-Aug-85 10:49:31 EDT
Article-I.D.: watdcsu.1612
Posted: Fri Aug 16 10:49:31 1985
Date-Received: Sun, 18-Aug-85 05:32:30 EDT
References: <909@oddjob.UUCP> <163@ho95e.UUCP> <367@ttrdc.UUCP>
Reply-To: herbie@watdcsu.UUCP (Herb Chong - DCS)
Organization: U of Waterloo
Lines: 52
Summary: 

In article <367@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
>In article <163@ho95e.UUCP>, wcs@ho95e.UUCP (x0705) writes:
>>I find the biggest
>>weaknesses fortran has for scientific programming are:
>>	- no recursion - makes everything tough, especially multiple integration
>
>I was under the impression that Fortran-77 allows recursion in the sense that
>a routine may call itself either directly or through a chain of other routines-
>am I mistaken?

the fortran 77 standard does not disallow recursion.  whether the
particular implementation allows it is up to the implementor.  almost
all, if not all, fortran 77 compilers for IBM systems do not allow it
and fail for mysterious infinite loops when written assuming
recursion.

>>	- no dynamically dimensioned arrays ( though C is kind of clumsy also)
>
>True in the general case--some operating systems (like VMS) provide extensions
>which allow dynamic memory allocation (is this what is being referred to?).

runtime dimensioning of subroutine parameters is allowed, which is fine
provided that you are using almost all the storage allocated all time.
a general way of dynamically allocating storage is messy to fit into
the fortran 77 language without making major changes in its design
philosophy.  you need an implicit pointer type or an explicit one, both
of which make the language implemented nonstandard.  there are ways of
getting around this, but no implementation i have seen really is
satisfactory.

>>	- clumsy input, though this is less important for scientific prog.
>
>Amen, brother.  Can't take input as a stream of bytes, for instance.

the whole fortran I/O design is based upon the record concept.  a
stream of bytes has no place in such a structure.  the semantics of a
read or write need to be changed to accomodate a byte stream, or by
taking the PL/I approach of separate statements in the language for
stream and record I/O.  a third possible way is to have both stream and
record oriented I/O routines which are implemented as one underlying
set of I/O routines as in the C runtime library.  any of the above ways
requires an extension to the fortran 77 language standard or
implementing a nonstandard compiler.

Herb Chong...

I'm user-friendly -- I don't byte, I nybble....

UUCP:  {decvax|utzoo|ihnp4|allegra|clyde}!watmath!water!watdcsu!herbie
CSNET: herbie%watdcsu@waterloo.csnet
ARPA:  herbie%watdcsu%waterloo.csnet@csnet-relay.arpa
NETNORTH, BITNET, EARN: herbie@watdcs, herbie@watdcsu