From: mailbox@dmitry-kazakov.de   
      
   On Thu, 06 May 2010 07:10:11 GMT, Don Geddis wrote:   
      
   > "Dmitry A. Kazakov"  wrote on Sun, 25 Apr 2010:   
   >>> But that wasn't what I asked.  What I asked was: how do you USE the   
   >>> lower level description, in order to make predictions and draw   
   >>> conclusions ABOUT the high level behavior?   
   >>   
   >> Lover level of WHAT? Before talking about a subject it has to be fixed   
   >> whatever level at.   
   >   
   > Have you already lost track of your own argument?   
      
   No, the question was concerning the subject. If you meant a description of   
   program code, then at whatever level, if the description is complete you   
   can predict absolutely everything. That trivially follows from its   
   finiteness, because you can enumerate all states of the GIVEN   
   program/computational system.   
      
   > We have a program.  You give it a list of numbers, and (after some   
   > time) it turns a list of the same numbers, only sorted.  Originally,   
   > this program takes time on the order of N^2, where N is the number of   
   > elements in the list.   
   >   
   > After using the program a number of times, over days and weeks, you   
   > discover that the program begins returning the answer faster.  It now   
   > takes time on the order of N log N, instead of N^2.  It still takes a   
   > list of numbers as input, and still produces a list of those numbers   
   > sorted as output.   
   >   
   > Has the program's behavior "changed"?   
      
   No. It was programmed in order to behave the described way.   
      
   Consider a data base which stores numbers. When a row is written into a   
   table, is the behavior of the RDBMS changed by that? The answer is no, even   
   if SELECT would return a different result set. It must do so. RDBMS shall   
   behave this way.   
      
   >  Reasonable people would say   
   > "yes", and that position is defensible.   
      
   No, it is not, because it exploits the already described trick: talking   
   about x, meaning y.   
      
   > This thread started because you claimed that no program could ever   
   > change its own behavior.  But we can certainly write a sorting program   
   > that changes the time complexity of its sort over time.   
      
   CPU pipelining changes complexity of instruction execution, which by no   
   means imply that it solders itself. Pipelining is its behavior. A CD can be   
   written with the Beatles' songs, which does not mean that the CD would   
   compose, interpret and sing. Playback is its behavior. An interpreter does   
   not change its behavior by interpreting some source. Interpreting is its   
   behavior. And so on, and so forth.   
      
   > But it is you who have confused levels of abstraction.  It is true that   
   > the CPU and RAM and that state-space transition has not changed.  But it   
   > is also true that the sorting algorithm has gone from N^2 to N log N, so   
   > the sorting algorithm has changed.  And it is also true that the sorting   
   > algorithm depends on the (unchanging) CPU/RAM in order to implement it.   
   >   
   > The point is, that the CPU/RAM model of the system, although lower   
   > level, is not a privileged model in any sense.  Just because that model   
   > hasn't changed, you can't conclude that some other model (like "a sort   
   > algorithm") hasn't changed.   
      
   If there exists a model of perpetual motion that model is inconsistent.   
      
   --   
   Regards,   
   Dmitry A. Kazakov   
   http://www.dmitry-kazakov.de   
      
   [ comp.ai is moderated ... your article may take a while to appear. ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)