home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.31 / text0025.txt < prev    next >
Encoding:
Text File  |  1993-07-15  |  3.8 KB  |  80 lines

  1. Submitted-by: jeffrey@netcom.com (Jeffrey Kegler)
  2.  
  3. In article <1oqhg1INNrs4@ftp.UU.NET> dave@88open.org (Dave Cline) writes:
  4. >In article <1ojaljINNrtb@ftp.UU.NET>,
  5. >             jeffrey@netcom.com (Jeffrey Kegler) writes:
  6. >> First off, let me point out, that since we are
  7. >> discussing standards, not physical machines, so the matters under
  8. >> discussion are all theoretical models.
  9. >
  10. >Standards contain limits making them finite.  For example, input
  11. >and output arguments in POSIX.1 are defined in terms of their
  12. >ANSI C realizations (2.9.1) and are clearly finite (e.g. INT_MAX,
  13. >sizeof(char *), etc.).
  14.  
  15. The readership of comp.std.unix should be able to spot the above
  16. reading of the standard as wrong with no trouble.  As a reading of ANSI
  17. X3.159-1989, section 2.2.4.2.1 shows, INT_MAX is a *minimum* -- the
  18. standard gives a magnitude they must be at least as large as, but
  19. implementors may define their magnitudes larger.  sizeof(char *) is
  20. implementation defined, pure and simple (3.3.3.4, 3.3.4, F.3.7).
  21.  
  22. But suppose it were right.  Is a memory which can consist of an
  23. infinite number of finite words, infinite in extent, or finite?
  24. Mathematics and intuition agree here, that an infinite number of 32 bit
  25. words contains an infinite number of bits.
  26.  
  27. With the standards and the math, Dave knows the vocabulary, but just
  28. randomly jumbles it.  It looks convincing as long as you know nothing
  29. about what's being discussed.  Dave should consider going into
  30. management.
  31.  
  32. >Proofs of the halting problem and undecidabilty all rely on the
  33. >fundamental assumption that the state space of the computation model
  34. >is infinite.  Changing from "infinite" to "very large" invalidates
  35. >the proofs.  Our current standards and the machines that implement
  36. >them are finite.  One cannot use Theory of Computation conclusions
  37. >about the halting problem or undecidability if the premises are not
  38. >satisfied.  Jeffrey's appeal to Turing complexity is unjustified.
  39.  
  40. Herbert S. Wilf, _Algorithms and Complexity_:  "We are going to talk
  41. about a Turing machine.  It is an idealized computer, and its purpose
  42. is to standardize ideas of computability and time of computation by
  43. referring all problems to the one standard machine. ... The beauty of
  44. the Turing machine is that it is at once a strong enough concept that
  45. it can in principle perform any calculation that any other finite-state
  46. machine can do, while at the same time it is logically clean and simple
  47. enough to be useful for proving theorems about complexity.  The
  48. microcomputer on your desktop might have been chosen as the standard
  49. against which polynomial-time computability is measured."
  50.  
  51. Incidentally, for someone desiring a good introduction to Theory of
  52. Computation, which has the virtue of focusing on essentials, avoiding
  53. much of the wearying detail that afflicts most such texts, I recommend
  54. Wilf.
  55.  
  56. Speaking of wearying detail, the moderator is losing patience with this
  57. thread, and I cannot blame him.  This will be my last post in reply to
  58. Cline.  This will allow him to have the last word, or as many such as
  59. the moderator cares to allow.  I can pretty much guarantee I won't even
  60. reply to new points raised, however outrageous -- I don't plan to read
  61. any more of Dave's posts.
  62.  
  63. I do plan to follow the rest of the discussion, and where I read
  64. arguments cogent enough to demand explication, extension or revision of
  65. my statements, I hope for the indulgence of the moderator.
  66.  
  67. -- 
  68. Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
  69. jeffrey@algor2.ALGORISTS.COM
  70. 137 E Fremont AVE #122, Sunnyvale CA 94087
  71.  
  72. [ Unless further messages have a more direct relevance to "unix standards,"
  73.   I will not post them.  I think the subject of testing is extremely
  74.   important, both to standards and software in general, but this is
  75.   no longer pertaining to the topic at hand.  Please feel free to yell at me if
  76.   you disagree -- mod ]
  77.  
  78. Volume-Number: Volume 31, Number 28
  79.  
  80.