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

Groups > comp.lang.c++ > #86869 > unrolled thread

Michael Sipser of MIT validates the notion of a simulating halt decider

Back to article view | Back to comp.lang.c++

Contents

  Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 10:08 -0500
    Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 11:48 -0500
    Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 12:04 -0500
    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-12 18:24 +0100
      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-12 12:38 -0500
        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-12 18:52 +0100
          Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 13:04 -0500
            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-12 19:07 +0100
              Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 13:25 -0500
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-12 19:30 +0100
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 14:17 -0500
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-12 20:26 +0100
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 14:32 -0500
                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-12 20:50 +0100
    Re: Michael Sipser of MIT validates the notion of a simulating halt decider (Ben's support) olcott <none-ya@beez-waxes.com> - 2022-10-20 22:17 -0500
    Ben agrees that Sipser_H is correct according to its halt status criteria olcott <polcott2@gmail.com> - 2022-10-21 15:03 -0500
      Re: Ben agrees that Sipser_H is correct according to its halt status criteria Paul N <gw7rib@aol.com> - 2022-10-22 05:19 -0700
        Re: Ben agrees that Sipser_H is correct according to its halt status criteria [Paul N Lies] olcott <polcott2@gmail.com> - 2022-10-22 14:20 -0500
        Paul N is a liar or does not bother to pay attention olcott <polcott2@gmail.com> - 2022-10-22 17:10 -0500

#86869 — Michael Sipser of MIT validates the notion of a simulating halt decider

Professor Michael Sipser of MIT said that this verbatim paragraph looks 
correct:

    If H does correctly determine that its correct simulation
    of D would never stop running unless aborted, would it be
    correct for H to abort this simulation and report that D
    specifies a non-halting sequence of configurations?

This validates the idea of a simulating halt decider referenced in this 
paper.

*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof 


Professor Sipser has not had the time to carefully review this paper 
presented to him.

*The exact words posted above have been approved by Michael Sipser*


-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

[toc] | [next] | [standalone]

#86871

On 10/12/2022 10:54 AM, Fred. Zwarts wrote:
> Op 12.okt..2022 om 17:08 schreef olcott:
>> Professor Michael Sipser of MIT said that this verbatim paragraph 
>> looks correct:
>>
>>     If H does correctly determine that its correct simulation
>>     of D would never stop running unless aborted, would it be
>>     correct for H to abort this simulation and report that D
>>     specifies a non-halting sequence of configurations?
>>
>> This validates the idea of a simulating halt decider referenced in 
>> this paper.
>>
>> *Rebutting the Sipser Halting Problem Proof*
>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>
>> Professor Sipser has not had the time to carefully review this paper 
>> presented to him.
>>
>> *The exact words posted above have been approved by Michael Sipser*
>>
>>
> 
> And what does he say about:
> 
>       If H does incorrectly determine that its incorrect simulation
>       of D would never stop running unless aborted, would it be
>       correct for H to abort this simulation and report that D
>       specifies a non-halting sequence of configurations?
> 

Professor Michael Sipser of MIT said that this verbatim paragraph looks 
correct:

    If H does correctly determine that its correct simulation
    of D would never stop running unless aborted, would it be
    correct for H to abort this simulation and report that D
    specifies a non-halting sequence of configurations?

This validates that the behavior of D correctly simulated by H is the 
correct behavior that H must report on, thus affirming that the notion 
of a simulating halt decider is correct.

Complete halt deciding system (Visual Studio Project) Sipser version.
(a) x86utm operating system
(b) x86 emulator adapted from libx86emu to compile under Windows
(c) Several halt deciders and their sample inputs contained within Halt7.c
https://liarparadox.org/2022_10_08.zip

Ordinary software engineering verifies the simulation of Sipser_D by 
Sipser_H is correct. Ordinary software engineering also verifies that 
Sipser_H does correctly determine that Sipser_D is stuck in what would 
otherwise be infinitely recursive simulation unless H aborts its 
simulation of Sipser_D.

As can be seen from the above quote Professor Sipser has agreed that 
this would be the correct basis for Sipser_H to report that Sipser_D 
specifies a non-halting sequence of configurations.

-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#86872

On 10/12/2022 11:46 AM, Ben Bacarisse wrote:
> "Fred. Zwarts" <F.Zwarts@KVI.nl> writes:
> 
>> Op 12.okt..2022 om 17:08 schreef olcott:
>>> Professor Michael Sipser of MIT said that this verbatim paragraph looks correct:
>>>      If H does correctly determine that its correct simulation
>>>      of D would never stop running unless aborted, would it be
>>>      correct for H to abort this simulation and report that D
>>>      specifies a non-halting sequence of configurations?
>>> This validates the idea of a simulating halt decider referenced in this
>>> paper.
>>> *Rebutting the Sipser Halting Problem Proof*
>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>> Professor Sipser has not had the time to carefully review this paper
>>> presented to him.
>>> *The exact words posted above have been approved by Michael Sipser*
>>>
>>
>> And what does he say about:
> 
> Oh please don't draw the good professor into this any further!
> 
>>       If H does incorrectly determine that its incorrect simulation
>>       of D would never stop running unless aborted, would it be
>>       correct for H to abort this simulation and report that D
>>       specifies a non-halting sequence of configurations?
> 
> You need to remove the deceptive subjunctive "would ... unless" to get
> something not open to PO's dishonest re-interpretation.  Whatever H
> "would" do "unless" it does what it actually does is irrelevant.  H(P,P)
> returns 0 and P(P) halts.  0 is the wrong answer for a halting
> computation.
> 

Professor Sipser essentially validates the same notion of a simulating 
halt decider that I have had all along:

When-so-ever simulating halt decider H correctly determines that its 
correct simulation of its input D would never stop running unless 
aborted then it is always correct for H to abort its simulation of D and 
report that D specifies a non-halting sequence of configurations.

<quoted email>
Professor Sipser:

Here is what I would like to say:

Professor Michael Sipser of MIT said that this verbatim paragraph looks 
correct:

    If H does correctly determine that its correct simulation
    of D would never stop  running unless aborted, would it be
    correct for H to abort this simulation and report that D
    specifies a non-halting sequence of configurations?

This validates the idea of a simulating halt decider referenced in this 
paper.

*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof 


Professor Sipser has not had the time to carefully review this paper 
presented to him.
</quoted email>

<quoted reply>
Looks ok.  Thanks for checking.
</quoted reply>




-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#86873

On Wed, 12 Oct 2022 10:08:20 -0500
olcott <polcott2@gmail.com> wrote:

> Professor Michael Sipser of MIT said that this verbatim paragraph
> looks correct:
> 
>     If H does correctly determine that its correct simulation
>     of D would never stop running unless aborted, would it be
>     correct for H to abort this simulation and report that D
>     specifies a non-halting sequence of configurations?
> 
> This validates the idea of a simulating halt decider referenced in
> this paper.
> 
> *Rebutting the Sipser Halting Problem Proof*
> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof 
> 
> 
> Professor Sipser has not had the time to carefully review this paper 
> presented to him.
> 
> *The exact words posted above have been approved by Michael Sipser*

Whilst the paragraph you sent to Sipser is correct the crucial detail
that you are glossing over is that you do NOT perform a correct
simulation for all inputs:

void Px(void (*x)())
{
	(void) H(x, x);
	return;
}

The correct simulation of Px above is to simulate Px halting.

Sipser confirms that the Flibble Signaling Halt Decider (TM) is a
solution however it does not confirm that the Olcott Simulation
Detector is a valid halt decider.

/Flibble

[toc] | [prev] | [next] | [standalone]

#86874

On 10/12/2022 12:24 PM, Mr Flibble wrote:
> On Wed, 12 Oct 2022 10:08:20 -0500
> olcott <polcott2@gmail.com> wrote:
> 
>> Professor Michael Sipser of MIT said that this verbatim paragraph
>> looks correct:
>>
>>      If H does correctly determine that its correct simulation
>>      of D would never stop running unless aborted, would it be
>>      correct for H to abort this simulation and report that D
>>      specifies a non-halting sequence of configurations?
>>
>> This validates the idea of a simulating halt decider referenced in
>> this paper.
>>
>> *Rebutting the Sipser Halting Problem Proof*
>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>
>>
>> Professor Sipser has not had the time to carefully review this paper
>> presented to him.
>>
>> *The exact words posted above have been approved by Michael Sipser*
> 
> Whilst the paragraph you sent to Sipser is correct the crucial detail
> that you are glossing over is that you do NOT perform a correct
> simulation for all inputs:
> 

Complete halt deciding system (Visual Studio Project) Sipser version.
(a) x86utm operating system
(b) x86 emulator adapted from libx86emu to compile under Windows
(c) Several halt deciders and their sample inputs contained within Halt7.c
https://liarparadox.org/2022_10_08.zip

Anyone with sufficient software engineering skill can easily verify that 
Sipser_D is correctly simulated by Sipser_H and that Sipser_D remains 
stuck in infinitely recursive simulation unless and until Sipser_H 
aborts its correct simulation of Sipser_D.

-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#86875

On Wed, 12 Oct 2022 12:38:31 -0500
olcott <none-ya@beez-waxes.com> wrote:

> On 10/12/2022 12:24 PM, Mr Flibble wrote:
> > On Wed, 12 Oct 2022 10:08:20 -0500
> > olcott <polcott2@gmail.com> wrote:
> >   
> >> Professor Michael Sipser of MIT said that this verbatim paragraph
> >> looks correct:
> >>
> >>      If H does correctly determine that its correct simulation
> >>      of D would never stop running unless aborted, would it be
> >>      correct for H to abort this simulation and report that D
> >>      specifies a non-halting sequence of configurations?
> >>
> >> This validates the idea of a simulating halt decider referenced in
> >> this paper.
> >>
> >> *Rebutting the Sipser Halting Problem Proof*
> >> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
> >>
> >>
> >> Professor Sipser has not had the time to carefully review this
> >> paper presented to him.
> >>
> >> *The exact words posted above have been approved by Michael
> >> Sipser*  
> > 
> > Whilst the paragraph you sent to Sipser is correct the crucial
> > detail that you are glossing over is that you do NOT perform a
> > correct simulation for all inputs:
> >   
> 
> Complete halt deciding system (Visual Studio Project) Sipser version.
> (a) x86utm operating system
> (b) x86 emulator adapted from libx86emu to compile under Windows
> (c) Several halt deciders and their sample inputs contained within
> Halt7.c https://liarparadox.org/2022_10_08.zip
> 
> Anyone with sufficient software engineering skill can easily verify
> that Sipser_D is correctly simulated by Sipser_H and that Sipser_D
> remains stuck in infinitely recursive simulation unless and until
> Sipser_H aborts its correct simulation of Sipser_D.

You chose to not fully address my reply by snipping the important part
so I will give you another chance:

Whilst the paragraph you sent to Sipser is correct the crucial detail
that you are glossing over is that you do NOT perform a correct
simulation for all inputs:

void Px(void (*x)())
{
	(void) H(x, x);
	return;
}

The correct simulation of Px above is to simulate Px halting.

Sipser confirms that the Flibble Signaling Halt Decider (TM) is a
solution however it does not confirm that the Olcott Simulation
Detector is a valid halt decider.

/Flibble

[toc] | [prev] | [next] | [standalone]

#86876

On 10/12/2022 12:52 PM, Mr Flibble wrote:
> On Wed, 12 Oct 2022 12:38:31 -0500
> olcott <none-ya@beez-waxes.com> wrote:
> 
>> On 10/12/2022 12:24 PM, Mr Flibble wrote:
>>> On Wed, 12 Oct 2022 10:08:20 -0500
>>> olcott <polcott2@gmail.com> wrote:
>>>    
>>>> Professor Michael Sipser of MIT said that this verbatim paragraph
>>>> looks correct:
>>>>
>>>>       If H does correctly determine that its correct simulation
>>>>       of D would never stop running unless aborted, would it be
>>>>       correct for H to abort this simulation and report that D
>>>>       specifies a non-halting sequence of configurations?
>>>>
>>>> This validates the idea of a simulating halt decider referenced in
>>>> this paper.
>>>>
>>>> *Rebutting the Sipser Halting Problem Proof*
>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>>>
>>>>
>>>> Professor Sipser has not had the time to carefully review this
>>>> paper presented to him.
>>>>
>>>> *The exact words posted above have been approved by Michael
>>>> Sipser*
>>>
>>> Whilst the paragraph you sent to Sipser is correct the crucial
>>> detail that you are glossing over is that you do NOT perform a
>>> correct simulation for all inputs:
>>>    
>>
>> Complete halt deciding system (Visual Studio Project) Sipser version.
>> (a) x86utm operating system
>> (b) x86 emulator adapted from libx86emu to compile under Windows
>> (c) Several halt deciders and their sample inputs contained within
>> Halt7.c https://liarparadox.org/2022_10_08.zip
>>
>> Anyone with sufficient software engineering skill can easily verify
>> that Sipser_D is correctly simulated by Sipser_H and that Sipser_D
>> remains stuck in infinitely recursive simulation unless and until
>> Sipser_H aborts its correct simulation of Sipser_D.
> 
> You chose to not fully address my reply by snipping the important part
> so I will give you another chance:
> 
> Whilst the paragraph you sent to Sipser is correct the crucial detail
> that you are glossing over is that you do NOT perform a correct
> simulation for all inputs:
> 
> void Px(void (*x)())
> {
> 	(void) H(x, x);
> 	return;
> }
> 
> The correct simulation of Px above is to simulate Px halting.
> 

Not at all. It must be a correct simulation of the actual input by the 
simulating halt decider.

int main() { H(Px,Px); }
(a) The executed H simulates Px that calls a simulated H
(b) that simulates Px that calls a simulated H
(c) that simulates Px that calls a simulated H ...



-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#86877

On Wed, 12 Oct 2022 13:04:17 -0500
olcott <polcott2@gmail.com> wrote:

> On 10/12/2022 12:52 PM, Mr Flibble wrote:
> > On Wed, 12 Oct 2022 12:38:31 -0500
> > olcott <none-ya@beez-waxes.com> wrote:
> >   
> >> On 10/12/2022 12:24 PM, Mr Flibble wrote:  
> >>> On Wed, 12 Oct 2022 10:08:20 -0500
> >>> olcott <polcott2@gmail.com> wrote:
> >>>      
> >>>> Professor Michael Sipser of MIT said that this verbatim paragraph
> >>>> looks correct:
> >>>>
> >>>>       If H does correctly determine that its correct simulation
> >>>>       of D would never stop running unless aborted, would it be
> >>>>       correct for H to abort this simulation and report that D
> >>>>       specifies a non-halting sequence of configurations?
> >>>>
> >>>> This validates the idea of a simulating halt decider referenced
> >>>> in this paper.
> >>>>
> >>>> *Rebutting the Sipser Halting Problem Proof*
> >>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
> >>>>
> >>>>
> >>>> Professor Sipser has not had the time to carefully review this
> >>>> paper presented to him.
> >>>>
> >>>> *The exact words posted above have been approved by Michael
> >>>> Sipser*  
> >>>
> >>> Whilst the paragraph you sent to Sipser is correct the crucial
> >>> detail that you are glossing over is that you do NOT perform a
> >>> correct simulation for all inputs:
> >>>      
> >>
> >> Complete halt deciding system (Visual Studio Project) Sipser
> >> version. (a) x86utm operating system
> >> (b) x86 emulator adapted from libx86emu to compile under Windows
> >> (c) Several halt deciders and their sample inputs contained within
> >> Halt7.c https://liarparadox.org/2022_10_08.zip
> >>
> >> Anyone with sufficient software engineering skill can easily verify
> >> that Sipser_D is correctly simulated by Sipser_H and that Sipser_D
> >> remains stuck in infinitely recursive simulation unless and until
> >> Sipser_H aborts its correct simulation of Sipser_D.  
> > 
> > You chose to not fully address my reply by snipping the important
> > part so I will give you another chance:
> > 
> > Whilst the paragraph you sent to Sipser is correct the crucial
> > detail that you are glossing over is that you do NOT perform a
> > correct simulation for all inputs:
> > 
> > void Px(void (*x)())
> > {
> > 	(void) H(x, x);
> > 	return;
> > }
> > 
> > The correct simulation of Px above is to simulate Px halting.
> >   
> 
> Not at all. It must be a correct simulation of the actual input by
> the simulating halt decider.
> 
> int main() { H(Px,Px); }
> (a) The executed H simulates Px that calls a simulated H
> (b) that simulates Px that calls a simulated H
> (c) that simulates Px that calls a simulated H ...

Yes indeed it must be a correct simulation and a correct simulation of
Px is to simulate Px halting.

/Flibble

[toc] | [prev] | [next] | [standalone]

#86878

On 10/12/2022 1:07 PM, Mr Flibble wrote:
> On Wed, 12 Oct 2022 13:04:17 -0500
> olcott <polcott2@gmail.com> wrote:
> 
>> On 10/12/2022 12:52 PM, Mr Flibble wrote:
>>> On Wed, 12 Oct 2022 12:38:31 -0500
>>> olcott <none-ya@beez-waxes.com> wrote:
>>>    
>>>> On 10/12/2022 12:24 PM, Mr Flibble wrote:
>>>>> On Wed, 12 Oct 2022 10:08:20 -0500
>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>       
>>>>>> Professor Michael Sipser of MIT said that this verbatim paragraph
>>>>>> looks correct:
>>>>>>
>>>>>>        If H does correctly determine that its correct simulation
>>>>>>        of D would never stop running unless aborted, would it be
>>>>>>        correct for H to abort this simulation and report that D
>>>>>>        specifies a non-halting sequence of configurations?
>>>>>>
>>>>>> This validates the idea of a simulating halt decider referenced
>>>>>> in this paper.
>>>>>>
>>>>>> *Rebutting the Sipser Halting Problem Proof*
>>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>>>>>
>>>>>>
>>>>>> Professor Sipser has not had the time to carefully review this
>>>>>> paper presented to him.
>>>>>>
>>>>>> *The exact words posted above have been approved by Michael
>>>>>> Sipser*
>>>>>
>>>>> Whilst the paragraph you sent to Sipser is correct the crucial
>>>>> detail that you are glossing over is that you do NOT perform a
>>>>> correct simulation for all inputs:
>>>>>       
>>>>
>>>> Complete halt deciding system (Visual Studio Project) Sipser
>>>> version. (a) x86utm operating system
>>>> (b) x86 emulator adapted from libx86emu to compile under Windows
>>>> (c) Several halt deciders and their sample inputs contained within
>>>> Halt7.c https://liarparadox.org/2022_10_08.zip
>>>>
>>>> Anyone with sufficient software engineering skill can easily verify
>>>> that Sipser_D is correctly simulated by Sipser_H and that Sipser_D
>>>> remains stuck in infinitely recursive simulation unless and until
>>>> Sipser_H aborts its correct simulation of Sipser_D.
>>>
>>> You chose to not fully address my reply by snipping the important
>>> part so I will give you another chance:
>>>
>>> Whilst the paragraph you sent to Sipser is correct the crucial
>>> detail that you are glossing over is that you do NOT perform a
>>> correct simulation for all inputs:
>>>
>>> void Px(void (*x)())
>>> {
>>> 	(void) H(x, x);
>>> 	return;
>>> }
>>>
>>> The correct simulation of Px above is to simulate Px halting.
>>>    
>>
>> Not at all. It must be a correct simulation of the actual input by
>> the simulating halt decider.
>>
>> int main() { H(Px,Px); }
>> (a) The executed H simulates Px that calls a simulated H
>> (b) that simulates Px that calls a simulated H
>> (c) that simulates Px that calls a simulated H ...
> 
> Yes indeed it must be a correct simulation and a correct simulation of
> Px is to simulate Px halting.
> 
> /Flibble
> 

Sipser agreed that the correct simulation of Px by H is the correct 
measure of the behavior of Px.

When we look at the above execution trace of: int main() { H(Px,Px); }
We see that Px remains stuck in recursive simulation until H aborts this 
simulation.

-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#86880

On Wed, 12 Oct 2022 13:25:34 -0500
olcott <polcott2@gmail.com> wrote:

> On 10/12/2022 1:07 PM, Mr Flibble wrote:
> > On Wed, 12 Oct 2022 13:04:17 -0500
> > olcott <polcott2@gmail.com> wrote:
> >   
> >> On 10/12/2022 12:52 PM, Mr Flibble wrote:  
> >>> On Wed, 12 Oct 2022 12:38:31 -0500
> >>> olcott <none-ya@beez-waxes.com> wrote:
> >>>      
> >>>> On 10/12/2022 12:24 PM, Mr Flibble wrote:  
> >>>>> On Wed, 12 Oct 2022 10:08:20 -0500
> >>>>> olcott <polcott2@gmail.com> wrote:
> >>>>>         
> >>>>>> Professor Michael Sipser of MIT said that this verbatim
> >>>>>> paragraph looks correct:
> >>>>>>
> >>>>>>        If H does correctly determine that its correct
> >>>>>> simulation of D would never stop running unless aborted, would
> >>>>>> it be correct for H to abort this simulation and report that D
> >>>>>>        specifies a non-halting sequence of configurations?
> >>>>>>
> >>>>>> This validates the idea of a simulating halt decider referenced
> >>>>>> in this paper.
> >>>>>>
> >>>>>> *Rebutting the Sipser Halting Problem Proof*
> >>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
> >>>>>>
> >>>>>>
> >>>>>> Professor Sipser has not had the time to carefully review this
> >>>>>> paper presented to him.
> >>>>>>
> >>>>>> *The exact words posted above have been approved by Michael
> >>>>>> Sipser*  
> >>>>>
> >>>>> Whilst the paragraph you sent to Sipser is correct the crucial
> >>>>> detail that you are glossing over is that you do NOT perform a
> >>>>> correct simulation for all inputs:
> >>>>>         
> >>>>
> >>>> Complete halt deciding system (Visual Studio Project) Sipser
> >>>> version. (a) x86utm operating system
> >>>> (b) x86 emulator adapted from libx86emu to compile under Windows
> >>>> (c) Several halt deciders and their sample inputs contained
> >>>> within Halt7.c https://liarparadox.org/2022_10_08.zip
> >>>>
> >>>> Anyone with sufficient software engineering skill can easily
> >>>> verify that Sipser_D is correctly simulated by Sipser_H and that
> >>>> Sipser_D remains stuck in infinitely recursive simulation unless
> >>>> and until Sipser_H aborts its correct simulation of Sipser_D.  
> >>>
> >>> You chose to not fully address my reply by snipping the important
> >>> part so I will give you another chance:
> >>>
> >>> Whilst the paragraph you sent to Sipser is correct the crucial
> >>> detail that you are glossing over is that you do NOT perform a
> >>> correct simulation for all inputs:
> >>>
> >>> void Px(void (*x)())
> >>> {
> >>> 	(void) H(x, x);
> >>> 	return;
> >>> }
> >>>
> >>> The correct simulation of Px above is to simulate Px halting.
> >>>      
> >>
> >> Not at all. It must be a correct simulation of the actual input by
> >> the simulating halt decider.
> >>
> >> int main() { H(Px,Px); }
> >> (a) The executed H simulates Px that calls a simulated H
> >> (b) that simulates Px that calls a simulated H
> >> (c) that simulates Px that calls a simulated H ...  
> > 
> > Yes indeed it must be a correct simulation and a correct simulation
> > of Px is to simulate Px halting.
> > 
> > /Flibble
> >   
> 
> Sipser agreed that the correct simulation of Px by H is the correct 
> measure of the behavior of Px.

Of course he did but you don't do a correct simulation of Px: a
correct simulation of Px is to simulate Px halting as that is how Px
behaves. 

/Flibble

[toc] | [prev] | [next] | [standalone]

#86881

On 10/12/2022 1:30 PM, Mr Flibble wrote:
> On Wed, 12 Oct 2022 13:25:34 -0500
> olcott <polcott2@gmail.com> wrote:
> 
>> On 10/12/2022 1:07 PM, Mr Flibble wrote:
>>> On Wed, 12 Oct 2022 13:04:17 -0500
>>> olcott <polcott2@gmail.com> wrote:
>>>    
>>>> On 10/12/2022 12:52 PM, Mr Flibble wrote:
>>>>> On Wed, 12 Oct 2022 12:38:31 -0500
>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>       
>>>>>> On 10/12/2022 12:24 PM, Mr Flibble wrote:
>>>>>>> On Wed, 12 Oct 2022 10:08:20 -0500
>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>          
>>>>>>>> Professor Michael Sipser of MIT said that this verbatim
>>>>>>>> paragraph looks correct:
>>>>>>>>
>>>>>>>>         If H does correctly determine that its correct
>>>>>>>> simulation of D would never stop running unless aborted, would
>>>>>>>> it be correct for H to abort this simulation and report that D
>>>>>>>>         specifies a non-halting sequence of configurations?
>>>>>>>>
>>>>>>>> This validates the idea of a simulating halt decider referenced
>>>>>>>> in this paper.
>>>>>>>>
>>>>>>>> *Rebutting the Sipser Halting Problem Proof*
>>>>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>>>>>>>
>>>>>>>>
>>>>>>>> Professor Sipser has not had the time to carefully review this
>>>>>>>> paper presented to him.
>>>>>>>>
>>>>>>>> *The exact words posted above have been approved by Michael
>>>>>>>> Sipser*
>>>>>>>
>>>>>>> Whilst the paragraph you sent to Sipser is correct the crucial
>>>>>>> detail that you are glossing over is that you do NOT perform a
>>>>>>> correct simulation for all inputs:
>>>>>>>          
>>>>>>
>>>>>> Complete halt deciding system (Visual Studio Project) Sipser
>>>>>> version. (a) x86utm operating system
>>>>>> (b) x86 emulator adapted from libx86emu to compile under Windows
>>>>>> (c) Several halt deciders and their sample inputs contained
>>>>>> within Halt7.c https://liarparadox.org/2022_10_08.zip
>>>>>>
>>>>>> Anyone with sufficient software engineering skill can easily
>>>>>> verify that Sipser_D is correctly simulated by Sipser_H and that
>>>>>> Sipser_D remains stuck in infinitely recursive simulation unless
>>>>>> and until Sipser_H aborts its correct simulation of Sipser_D.
>>>>>
>>>>> You chose to not fully address my reply by snipping the important
>>>>> part so I will give you another chance:
>>>>>
>>>>> Whilst the paragraph you sent to Sipser is correct the crucial
>>>>> detail that you are glossing over is that you do NOT perform a
>>>>> correct simulation for all inputs:
>>>>>
>>>>> void Px(void (*x)())
>>>>> {
>>>>> 	(void) H(x, x);
>>>>> 	return;
>>>>> }
>>>>>
>>>>> The correct simulation of Px above is to simulate Px halting.
>>>>>       
>>>>
>>>> Not at all. It must be a correct simulation of the actual input by
>>>> the simulating halt decider.
>>>>
>>>> int main() { H(Px,Px); }
>>>> (a) The executed H simulates Px that calls a simulated H
>>>> (b) that simulates Px that calls a simulated H
>>>> (c) that simulates Px that calls a simulated H ...
>>>
>>> Yes indeed it must be a correct simulation and a correct simulation
>>> of Px is to simulate Px halting.
>>>
>>> /Flibble
>>>    
>>
>> Sipser agreed that the correct simulation of Px by H is the correct
>> measure of the behavior of Px.
> 
> Of course he did but you don't do a correct simulation of Px: a
> correct simulation of Px is to simulate Px halting as that is how Px
> behaves.
> 
> /Flibble
> 

A correct simulation of Px by H derives the execution trace that I 
specified. Every line of the execution trace of the x86 emulation of Px 
by H precisely corresponds to exactly what the x86 source code of Px 
specifies.

void Px(void (*x)())
{
   (void) H(x, x);
   return;
}

int main()
{
   Output("Input_Halts = ", H(Px, Px));
}

_Px()
[00001256] 55             push ebp
[00001257] 8bec           mov ebp,esp
[00001259] 8b4508         mov eax,[ebp+08]
[0000125c] 50             push eax      // push 2nd arg to H
[0000125d] 8b4d08         mov ecx,[ebp+08]
[00001260] 51             push ecx      // push 1st arg to H
[00001261] e8b0fcffff     call 00000f16 // call H
[00001266] 83c408         add esp,+08
[00001269] 5d             pop ebp
[0000126a] c3             ret
Size in bytes:(0021) [0000126a]

H: Begin Simulation   Execution Trace Stored at:111fcb
Address_of_H:f16
[00001256][00111fb7][00111fbb] 55             push ebp
[00001257][00111fb7][00111fbb] 8bec           mov ebp,esp
[00001259][00111fb7][00111fbb] 8b4508         mov eax,[ebp+08]
[0000125c][00111fb3][00001256] 50             push eax      // push Px
[0000125d][00111fb3][00001256] 8b4d08         mov ecx,[ebp+08]
[00001260][00111faf][00001256] 51             push ecx      // push Px
[00001261][00111fab][00001266] e8b0fcffff     call 00000f16 // call H
H: Infinitely Recursive Simulation Detected Simulation Stopped

We can see that the execution trace of the first six instructions of Px 
exactly matches the x86 source-code of Px. We can also see that Px was 
about to call H(Px,Px) again and this would repeat the cycle of the 
first six instructions of Px.

-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#86882

On Wed, 12 Oct 2022 14:17:35 -0500
olcott <polcott2@gmail.com> wrote:

> On 10/12/2022 1:30 PM, Mr Flibble wrote:
> > On Wed, 12 Oct 2022 13:25:34 -0500
> > olcott <polcott2@gmail.com> wrote:
> >   
> >> On 10/12/2022 1:07 PM, Mr Flibble wrote:  
> >>> On Wed, 12 Oct 2022 13:04:17 -0500
> >>> olcott <polcott2@gmail.com> wrote:
> >>>      
> >>>> On 10/12/2022 12:52 PM, Mr Flibble wrote:  
> >>>>> On Wed, 12 Oct 2022 12:38:31 -0500
> >>>>> olcott <none-ya@beez-waxes.com> wrote:
> >>>>>         
> >>>>>> On 10/12/2022 12:24 PM, Mr Flibble wrote:  
> >>>>>>> On Wed, 12 Oct 2022 10:08:20 -0500
> >>>>>>> olcott <polcott2@gmail.com> wrote:
> >>>>>>>            
> >>>>>>>> Professor Michael Sipser of MIT said that this verbatim
> >>>>>>>> paragraph looks correct:
> >>>>>>>>
> >>>>>>>>         If H does correctly determine that its correct
> >>>>>>>> simulation of D would never stop running unless aborted,
> >>>>>>>> would it be correct for H to abort this simulation and
> >>>>>>>> report that D specifies a non-halting sequence of
> >>>>>>>> configurations?
> >>>>>>>>
> >>>>>>>> This validates the idea of a simulating halt decider
> >>>>>>>> referenced in this paper.
> >>>>>>>>
> >>>>>>>> *Rebutting the Sipser Halting Problem Proof*
> >>>>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Professor Sipser has not had the time to carefully review
> >>>>>>>> this paper presented to him.
> >>>>>>>>
> >>>>>>>> *The exact words posted above have been approved by Michael
> >>>>>>>> Sipser*  
> >>>>>>>
> >>>>>>> Whilst the paragraph you sent to Sipser is correct the crucial
> >>>>>>> detail that you are glossing over is that you do NOT perform a
> >>>>>>> correct simulation for all inputs:
> >>>>>>>            
> >>>>>>
> >>>>>> Complete halt deciding system (Visual Studio Project) Sipser
> >>>>>> version. (a) x86utm operating system
> >>>>>> (b) x86 emulator adapted from libx86emu to compile under
> >>>>>> Windows (c) Several halt deciders and their sample inputs
> >>>>>> contained within Halt7.c https://liarparadox.org/2022_10_08.zip
> >>>>>>
> >>>>>> Anyone with sufficient software engineering skill can easily
> >>>>>> verify that Sipser_D is correctly simulated by Sipser_H and
> >>>>>> that Sipser_D remains stuck in infinitely recursive simulation
> >>>>>> unless and until Sipser_H aborts its correct simulation of
> >>>>>> Sipser_D.  
> >>>>>
> >>>>> You chose to not fully address my reply by snipping the
> >>>>> important part so I will give you another chance:
> >>>>>
> >>>>> Whilst the paragraph you sent to Sipser is correct the crucial
> >>>>> detail that you are glossing over is that you do NOT perform a
> >>>>> correct simulation for all inputs:
> >>>>>
> >>>>> void Px(void (*x)())
> >>>>> {
> >>>>> 	(void) H(x, x);
> >>>>> 	return;
> >>>>> }
> >>>>>
> >>>>> The correct simulation of Px above is to simulate Px halting.
> >>>>>         
> >>>>
> >>>> Not at all. It must be a correct simulation of the actual input
> >>>> by the simulating halt decider.
> >>>>
> >>>> int main() { H(Px,Px); }
> >>>> (a) The executed H simulates Px that calls a simulated H
> >>>> (b) that simulates Px that calls a simulated H
> >>>> (c) that simulates Px that calls a simulated H ...  
> >>>
> >>> Yes indeed it must be a correct simulation and a correct
> >>> simulation of Px is to simulate Px halting.
> >>>
> >>> /Flibble
> >>>      
> >>
> >> Sipser agreed that the correct simulation of Px by H is the correct
> >> measure of the behavior of Px.  
> > 
> > Of course he did but you don't do a correct simulation of Px: a
> > correct simulation of Px is to simulate Px halting as that is how Px
> > behaves.
> > 
> > /Flibble
> >   
> 
> A correct simulation of Px by H derives the execution trace that I 
> specified. Every line of the execution trace of the x86 emulation of
> Px by H precisely corresponds to exactly what the x86 source code of
> Px specifies.
> 
> void Px(void (*x)())
> {
>    (void) H(x, x);
>    return;
> }
> 
> int main()
> {
>    Output("Input_Halts = ", H(Px, Px));
> }
> 
> _Px()
> [00001256] 55             push ebp
> [00001257] 8bec           mov ebp,esp
> [00001259] 8b4508         mov eax,[ebp+08]
> [0000125c] 50             push eax      // push 2nd arg to H
> [0000125d] 8b4d08         mov ecx,[ebp+08]
> [00001260] 51             push ecx      // push 1st arg to H
> [00001261] e8b0fcffff     call 00000f16 // call H
> [00001266] 83c408         add esp,+08
> [00001269] 5d             pop ebp
> [0000126a] c3             ret
> Size in bytes:(0021) [0000126a]
> 
> H: Begin Simulation   Execution Trace Stored at:111fcb
> Address_of_H:f16
> [00001256][00111fb7][00111fbb] 55             push ebp
> [00001257][00111fb7][00111fbb] 8bec           mov ebp,esp
> [00001259][00111fb7][00111fbb] 8b4508         mov eax,[ebp+08]
> [0000125c][00111fb3][00001256] 50             push eax      // push Px
> [0000125d][00111fb3][00001256] 8b4d08         mov ecx,[ebp+08]
> [00001260][00111faf][00001256] 51             push ecx      // push Px
> [00001261][00111fab][00001266] e8b0fcffff     call 00000f16 // call H
> H: Infinitely Recursive Simulation Detected Simulation Stopped
> 
> We can see that the execution trace of the first six instructions of
> Px exactly matches the x86 source-code of Px. We can also see that Px
> was about to call H(Px,Px) again and this would repeat the cycle of
> the first six instructions of Px.

There are various methods of simulating an input: you have chosen an
incorrect method of simulation; if we substitute your H for another H
which uses a correct method of simulation, Px will correctly halt.

An SHD which uses a correct method of simulation would be the Flibble
Signaling Halt Decider (TM).

/Flibble

[toc] | [prev] | [next] | [standalone]

#86884

On 10/12/2022 2:26 PM, Mr Flibble wrote:
> On Wed, 12 Oct 2022 14:17:35 -0500
> olcott <polcott2@gmail.com> wrote:
> 
>> On 10/12/2022 1:30 PM, Mr Flibble wrote:
>>> On Wed, 12 Oct 2022 13:25:34 -0500
>>> olcott <polcott2@gmail.com> wrote:
>>>    
>>>> On 10/12/2022 1:07 PM, Mr Flibble wrote:
>>>>> On Wed, 12 Oct 2022 13:04:17 -0500
>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>       
>>>>>> On 10/12/2022 12:52 PM, Mr Flibble wrote:
>>>>>>> On Wed, 12 Oct 2022 12:38:31 -0500
>>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>>          
>>>>>>>> On 10/12/2022 12:24 PM, Mr Flibble wrote:
>>>>>>>>> On Wed, 12 Oct 2022 10:08:20 -0500
>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>             
>>>>>>>>>> Professor Michael Sipser of MIT said that this verbatim
>>>>>>>>>> paragraph looks correct:
>>>>>>>>>>
>>>>>>>>>>          If H does correctly determine that its correct
>>>>>>>>>> simulation of D would never stop running unless aborted,
>>>>>>>>>> would it be correct for H to abort this simulation and
>>>>>>>>>> report that D specifies a non-halting sequence of
>>>>>>>>>> configurations?
>>>>>>>>>>
>>>>>>>>>> This validates the idea of a simulating halt decider
>>>>>>>>>> referenced in this paper.
>>>>>>>>>>
>>>>>>>>>> *Rebutting the Sipser Halting Problem Proof*
>>>>>>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Professor Sipser has not had the time to carefully review
>>>>>>>>>> this paper presented to him.
>>>>>>>>>>
>>>>>>>>>> *The exact words posted above have been approved by Michael
>>>>>>>>>> Sipser*
>>>>>>>>>
>>>>>>>>> Whilst the paragraph you sent to Sipser is correct the crucial
>>>>>>>>> detail that you are glossing over is that you do NOT perform a
>>>>>>>>> correct simulation for all inputs:
>>>>>>>>>             
>>>>>>>>
>>>>>>>> Complete halt deciding system (Visual Studio Project) Sipser
>>>>>>>> version. (a) x86utm operating system
>>>>>>>> (b) x86 emulator adapted from libx86emu to compile under
>>>>>>>> Windows (c) Several halt deciders and their sample inputs
>>>>>>>> contained within Halt7.c https://liarparadox.org/2022_10_08.zip
>>>>>>>>
>>>>>>>> Anyone with sufficient software engineering skill can easily
>>>>>>>> verify that Sipser_D is correctly simulated by Sipser_H and
>>>>>>>> that Sipser_D remains stuck in infinitely recursive simulation
>>>>>>>> unless and until Sipser_H aborts its correct simulation of
>>>>>>>> Sipser_D.
>>>>>>>
>>>>>>> You chose to not fully address my reply by snipping the
>>>>>>> important part so I will give you another chance:
>>>>>>>
>>>>>>> Whilst the paragraph you sent to Sipser is correct the crucial
>>>>>>> detail that you are glossing over is that you do NOT perform a
>>>>>>> correct simulation for all inputs:
>>>>>>>
>>>>>>> void Px(void (*x)())
>>>>>>> {
>>>>>>> 	(void) H(x, x);
>>>>>>> 	return;
>>>>>>> }
>>>>>>>
>>>>>>> The correct simulation of Px above is to simulate Px halting.
>>>>>>>          
>>>>>>
>>>>>> Not at all. It must be a correct simulation of the actual input
>>>>>> by the simulating halt decider.
>>>>>>
>>>>>> int main() { H(Px,Px); }
>>>>>> (a) The executed H simulates Px that calls a simulated H
>>>>>> (b) that simulates Px that calls a simulated H
>>>>>> (c) that simulates Px that calls a simulated H ...
>>>>>
>>>>> Yes indeed it must be a correct simulation and a correct
>>>>> simulation of Px is to simulate Px halting.
>>>>>
>>>>> /Flibble
>>>>>       
>>>>
>>>> Sipser agreed that the correct simulation of Px by H is the correct
>>>> measure of the behavior of Px.
>>>
>>> Of course he did but you don't do a correct simulation of Px: a
>>> correct simulation of Px is to simulate Px halting as that is how Px
>>> behaves.
>>>
>>> /Flibble
>>>    
>>
>> A correct simulation of Px by H derives the execution trace that I
>> specified. Every line of the execution trace of the x86 emulation of
>> Px by H precisely corresponds to exactly what the x86 source code of
>> Px specifies.
>>
>> void Px(void (*x)())
>> {
>>     (void) H(x, x);
>>     return;
>> }
>>
>> int main()
>> {
>>     Output("Input_Halts = ", H(Px, Px));
>> }
>>
>> _Px()
>> [00001256] 55             push ebp
>> [00001257] 8bec           mov ebp,esp
>> [00001259] 8b4508         mov eax,[ebp+08]
>> [0000125c] 50             push eax      // push 2nd arg to H
>> [0000125d] 8b4d08         mov ecx,[ebp+08]
>> [00001260] 51             push ecx      // push 1st arg to H
>> [00001261] e8b0fcffff     call 00000f16 // call H
>> [00001266] 83c408         add esp,+08
>> [00001269] 5d             pop ebp
>> [0000126a] c3             ret
>> Size in bytes:(0021) [0000126a]
>>
>> H: Begin Simulation   Execution Trace Stored at:111fcb
>> Address_of_H:f16
>> [00001256][00111fb7][00111fbb] 55             push ebp
>> [00001257][00111fb7][00111fbb] 8bec           mov ebp,esp
>> [00001259][00111fb7][00111fbb] 8b4508         mov eax,[ebp+08]
>> [0000125c][00111fb3][00001256] 50             push eax      // push Px
>> [0000125d][00111fb3][00001256] 8b4d08         mov ecx,[ebp+08]
>> [00001260][00111faf][00001256] 51             push ecx      // push Px
>> [00001261][00111fab][00001266] e8b0fcffff     call 00000f16 // call H
>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>
>> We can see that the execution trace of the first six instructions of
>> Px exactly matches the x86 source-code of Px. We can also see that Px
>> was about to call H(Px,Px) again and this would repeat the cycle of
>> the first six instructions of Px.
> 
> There are various methods of simulating an input: you have chosen an
> incorrect method of simulation; if we substitute your H for another H
> which uses a correct method of simulation, Px will correctly halt.
> 
> An SHD which uses a correct method of simulation would be the Flibble
> Signaling Halt Decider (TM).
> 
> /Flibble
> 

Everyone that is sufficiently technically competent at software 
engineering can verify that H does correctly simulate Px on the basis 
that the line-by-line execution trace of the simulation of Px by H 
exactly matches the line-by-line x86 source-code of Px.

People that are not sufficiently technically competent might use 
double-talk, misdirection and vagueness to provide a baseless rebuttal.

-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#86885

On Wed, 12 Oct 2022 14:32:41 -0500
olcott <polcott2@gmail.com> wrote:

> On 10/12/2022 2:26 PM, Mr Flibble wrote:
> > On Wed, 12 Oct 2022 14:17:35 -0500
> > olcott <polcott2@gmail.com> wrote:
> >   
> >> On 10/12/2022 1:30 PM, Mr Flibble wrote:  
> >>> On Wed, 12 Oct 2022 13:25:34 -0500
> >>> olcott <polcott2@gmail.com> wrote:
> >>>      
> >>>> On 10/12/2022 1:07 PM, Mr Flibble wrote:  
> >>>>> On Wed, 12 Oct 2022 13:04:17 -0500
> >>>>> olcott <polcott2@gmail.com> wrote:
> >>>>>         
> >>>>>> On 10/12/2022 12:52 PM, Mr Flibble wrote:  
> >>>>>>> On Wed, 12 Oct 2022 12:38:31 -0500
> >>>>>>> olcott <none-ya@beez-waxes.com> wrote:
> >>>>>>>            
> >>>>>>>> On 10/12/2022 12:24 PM, Mr Flibble wrote:  
> >>>>>>>>> On Wed, 12 Oct 2022 10:08:20 -0500
> >>>>>>>>> olcott <polcott2@gmail.com> wrote:
> >>>>>>>>>               
> >>>>>>>>>> Professor Michael Sipser of MIT said that this verbatim
> >>>>>>>>>> paragraph looks correct:
> >>>>>>>>>>
> >>>>>>>>>>          If H does correctly determine that its correct
> >>>>>>>>>> simulation of D would never stop running unless aborted,
> >>>>>>>>>> would it be correct for H to abort this simulation and
> >>>>>>>>>> report that D specifies a non-halting sequence of
> >>>>>>>>>> configurations?
> >>>>>>>>>>
> >>>>>>>>>> This validates the idea of a simulating halt decider
> >>>>>>>>>> referenced in this paper.
> >>>>>>>>>>
> >>>>>>>>>> *Rebutting the Sipser Halting Problem Proof*
> >>>>>>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Professor Sipser has not had the time to carefully review
> >>>>>>>>>> this paper presented to him.
> >>>>>>>>>>
> >>>>>>>>>> *The exact words posted above have been approved by Michael
> >>>>>>>>>> Sipser*  
> >>>>>>>>>
> >>>>>>>>> Whilst the paragraph you sent to Sipser is correct the
> >>>>>>>>> crucial detail that you are glossing over is that you do
> >>>>>>>>> NOT perform a correct simulation for all inputs:
> >>>>>>>>>               
> >>>>>>>>
> >>>>>>>> Complete halt deciding system (Visual Studio Project) Sipser
> >>>>>>>> version. (a) x86utm operating system
> >>>>>>>> (b) x86 emulator adapted from libx86emu to compile under
> >>>>>>>> Windows (c) Several halt deciders and their sample inputs
> >>>>>>>> contained within Halt7.c
> >>>>>>>> https://liarparadox.org/2022_10_08.zip
> >>>>>>>>
> >>>>>>>> Anyone with sufficient software engineering skill can easily
> >>>>>>>> verify that Sipser_D is correctly simulated by Sipser_H and
> >>>>>>>> that Sipser_D remains stuck in infinitely recursive
> >>>>>>>> simulation unless and until Sipser_H aborts its correct
> >>>>>>>> simulation of Sipser_D.  
> >>>>>>>
> >>>>>>> You chose to not fully address my reply by snipping the
> >>>>>>> important part so I will give you another chance:
> >>>>>>>
> >>>>>>> Whilst the paragraph you sent to Sipser is correct the crucial
> >>>>>>> detail that you are glossing over is that you do NOT perform a
> >>>>>>> correct simulation for all inputs:
> >>>>>>>
> >>>>>>> void Px(void (*x)())
> >>>>>>> {
> >>>>>>> 	(void) H(x, x);
> >>>>>>> 	return;
> >>>>>>> }
> >>>>>>>
> >>>>>>> The correct simulation of Px above is to simulate Px halting.
> >>>>>>>            
> >>>>>>
> >>>>>> Not at all. It must be a correct simulation of the actual input
> >>>>>> by the simulating halt decider.
> >>>>>>
> >>>>>> int main() { H(Px,Px); }
> >>>>>> (a) The executed H simulates Px that calls a simulated H
> >>>>>> (b) that simulates Px that calls a simulated H
> >>>>>> (c) that simulates Px that calls a simulated H ...  
> >>>>>
> >>>>> Yes indeed it must be a correct simulation and a correct
> >>>>> simulation of Px is to simulate Px halting.
> >>>>>
> >>>>> /Flibble
> >>>>>         
> >>>>
> >>>> Sipser agreed that the correct simulation of Px by H is the
> >>>> correct measure of the behavior of Px.  
> >>>
> >>> Of course he did but you don't do a correct simulation of Px: a
> >>> correct simulation of Px is to simulate Px halting as that is how
> >>> Px behaves.
> >>>
> >>> /Flibble
> >>>      
> >>
> >> A correct simulation of Px by H derives the execution trace that I
> >> specified. Every line of the execution trace of the x86 emulation
> >> of Px by H precisely corresponds to exactly what the x86 source
> >> code of Px specifies.
> >>
> >> void Px(void (*x)())
> >> {
> >>     (void) H(x, x);
> >>     return;
> >> }
> >>
> >> int main()
> >> {
> >>     Output("Input_Halts = ", H(Px, Px));
> >> }
> >>
> >> _Px()
> >> [00001256] 55             push ebp
> >> [00001257] 8bec           mov ebp,esp
> >> [00001259] 8b4508         mov eax,[ebp+08]
> >> [0000125c] 50             push eax      // push 2nd arg to H
> >> [0000125d] 8b4d08         mov ecx,[ebp+08]
> >> [00001260] 51             push ecx      // push 1st arg to H
> >> [00001261] e8b0fcffff     call 00000f16 // call H
> >> [00001266] 83c408         add esp,+08
> >> [00001269] 5d             pop ebp
> >> [0000126a] c3             ret
> >> Size in bytes:(0021) [0000126a]
> >>
> >> H: Begin Simulation   Execution Trace Stored at:111fcb
> >> Address_of_H:f16
> >> [00001256][00111fb7][00111fbb] 55             push ebp
> >> [00001257][00111fb7][00111fbb] 8bec           mov ebp,esp
> >> [00001259][00111fb7][00111fbb] 8b4508         mov eax,[ebp+08]
> >> [0000125c][00111fb3][00001256] 50             push eax      //
> >> push Px [0000125d][00111fb3][00001256] 8b4d08         mov
> >> ecx,[ebp+08] [00001260][00111faf][00001256] 51             push
> >> ecx      // push Px [00001261][00111fab][00001266] e8b0fcffff
> >> call 00000f16 // call H H: Infinitely Recursive Simulation
> >> Detected Simulation Stopped
> >>
> >> We can see that the execution trace of the first six instructions
> >> of Px exactly matches the x86 source-code of Px. We can also see
> >> that Px was about to call H(Px,Px) again and this would repeat the
> >> cycle of the first six instructions of Px.  
> > 
> > There are various methods of simulating an input: you have chosen an
> > incorrect method of simulation; if we substitute your H for another
> > H which uses a correct method of simulation, Px will correctly halt.
> > 
> > An SHD which uses a correct method of simulation would be the
> > Flibble Signaling Halt Decider (TM).
> > 
> > /Flibble
> >   
> 
> Everyone that is sufficiently technically competent at software 
> engineering can verify that H does correctly simulate Px on the basis 
> that the line-by-line execution trace of the simulation of Px by H 
> exactly matches the line-by-line x86 source-code of Px.
> 
> People that are not sufficiently technically competent might use 
> double-talk, misdirection and vagueness to provide a baseless
> rebuttal.

A valid halt decider MUST return a decision to its caller, in this case
Px, in finite time; Px will then halt, correctly.  Your H does not do
this so is not a valid halt decider.

/Flibble

[toc] | [prev] | [next] | [standalone]

#87110 — Re: Michael Sipser of MIT validates the notion of a simulating halt decider (Ben's support)

On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
> 
>> On 10/17/22 1:11 AM, olcott wrote:
>>> On 10/13/2022 1:53 PM, Ben Bacarisse wrote:
>>>> Jeff Barnett <jbb@notatt.com> writes:
>>>>
>>>>> Isn't the "brushoff with implied agreement" a method to decrank one's
>>>>> mailbox that was mentioned in Dudley's "The Trisectors"? Can't find my
>>>>> copy to check it out.
>>>>
>>>> No, I think Dudley explicitly says not to do that.  His two
>>>> recommendations are to be flattering while plainly pointing out the
>>>> error in the end result without engaging with the argument in any way.
>>>> For PO that would be "I see you have thought long and hard about this
>>>> problem and you have come up with some ingenious ideas.  However, H(P,P)
>>>> == 0 is not the correct answer if P(P) is a halting computation."
>>>>
>>> If H(D,D) meets the criteria then H(D,D)==0  No-Matter-What
>>
>> But it does'nt meet the criteria, sincd it never correctly determines
>> that the correct simulation of its input is non-halting.
> 
> Are you dancing round the fact that PO tricked the professor?
> 
> H(D,D) /does/ meet the criterion for PO's Other Halting problem -- the
> one no one cares about.  D(D) halts (so H is not halt decider), but D(D)
> would not halt unless H stops the simulation.  H /can/ correctly
> determine this silly criterion (in this one case) so H is a POOH decider
> (again, for this one case -- PO is not interested in the fact the POOH
> is also undecidable in general).
> 
>> The correct simulation is the correct simulation who ever does it, and
>> since D will halt when run, the correct simulation of D will halt.
> 
> Right, but that's not the criterion that PO is using, is it?  I don't
> get what the problem is.  Ever since the "line 15 commented out"
> debacle, PO has been pulling the same trick: "D(D) only halts
> because..." was one way he used to put it before finding a more tricky
> wording.  For years, the project has simply been to find words he can
> dupe people with.
> 

I will keep posting this every day reminding people that Ben has agreed 
that Sipser_H does correctly compute the halt status of Sipser_D 
according to this criteria:

*Professor Sipser has agreed to these verbatim words* (and no more)
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.

until someone like Andre gives me an accurate review of this paper.

*Simulating Halt Decider Applied to the Halting Theorem*
https://www.researchgate.net/publication/364302709_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem


-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#87123 — Ben agrees that Sipser_H is correct according to its halt status criteria

On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
> 
>> On 10/17/22 1:11 AM, olcott wrote:
>>> On 10/13/2022 1:53 PM, Ben Bacarisse wrote:
>>>> Jeff Barnett <jbb@notatt.com> writes:
>>>>
>>>>> Isn't the "brushoff with implied agreement" a method to decrank one's
>>>>> mailbox that was mentioned in Dudley's "The Trisectors"? Can't find my
>>>>> copy to check it out.
>>>>
>>>> No, I think Dudley explicitly says not to do that.  His two
>>>> recommendations are to be flattering while plainly pointing out the
>>>> error in the end result without engaging with the argument in any way. >>>> For PO that would be "I see you have thought long and hard about this
>>>> problem and you have come up with some ingenious ideas.  However, H(P,P)
>>>> == 0 is not the correct answer if P(P) is a halting computation."
>>>>
>>> If H(D,D) meets the criteria then H(D,D)==0  No-Matter-What
>>
>> But it does'nt meet the criteria, sincd it never correctly determines
>> that the correct simulation of its input is non-halting.
> 
> Are you dancing round the fact that PO tricked the professor?
> 
> H(D,D) /does/ meet the criterion for PO's Other Halting problem -- the
> one no one cares about.  D(D) halts (so H is not halt decider), but D(D)
> would not halt unless H stops the simulation.  H /can/ correctly
> determine this silly criterion (in this one case) so H is a POOH decider

Ben has agreed that Sipser_H does correctly compute the halt status of 
Sipser_D according to this criteria:

*Professor Sipser has agreed to these verbatim words* (and no more)
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.

*Simulating Halt Decider Applied to the Halting Theorem*
https://www.researchgate.net/publication/364302709_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem

> (again, for this one case -- PO is not interested in the fact the POOH
> is also undecidable in general).
> 
>> The correct simulation is the correct simulation who ever does it, and
>> since D will halt when run, the correct simulation of D will halt.
> 
> Right, but that's not the criterion that PO is using, is it?  I don't

Ben agrees that Richard is evaluating my work using the wrong criteria.

*This is the criteria that I am using*

*Professor Sipser has agreed to these verbatim words* (and no more)
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.

> get what the problem is.  Ever since the "line 15 commented out"
> debacle, PO has been pulling the same trick: "D(D) only halts
> because..." was one way he used to put it before finding a more tricky
> wording.  For years, the project has simply been to find words he can
> dupe people with.
> 

Professor Sipser knows these things much deeper than my learned-by-rote 
from a textbook reviewers.



-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#87130 — Re: Ben agrees that Sipser_H is correct according to its halt status criteria

For those who don't follow comp.theory, I think it is worth pointing out that Ben is trying to deal with PO by encouraging no-one to reply to him. This probably explains the posts here claiming that "Ben agrees" with things it's quite clear he does not agree with, either because PO thinks he can get away with it or to try to tempt Ben back into replying.


On Friday, October 21, 2022 at 9:03:45 PM UTC+1, polc...@gmail.com wrote:
> On 10/17/2022 10:23 AM, Ben Bacarisse wrote: 
> > Richard Damon <Ric...@Damon-Family.org> writes: 
> > 
> >> On 10/17/22 1:11 AM, olcott wrote: 
> >>> On 10/13/2022 1:53 PM, Ben Bacarisse wrote: 
> >>>> Jeff Barnett <j...@notatt.com> writes: 
> >>>> 
> >>>>> Isn't the "brushoff with implied agreement" a method to decrank one's 
> >>>>> mailbox that was mentioned in Dudley's "The Trisectors"? Can't find my 
> >>>>> copy to check it out. 
> >>>> 
> >>>> No, I think Dudley explicitly says not to do that.  His two 
> >>>> recommendations are to be flattering while plainly pointing out the 
> >>>> error in the end result without engaging with the argument in any way. >>>> For PO that would be "I see you have thought long and hard about this 
> >>>> problem and you have come up with some ingenious ideas.  However, H(P,P) 
> >>>> == 0 is not the correct answer if P(P) is a halting computation." 
> >>>> 
> >>> If H(D,D) meets the criteria then H(D,D)==0  No-Matter-What 
> >> 
> >> But it does'nt meet the criteria, sincd it never correctly determines 
> >> that the correct simulation of its input is non-halting. 
> > 
> > Are you dancing round the fact that PO tricked the professor? 
> > 
> > H(D,D) /does/ meet the criterion for PO's Other Halting problem -- the 
> > one no one cares about. D(D) halts (so H is not halt decider), but D(D) 
> > would not halt unless H stops the simulation. H /can/ correctly 
> > determine this silly criterion (in this one case) so H is a POOH decider
> Ben has agreed that Sipser_H does correctly compute the halt status of 
> Sipser_D according to this criteria: 
> 
> *Professor Sipser has agreed to these verbatim words* (and no more) 
> 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.
> *Simulating Halt Decider Applied to the Halting Theorem* 
> https://www.researchgate.net/publication/364302709_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
> > (again, for this one case -- PO is not interested in the fact the POOH 
> > is also undecidable in general). 
> > 
> >> The correct simulation is the correct simulation who ever does it, and 
> >> since D will halt when run, the correct simulation of D will halt. 
> > 
> > Right, but that's not the criterion that PO is using, is it? I don't
> Ben agrees that Richard is evaluating my work using the wrong criteria. 
> 
> *This is the criteria that I am using*
> *Professor Sipser has agreed to these verbatim words* (and no more) 
> 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.
> > get what the problem is. Ever since the "line 15 commented out" 
> > debacle, PO has been pulling the same trick: "D(D) only halts 
> > because..." was one way he used to put it before finding a more tricky 
> > wording. For years, the project has simply been to find words he can 
> > dupe people with. 
> >
> Professor Sipser knows these things much deeper than my learned-by-rote 
> from a textbook reviewers.

[toc] | [prev] | [next] | [standalone]

#87134 — Re: Ben agrees that Sipser_H is correct according to its halt status criteria [Paul N Lies]

On 10/22/2022 7:19 AM, Paul N wrote:
> For those who don't follow comp.theory, I think it is worth pointing out that Ben is trying to deal with PO by encouraging no-one to reply to him. This probably explains the posts here claiming that "Ben agrees" with things it's quite clear he does not agree with, 

*You are a liar or did not bother to pay attention*
*You are a liar or did not bother to pay attention*
*You are a liar or did not bother to pay attention*
*You are a liar or did not bother to pay attention*

These references are on comp.theory:

On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
 > D(D) would not halt unless H stops the simulation.
 > H /can/ correctly determine this silly criterion (in this one case)

*This is the "silly" criterion that Ben is referring to*

On 10/17/2022 12:11 AM, olcott wrote:
 > *Professor Sipser has agreed to these verbatim words* (and no more)
 > 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.
 >


-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#87137 — Paul N is a liar or does not bother to pay attention

On 10/22/2022 7:19 AM, Paul N wrote:
> For those who don't follow comp.theory, I think it is worth pointing out that Ben is trying to deal with PO by encouraging no-one to reply to him. This probably explains the posts here claiming that "Ben agrees" with things it's quite clear he does not agree with, 

*You are a liar or did not bother to pay attention*
*You are a liar or did not bother to pay attention*
*You are a liar or did not bother to pay attention*
*You are a liar or did not bother to pay attention*

These references are on comp.theory:

On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
 > D(D) would not halt unless H stops the simulation.
 > H /can/ correctly determine this silly criterion (in this one case)

*This is the "silly" criterion that Ben is referring to*

On 10/17/2022 12:11 AM, olcott wrote:
 > *Professor Sipser has agreed to these verbatim words* (and no more)
 > 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.
 >

-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web