home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / arch / 8915 < prev    next >
Encoding:
Internet Message Format  |  1992-08-15  |  2.5 KB
  1. Path: sparky!uunet!gatech!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  2. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  3. Newsgroups: comp.arch
  4. Subject: Lengths. Was: Re: 32 => 64 Transition
  5. Message-ID: <56918@mentor.cc.purdue.edu>
  6. Date: 15 Aug 92 14:34:48 GMT
  7. References: <1992Aug11.125326.16719@email.tuwien.ac.at> <id.UHAS.9TA@ferranti.com> <robert.713773090@cs.anu.edu.au>
  8. Sender: news@mentor.cc.purdue.edu
  9. Organization: Purdue University Statistics Department
  10. Lines: 41
  11.  
  12. In article <robert.713773090@cs.anu.edu.au> robert@cs.anu.edu.au (Robert Cohen) writes:
  13. >peter@ferranti.com (peter da silva) writes:
  14.  
  15. >>What size would *you* make an int? 64 bits? What do you do for a 32-bit
  16. >>data type? Short? Then what do you do for a 16-bit data type? Create another
  17. >>abomination "short short" or "long char"? "long long" is bad enough.
  18.  
  19. >The perfect solution: int= 64, long =128 (for real men's numbers),
  20. >short = 32, char = 8, long char= 16, short short = 24,
  21. >long short = 48 and short long = 96.
  22. >If we need more precision we can start using short short long and
  23. >long short long etc.
  24. >In case anyone hasn't realised yet :-) :-) :-)
  25.  
  26. >More seriously, I belive that we need a way to machine independently
  27. >specify the precision such as int:32.
  28. >When I write a program I usually know what sort of range I expect
  29. >a variable to have to hold. I dont care if its an int or a long or a short
  30. >on different machines, I want a number about that big.
  31.  
  32. >Who uses 16 bit variables anymore anyway, memory's cheap, right :-)
  33.  
  34. There are many situations in which one generates what is essentially
  35. a bit stream, and works with that.  The generation process takes about
  36. the same length of time regardless of the sizes of the "words" produced
  37. up to machine arithmetic size.  I have not found any situations yet 
  38. where using 16-bit blocks is the "right" thing to do, but some situations
  39. which I have not completely investigated may call for it.
  40.  
  41. There is another usage which will be coming out shortly, that of text
  42. communication not restricted to the Latin alphabet.  I have read on other
  43. groups about a protocol, called unicode, which will use 16 bits/character.
  44. As you have said, memory's cheap, so why should we be limited to 8 bits?
  45.  
  46. Other sizes which should be considered are 52 (53?), the length of the
  47. significand in an IEEE float, etc.
  48. -- 
  49. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  50. Phone: (317)494-6054
  51. hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  52. {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  53.