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