home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / mac / programm / 14258 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  1.6 KB
  1. Path: sparky!uunet!comp.vuw.ac.nz!waikato.ac.nz!ldo
  2. From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: AIFF and 'extended' type
  5. Message-ID: <1992Aug20.181459.10250@waikato.ac.nz>
  6. Date: 20 Aug 92 18:14:59 +1200
  7. References: <1992Aug17.204116.11424@nosc.mil> <1992Aug19.100049.10187@waikato.ac.nz> <1992Aug20.013819.7382@eng.umd.edu>
  8. Organization: University of Waikato, Hamilton, New Zealand
  9. Lines: 20
  10.  
  11. In article <1992Aug20.013819.7382@eng.umd.edu>, russotto@eng.umd.edu (Matthew T. Russotto) writes:
  12. > In article <1992Aug19.100049.10187@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:
  13. >>
  14. >>It's interesting that Apple's guidelines state that the extended type is
  15. >>only meant for intermediate temporary values, to minimize rounding errors
  16. >>in multi-step calculations: you should *not* use it as a type for permanent
  17. >>storage of data. And yet they go and break their own guidelines with AIFF...
  18. >
  19. > That's because the 64-bit type (COMP in pascal, I don't remember in
  20. > 'C'--  possibly "short double") is dog-slow due to all the
  21. > conversions, and really wrecks the advantage of an FPU, too.
  22.  
  23. Yes, but that shouldn't be a significant factor for loading and saving data on
  24. permanent storage (i e disk).
  25.  
  26. Lawrence D'Oliveiro                       fone: +64-7-856-2889
  27. Computer Services Dept                     fax: +64-7-838-4066
  28. University of Waikato            electric mail: ldo@waikato.ac.nz
  29. Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
  30. This is a test of the  key on my keyboard.
  31.