ok@quintus.UUCP (Richard A. O'Keefe) (03/23/88)
In article <10037@steinmetz.steinmetz.ge.com>, davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr) writes: > The arithmetic if is one of the few good things in FORTRAN ... > Of course I wouldn't suggest having it be implemented as goto's, but > some reasonable syntax, such as: > evaluate (fun(4,"test") < 22) > { < 0 action } > { equal action } > { > 0 action } What's wrong with typedef enum {LESS = -1, EQUAL = 0, GREATER = 1} Order; extern Order int_compare(int, int); switch (int_compare(fun(4,"test"), 22) { case LESS: ...; break; case EQUAL: ...; break; case GREATER: ...; break; } No new syntax needed. Where something like this pays off is when you are comparing strings or complicated records, and you don't want to do it twice, but that is when you are defining your own comparison function anyway. This is really a comp.lang.misc issue.
cik@l.cc.purdue.edu (Herman Rubin) (03/24/88)
In article <800@cresswell.quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes: > In article <10037@steinmetz.steinmetz.ge.com>, davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr) writes: || The arithmetic if is one of the few good things in FORTRAN > ... || Of course I wouldn't suggest having it be implemented as goto's, but || some reasonable syntax, such as: || evaluate (fun(4,"test") < 22) || { < 0 action } || { equal action } || { > 0 action } > > What's wrong with > typedef enum {LESS = -1, EQUAL = 0, GREATER = 1} Order; > extern Order int_compare(int, int); > > switch (int_compare(fun(4,"test"), 22) { > case LESS: ...; break; > case EQUAL: ...; break; > case GREATER: ...; break; > } > No new syntax needed. Where something like this pays off is when > you are comparing strings or complicated records, and you don't > want to do it twice, but that is when you are defining your own > comparison function anyway. This is really a comp.lang.misc issue. This is only acceptable if you are comparing _long_ strings or complicated records; it is far too costly otherwise. On the machines of the 50's, from which the language gurus seem to have gotten their ideas, testing and branching were cheap relative to computation; I fear that will never be the case again. Subroutine calls are expensive; even though int_compare (and is the problem only restricted to integers?) is not cheap, the subroutine call is likely to be even more costly. Few implementations allow the user to force inline. The mind of the mathematician can conceive far more than the compiler can fathom. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet
anw@nott-cs.UUCP (03/29/88)
In article <4816@ecsvax.UUCP> urjlew@ecsvax.UUCP (Rostyk Lewyckyj) writes: >Since a mail reply to Mr. Walker in Great Britain is unlikely >to be accepted [...]. Nottingham isn't exactly the remotest place in the universe! We do have intelligent life here, and an excellent cricket team. >In article <551@tuck.nott-cs.UUCP>, anw@nott-cs.UUCP writes: >> [ In response to a claim that Fortran addicts might change if the modern >> languages were more efficient, I quoted a Whetstone benchmark, showing >> that on an ICL 1906A in 1976 >> Pascal > Algol 68 > Fortran >> Algol 60 >> with little effect on the users. ] >Note that the Fortran compiler figure is the best of the figures >for ICL compilers. Yeah, third isn't bad. But note that the Algol 68 wasn't optimised, and the Fortran was. Good modern languages [1968 onwards!] allow the user to say what is wanted in a way that is easy to compile into efficient code. While I'm on the subject, a correspondent tells me of vague memories that Pascal and Algol also benchmarked faster than Fortran on the CDC 7600, again with very little effect on the general population of users. Rings a bell with me too -- anyone able to confirm or deny? > Also did the machine you ran on have hardware >floating point? Of course. '6A was top of the range. >Anyway this should be being discussed in comp.lang.fortran. I'd never dare admit to reading "comp.lang.fortran". But in deference to the minimal architecture content of these postings, I'm re-directing follow-ups to "comp.lang.misc". -- Andy Walker, Maths Dept, Nott'm Univ. anw@maths.nott.ac.uk
radford@calgary.UUCP (Radford Neal) (04/01/88)
In article <552@tuck.nott-cs.UUCP>, anw@nott-cs.UUCP writes: > While I'm on the subject, a correspondent tells me of vague memories > that Pascal and Algol also benchmarked faster than Fortran on the CDC > 7600, again with very little effect on the general population of users. > Rings a bell with me too -- anyone able to confirm or deny? Back in 74 to 78, I used a CDC 6400, which is instruction set compatible with a 7600. The FORTRAN compiler was certainly far better than the Pascal and Algol 60 compilers for numeric computations. The difference was likely even larger for th 7600, with its multiple functional units, exploited by the FORTRAN compiler more than Pascal or Algol. However... I can well beleive that most FORTRAN programs ran slower than they would have if written in Pascal. Most FORTRAN programs are not dominated by numeric computations. The FORTRAN IO system was abysmally slow, due to the need to interpret formats at run time, plus general brain damage. I find it rather amusing how scientists and engineers insist of using FORTRAN for "numeric" applications which are 90% IO, data conversion, and control, applications for which it is wholely inappropriate, *especially* if you are not a professional programmer. Radford Neal