home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / amiga / programm / 17317 < prev    next >
Encoding:
Text File  |  1992-12-13  |  2.1 KB  |  48 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!think.com!sdd.hp.com!col.hp.com!fc.hp.com!koren
  3. From: koren@fc.hp.com (Steve Koren)
  4. Subject: Re: SAS6.1 users: please read
  5. Sender: news@fc.hp.com (news daemon)
  6. Message-ID: <Bz81JE.Bp7@fc.hp.com>
  7. Date: Sun, 13 Dec 1992 23:35:38 GMT
  8. References: <Bz3zxI.2A8@unx.sas.com>
  9. Organization: Hewlett-Packard Fort Collins Site
  10. X-Newsreader: Tin 1.1.3 PL5
  11. Lines: 35
  12.  
  13. Doug Walker (walker@twix.unx.sas.com) wrote:
  14.  
  15. > be considering signed types wider than unsigned types, from looking at
  16. > your example with doubles and ints, but your term is "more general".
  17.  
  18. No, I don't consider them wider, but I _do_ consider them more general.
  19. The maximum integer storable in a signed and unsigned int is, I think,
  20. an implementation accident on all accords.  First, consider a CPU which
  21. used 64 bit ints but used only 63 bits for _both_ signed and unsigned
  22. ints, ignoring the sign bit in one case and using it in the other.  In
  23. that case, there is no overflow problem because the maximum is the
  24. same for both signed and unsigned ints.  Second, the likelihood of
  25. overflowing MAXINT is dependent on the size of the integer.  Whether or
  26. not you overflow is just an accident of how the numbers happen to be
  27. stored.
  28.  
  29. Contrast this to the sign loss problem.  The sign is an integral property
  30. of the data type, and does not depend on the storage method or
  31. architecture of the CPU.  By using ANSI's rules, you _always_ run into
  32. the sign loss problem, no matter how your CPU deals with signed vs.
  33. unsigned ints and no matter how big they are.
  34.  
  35. Think of the problem outside of computer terms: integers have no maximum
  36. value, so you can't overflow them to loose information.  But you can
  37. loose sign information using ANSI's promoting rules.  Nothing says that
  38. a future generation of CPUs won't default to arbitrary precision math,
  39. thus making the overflow problem meaningless, but leaving the sign loss
  40. problem.
  41.  
  42. My argument with ANSI is that I believe what they picked was both
  43. shortsighted and dependent on our current CPU's implementation of
  44. signed vs. unsigned ints.
  45.  
  46.    - steve
  47.  
  48.