home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / programm / 2103 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  2.4 KB
  1. Path: sparky!uunet!olivea!decwrl!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  2. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  3. Newsgroups: comp.programming
  4. Subject: Re: floating point routines with double precision
  5. Message-ID: <55036@mentor.cc.purdue.edu>
  6. Date: 24 Jul 92 20:48:00 GMT
  7. References: <1992Jul22.120724.3466@druid.uucp> <54944@mentor.cc.purdue.edu> <6760@charon.cwi.nl>
  8. Sender: news@mentor.cc.purdue.edu
  9. Organization: Purdue University Statistics Department
  10. Lines: 38
  11.  
  12. In article <6760@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
  13. >In article <54944@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
  14.  
  15.             ......................
  16.  
  17. > > Now I was answering the question assuming that more than the designed
  18. > > precision is needed.  The routines are not difficult for a human to
  19. > > design, but almost hopeless for a compiler.  Anyone who writes such
  20. > > a procedure for a machine which has forced normalization will curse
  21. > > the designers.
  22. >Well, as the machine of the original requestor has no floating-point
  23. >hardware, this point is moot.  Moreover, it is not the compiler that
  24. >suddenly comes up with some code to do double-precision, it is put in
  25. >the compiler by the compiler-writer, e.g. hand-coded.  He may have done
  26. >a poor job of course (as some code sequences for the 205 show, but that one
  27. >had an extremely bad Fortran compiler; past tense because the one I used
  28. >has been decommissioned more than a year ago).
  29.  
  30. The 205 is much easier for the purpose of increasing precision because
  31. the floating-point arithmetic is not forced to be normalized.  The Crays
  32. are much worse here, although they are not forced normalized for 
  33. multiplication, but because only the most significant part of the
  34. product can be obtained.
  35.  
  36. If we want everything to be in the compiler, the compiler will be very
  37. large indeed.  One of the points I wish to stress is that, no matter
  38. how much is put in the compiler, much more, even from the standpoint
  39. of practicality, will be omitted.  And as knowledge progresses, the
  40. variety of things to consider increases.
  41.  
  42. With the present languages, it is already necessary to consider 
  43. alternate codings to achieve the same purpose for such simple
  44. things as adding two vectors.
  45. -- 
  46. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  47. Phone: (317)494-6054
  48. hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  49. {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  50.