Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.theory > #59474

Re: Validating the notion of a simulating halt decider

Show all headers | View raw

On Fri, 11 Nov 2022 10:12:43 -0500
Richard Damon <Richard@Damon-Family.org> wrote:

> On 11/10/22 2:31 PM, olcott wrote:
> > MIT Professor Michael Sipser has agreed that the following verbatim 
> > paragraph is correct (he has not agreed to anything else):
> > 
> > If simulating halt decider H correctly simulates its input D until
> > H correctly determines that its simulated D would never stop
> > running unless aborted then H can abort its simulation of D and
> > correctly report that D specifies a non-halting sequence of
> > configurations.
> > 
> > void D(void (*x)())
> > {
> >    int Halt_Status = H(x, x);
> >    if (Halt_Status)
> >      HERE: goto HERE;
> >    return;
> > }
> > 
> > int main()
> > {
> >    Output("Input_Halts = ", H(D, D));
> > }
> > 
> > Unless one rejects the notion of a universal Turing machine (UTM)
> > then they already know that H can base its halt status decision on
> > the behavior of D correctly simulated by H.  
> 
> No, it can base its decision on the behavior of D correctly simulated.
> 
> D correctly simulatd by H means that H can not abort its simulation 
> until it reaches a final state, and thus can not be a decider that 
> return 0 for a non-halting input.
> 
> > 
> > That theory of computation textbooks do not bother to mention this
> > is only because they never considered the notion of a simulating
> > halt decider.
> > 
> > void D(void (*x)())
> > {
> >    H(x, x);
> > }
> > 
> > It is dead obvious that (ignoring stack overflow) D correctly
> > simulated by H will never stop running unless H aborts its
> > simulation of D.
> > 
> >   
> 
> The problem with your logic is that if H DOES correct simulate its 
> input, then if it is non-halting, H will NEVER stop its simulation.
> 
> That follows from the basic definition of what correct simulation is
> and the fact that a specific program always behaves the same when
> given a specific input.
> 
> You just seem unable to understand that changing the code of a
> program gives you a different program, and that the code of a program
> includes all the code of every piece that it calls. This includes
> even the operatin system (if there is one) that it runs under.
> 
> Thus the code for D above, when we are looking at its behavior,
> includes the code of the H it calls, so to determine its behavior you
> can't change H.
> 
> We thus have two DISTINCT possibilities that you talk about.
> 
> H could be a program that correct simulates its input, and such an H 
> will NEVER return 0.
> 
> Or, H can be a program that answers 0, but then it doesn't correctly 
> simulate its input, and its argument about a correct simulation of 
> something that looks somewhat like its input is shown to be actually 
> about an input that is actually different than the one it was given.
> 
> You are just showing you don't understand the basic defintions of the
> field.
> 
> It seems that you don't actually understand what a program is, or
> what computation theory calls a "function".
> 
> You also don't seem to understand the basics of category theory as
> your "Simulating Halt Deciders" reject the idea that they need to be
> actual Halt Deciders but somehow thing that a sub-category doesn't
> need to have all the attributes of the super-category they are
> supposed to be part of.

It is my understanding that Olcott has blocked you and I would have
thought given your intelligence you would also understand that so why
the verbose reply to him?

/Flibble

Back to comp.theory | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Validating the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-11-10 13:31 -0600
  Re: Validating the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-11-11 10:12 -0500
    Re: Validating the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-11 18:35 +0000

csiph-web