home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / fortran / 3288 < prev    next >
Encoding:
Text File  |  1992-08-30  |  2.6 KB  |  56 lines

  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!uvaarpa!cv3.cv.nrao.edu!laphroaig!cflatter
  3. From: cflatter@nrao.edu (Chris Flatters)
  4. Subject: Re: Scientists as Programmers (was Re: Smal
  5. Message-ID: <1992Aug30.232409.15262@nrao.edu>
  6. Sender: news@nrao.edu
  7. Reply-To: cflatter@nrao.edu
  8. Organization: NRAO
  9. References: <BttB9z.IAy@mentor.cc.purdue.edu>
  10. Date: Sun, 30 Aug 1992 23:24:09 GMT
  11. Lines: 43
  12.  
  13. In article IAy@mentor.cc.purdue.edu, hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
  14. >This statement is too broad.  Modularization is not a problem for the
  15. >scientist, but it can be a major time-waster if the current software is
  16. >used.  Subroutine calls are, at this time, and for the foreseeable future,
  17. >quite expensive.  This was not the case when Fortran and Algol were first
  18. >produced; there were few registers then, transfer was the fastest instruction,
  19. >and context switching cost less than one multiplication.
  20.  
  21. Subroutine calls are not that expensive.  Here are some examples.
  22.  
  23.         function call+return        double precision fp operation
  24.         (average time in us)             (average time in us)
  25.  
  26. SPARCstation IPX     0.115                    0.146
  27. 25 MHz 386SX/387SX     1.75                    3.37
  28.  
  29. (IPX timing from Sun C++ 2.1 using -O4; 386SX/387SX timing taken from
  30. GNU C 1.39 with -O under 386BSD 0.1).  Unless the work carried out in
  31. a subroutine is trivial the overhead of a function call can be discounted.
  32.  
  33. >I have deliberately violated types to get the job done.  In fact, I see no
  34. >good way out of it.  Now there might be some point to informing the programmer
  35. >that types are violated, but very definitely not to insist on it, or to force
  36.  
  37. It is rarely necessary to violate type constraints in a strongly typed language.
  38. When it is necessary it is possible to localize the code that does this.  Most
  39. typesafe languages provide mechanisms to avoid the constraints of the type
  40. system in these rare cases (eg. the WORD data type in Modula 2).
  41.  
  42. >Also, mathematicians especially use lots of operators.  Despite what the CS
  43. >gurus say, allowing the introduction of additional functions is not the
  44. >same thing.  Also, mathematicians and scientists are accustomed to using
  45. >whatever syntax they like, as long as it does not lead to confusion.  But
  46. >the CS people insist that only the standard operators are to be allowed to
  47. >use infix notation, and all others must be prefix, except in reverse Polish
  48. >systems, in which all must be postfix.  
  49.  
  50. Restrictions on the introduction of new operators arise from practical
  51. considerations.  The introduction of a new infix operator changes the
  52. syntax of the language significantly.
  53.  
  54.     Chris Flatters
  55.     cflatter@nrao.edu
  56.