Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site ttrdc.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!harpo!whuxlm!whuxl!houxm!ihnp4!mgnetp!ltuxa!ttrdc!levy From: levy@ttrdc.UUCP (Daniel R. Levy) Newsgroups: net.lang Subject: Re: What language do you use for scientific programming? Message-ID: <371@ttrdc.UUCP> Date: Mon, 19-Aug-85 01:57:51 EDT Article-I.D.: ttrdc.371 Posted: Mon Aug 19 01:57:51 1985 Date-Received: Fri, 23-Aug-85 06:51:02 EDT References: <909@oddjob.UUCP> <163@ho95e.UUCP> <367@ttrdc.UUCP> <1612@watdcsu.UUCP> Organization: AT&T, Computer Systems Division, Skokie, IL Lines: 62 In article <1612@watdcsu.UUCP>, herbie@watdcsu.UUCP (Herb Chong - DCS) writes: >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. I plead very guilty to my ignorance in saying that. Someone else also flamed me for this. I presume this adds to the number-crunching efficiency when recursion is disallowed since there would need be no provision for stuffing the old variables on the stack and reinitializing them upon calling an already called procedure, and restoring them when the call returns. Unix f77 and (I believe) VMS Fortran allow for this. >>> - 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 >... >requires an extension to the fortran 77 language standard or >implementing a nonstandard compiler. > Actually, Unix' f77 allows byte input to be done on any file which can be seeked upon--you do something like character abyte integer n open(unit=1,file='foo.bar',access='direct',form='unformatted', + recl=1) n=[whatever] read [write] (unit=1,rec=n,err=nnn)abyte but this will bomb on a system like VMS when the type of file you are trying to input from (output to) was created with a different structure. It is also impossible to do this on terminal I/O, or on standard input/output. It would be nice if you could mix different types of access with different file struc- tures and have the I/O routines deal with this in a sane manner. Then you could have your bytes and eat them too :-). >Herb Chong... -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer, my pets, my plants, my boss, or the | at&t computer systems division | s.a. of any computer upon which I may hack. | skokie, illinois | | "go for it" | Path: ..!ihnp4!ttrdc!levy -------------------------------- or: ..!ihnp4!iheds!ttbcad!levy