home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / fortran / 3236 < prev    next >
Encoding:
Text File  |  1992-08-27  |  3.1 KB  |  72 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!utcsri!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!mroussel
  3. From: mroussel@alchemy.chem.utoronto.ca (Marc Roussel)
  4. Subject: Re: Small Language Wanted
  5. Message-ID: <1992Aug27.181926.5677@alchemy.chem.utoronto.ca>
  6. Organization: Department of Chemistry, University of Toronto
  7. References: <DAVIS.92Aug23010605@pacific.mps.ohio-state.edu> <H.3lvmyc56w&A@lionbbs.bs.open.de>
  8. Date: Thu, 27 Aug 1992 18:19:26 GMT
  9. Lines: 61
  10.  
  11. In article <H.3lvmyc56w&A@lionbbs.bs.open.de> UweKloss@lionbbs.bs.open.de
  12. writes:
  13. >In <DAVIS.92Aug23010605@pacific.mps.ohio-state.edu>, "John E. Davis" writes:
  14. >> In addition, C has nothing equivalent to Fortrans **
  15. >> operator nor does it have complex types.
  16. >The differeces between code the compiler generates and
  17. >the one that is linked as a library or inserted by the
  18. >preprocessor.
  19.  
  20.      That is a big difference!  Consider the following Fortran program:
  21.  
  22.       integer i
  23.       double precision a,b
  24.       a = 4.2
  25.       b = 9.3
  26.       i = 10
  27.       write(*,*)a**i,a**b
  28.       END
  29.  
  30.      The compiler, faced with such a program, examines the types of the
  31. arguments and generates completely different code to do the two
  32. exponentiations; certainly, one calculation can be expressed exactly in
  33. terms of multiplications while the other cannot.  It may be more
  34. efficient or more accurate to do it one way or the other and the
  35. compiler can choose a calculation method which reflects current thinking
  36. on this sort of problem.
  37.      Now consider an equivalent piece of code, written in C:
  38.  
  39.      void main(){
  40.      int i;
  41.      double a,b;
  42.      a = 4.2;
  43.      b = 9.3;
  44.      i = 10;
  45.      printf(pow(a,(double) i),pow(a,b));
  46.      }
  47.  
  48. (You'll forgive me, I hope, for getting the C idiom slightly wrong.
  49. The one manual I have at hand right now is less than entirely helpful on
  50. several trivial details.  In particular, I'm not at all sure that the
  51. cast of i to double is entirely kosher, and I think that printf wants a
  52. format specification.  In any event, you get the general idea.)  Can the
  53. compiler play the sorts of tricks which the Fortran compiler was free to
  54. do?  I don't think so.  pow() being a library routine, I don't think it
  55. would be good form (or standard-conforming) for the compiler to guess at
  56. the programmer's intent and to do anything more than to leave the
  57. reference to be resolved by the linker.  After all, until the library is
  58. linked in, in principle the compiler knows nothing about any function
  59. but perhaps its prototype.  This particular library function
  60. expects (I think) two doubles (floats?) and must be passed these.
  61. That's all there is to it.
  62.      In my opinion, what C lacks to be able to handle these things
  63. correctly is any concept of a "built-in" function.  Fortran knows to
  64. treat sin(a) and sin(x) differently if a is real and x is double
  65. precision because knowledge of these primitive functions is built into
  66. the compiler.  C can't do anything like this because of its design.  C
  67. is great for writing wordprocessors, but not so great for scientific
  68. computing for exactly this sort of reason.
  69.  
  70.                 Marc R. Roussel
  71.                                 mroussel@alchemy.chem.utoronto.ca
  72.