On 19/04/2023 11:52 pm, olcott wrote:
> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>> On 19/04/2023 10:10 pm, olcott wrote:
>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>> A simulating halt decider correctly predicts whether or not its
>>>>>>>>>>> correctly simulated input can possibly reach its own final
>>>>>>>>>>> state and
>>>>>>>>>>> halt. It does this by correctly recognizing several
>>>>>>>>>>> non-halting behavior
>>>>>>>>>>> patterns in a finite number of steps of correct simulation.
>>>>>>>>>>> Inputs that
>>>>>>>>>>> do terminate are simply simulated until they complete.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Except t doesn't o this for the "pathological" program.
>>>>>>>>>>
>>>>>>>>>> The "Pathological Program" when built on such a Decider that
>>>>>>>>>> does give an answer, which you say will be non-halting, and
>>>>>>>>>> then "Correctly Simulated" by giving it representation to a
>>>>>>>>>> UTM, we see that the simulation reaches a final state.
>>>>>>>>>>
>>>>>>>>>> Thus, your H was WRONG t make the answer. And the problem is
>>>>>>>>>> you have added a pattern that isn't always non-halting.
>>>>>>>>>>
>>>>>>>>>>> When a simulating halt decider correctly simulates N steps of
>>>>>>>>>>> its input
>>>>>>>>>>> it derives the exact same N steps that a pure UTM would
>>>>>>>>>>> derive because
>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>
>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the features
>>>>>>>>>> you added have removed essential features needed for it to be
>>>>>>>>>> an actual UTM. That you make this claim shows you don't
>>>>>>>>>> actually know what a UTM is.
>>>>>>>>>>
>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street Legal
>>>>>>>>>> vehicle, since it started as one and just had some extra
>>>>>>>>>> features axded.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> My reviewers cannot show that any of the extra features added
>>>>>>>>>>> to the UTM
>>>>>>>>>>> change the behavior of the simulated input for the first N
>>>>>>>>>>> steps of simulation:
>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't change it
>>>>>>>>>>> (c) Even aborting the simulation after N steps doesn't change
>>>>>>>>>>> the first N steps.
>>>>>>>>>>
>>>>>>>>>> No one claims that it doesn't correctly reproduce the first N
>>>>>>>>>> steps of the behavior, that is a Strawman argumen.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Because of all this we can know that the first N steps of
>>>>>>>>>>> input D
>>>>>>>>>>> simulated by simulating halt decider H are the actual
>>>>>>>>>>> behavior that D
>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>
>>>>>>>>>>> *computation that halts*… “the Turing machine will halt
>>>>>>>>>>> whenever it enters a final state” (Linz:1990:234)rrr
>>>>>>>>>>
>>>>>>>>>> Right, so we are concerned about the behavior of the ACTUAL
>>>>>>>>>> machine, not a partial simulation of it.
>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the answer is
>>>>>>>>>> wrong.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> When we see (after N steps) that D correctly simulated by H
>>>>>>>>>>> cannot
>>>>>>>>>>> possibly reach its simulated final state in any finite number
>>>>>>>>>>> of steps
>>>>>>>>>>> of correct simulation then we have conclusive proof that D
>>>>>>>>>>> presents non-
>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>
>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>> You agreed that the first N steps are correctly simulated.
>>>>>>>>>
>>>>>>>>> It turns out that the non-halting behavior pattern is correctly
>>>>>>>>> recognized in the first N steps.
>>>>>>>>
>>>>>>>> Your assumption that a program that calls H is non-halting is
>>>>>>>> erroneous:
>>>>>>>>
>>>>>>>
>>>>>>> My new paper anchors its ideas in actual Turing machines so it is
>>>>>>> unequivocal. The first two pages re only about the Linz Turing
>>>>>>> machine based proof.
>>>>>>>
>>>>>>> The H/D material is now on a single page and all reference
>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>> analysis entirely in C.
>>>>>>>
>>>>>>> With this new paper even Richard admits that the first N steps
>>>>>>> UTM based simulated by a simulating halt decider are necessarily the
>>>>>>> actual behavior of these N steps.
>>>>>>>
>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting Problem
>>>>>>> Proofs*
>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>
>>>>>>>> void Px(void (*x)())
>>>>>>>> {
>>>>>>>>      (void) H(x, x);
>>>>>>>>      return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> Px halts (it discards the result that H returns); your decider
>>>>>>>> thinks that Px is non-halting which is an obvious error due to a
>>>>>>>> design flaw in the architecture of your decider.  Only the
>>>>>>>> Flibble Signaling Simulating Halt Decider (SSHD) correctly
>>>>>>>> handles this case.
>>>>>>
>>>>>> Nope. For H to be a halt decider it must return a halt decision to
>>>>>> its caller in finite time
>>>>>
>>>>> Although H must always return to some caller H is not allowed to
>>>>> return
>>>>> to any caller that essentially calls H in infinite recursion.
>>>>
>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does not have
>>>> any infinite recursion thereby proving that
>>>
>>> It overrode that behavior that was specified by the machine code for Px.
>>
>> Nope. You SHD is not a halt decider as
>
> I was not even talking about my SHD, I was talking about how your
> program does its simulation incorrectly.

On 4/20/2023 12:32 PM, Mr Flibble wrote:
> On 19/04/2023 11:52 pm, olcott wrote:
>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>> A simulating halt decider correctly predicts whether or not its
>>>>>>>>>>>> correctly simulated input can possibly reach its own final
>>>>>>>>>>>> state and
>>>>>>>>>>>> halt. It does this by correctly recognizing several
>>>>>>>>>>>> non-halting behavior
>>>>>>>>>>>> patterns in a finite number of steps of correct simulation.
>>>>>>>>>>>> Inputs that
>>>>>>>>>>>> do terminate are simply simulated until they complete.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Except t doesn't o this for the "pathological" program.
>>>>>>>>>>>
>>>>>>>>>>> The "Pathological Program" when built on such a Decider that
>>>>>>>>>>> does give an answer, which you say will be non-halting, and
>>>>>>>>>>> then "Correctly Simulated" by giving it representation to a
>>>>>>>>>>> UTM, we see that the simulation reaches a final state.
>>>>>>>>>>>
>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the problem is
>>>>>>>>>>> you have added a pattern that isn't always non-halting.
>>>>>>>>>>>
>>>>>>>>>>>> When a simulating halt decider correctly simulates N steps
>>>>>>>>>>>> of its input
>>>>>>>>>>>> it derives the exact same N steps that a pure UTM would
>>>>>>>>>>>> derive because
>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>
>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the features
>>>>>>>>>>> you added have removed essential features needed for it to be
>>>>>>>>>>> an actual UTM. That you make this claim shows you don't
>>>>>>>>>>> actually know what a UTM is.
>>>>>>>>>>>
>>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street Legal
>>>>>>>>>>> vehicle, since it started as one and just had some extra
>>>>>>>>>>> features axded.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> My reviewers cannot show that any of the extra features
>>>>>>>>>>>> added to the UTM
>>>>>>>>>>>> change the behavior of the simulated input for the first N
>>>>>>>>>>>> steps of simulation:
>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't change it
>>>>>>>>>>>> (c) Even aborting the simulation after N steps doesn't
>>>>>>>>>>>> change the first N steps.
>>>>>>>>>>>
>>>>>>>>>>> No one claims that it doesn't correctly reproduce the first N
>>>>>>>>>>> steps of the behavior, that is a Strawman argumen.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Because of all this we can know that the first N steps of
>>>>>>>>>>>> input D
>>>>>>>>>>>> simulated by simulating halt decider H are the actual
>>>>>>>>>>>> behavior that D
>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>
>>>>>>>>>>>> *computation that halts*… “the Turing machine will halt
>>>>>>>>>>>> whenever it enters a final state” (Linz:1990:234)rrr
>>>>>>>>>>>
>>>>>>>>>>> Right, so we are concerned about the behavior of the ACTUAL
>>>>>>>>>>> machine, not a partial simulation of it.
>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the answer is
>>>>>>>>>>> wrong.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> When we see (after N steps) that D correctly simulated by H
>>>>>>>>>>>> cannot
>>>>>>>>>>>> possibly reach its simulated final state in any finite
>>>>>>>>>>>> number of steps
>>>>>>>>>>>> of correct simulation then we have conclusive proof that D
>>>>>>>>>>>> presents non-
>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>
>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>> You agreed that the first N steps are correctly simulated.
>>>>>>>>>>
>>>>>>>>>> It turns out that the non-halting behavior pattern is correctly
>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>
>>>>>>>>> Your assumption that a program that calls H is non-halting is
>>>>>>>>> erroneous:
>>>>>>>>>
>>>>>>>>
>>>>>>>> My new paper anchors its ideas in actual Turing machines so it is
>>>>>>>> unequivocal. The first two pages re only about the Linz Turing
>>>>>>>> machine based proof.
>>>>>>>>
>>>>>>>> The H/D material is now on a single page and all reference
>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>> analysis entirely in C.
>>>>>>>>
>>>>>>>> With this new paper even Richard admits that the first N steps
>>>>>>>> UTM based simulated by a simulating halt decider are necessarily
>>>>>>>> the
>>>>>>>> actual behavior of these N steps.
>>>>>>>>
>>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting Problem
>>>>>>>> Proofs*
>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>
>>>>>>>>> void Px(void (*x)())
>>>>>>>>> {
>>>>>>>>>      (void) H(x, x);
>>>>>>>>>      return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Px halts (it discards the result that H returns); your decider
>>>>>>>>> thinks that Px is non-halting which is an obvious error due to
>>>>>>>>> a design flaw in the architecture of your decider.  Only the
>>>>>>>>> Flibble Signaling Simulating Halt Decider (SSHD) correctly
>>>>>>>>> handles this case.
>>>>>>>
>>>>>>> Nope. For H to be a halt decider it must return a halt decision
>>>>>>> to its caller in finite time
>>>>>>
>>>>>> Although H must always return to some caller H is not allowed to
>>>>>> return
>>>>>> to any caller that essentially calls H in infinite recursion.
>>>>>
>>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does not have
>>>>> any infinite recursion thereby proving that
>>>>
>>>> It overrode that behavior that was specified by the machine code for
>>>> Px.
>>>
>>> Nope. You SHD is not a halt decider as
>>
>> I was not even talking about my SHD, I was talking about how your
>> program does its simulation incorrectly.
>
> My SSHD does not do its simulation incorrectly: it does its simulation
> just like I have defined it as evidenced by the fact that it returns a
> correct halting decision for Px; something your broken SHD gets wrong.
>

On 20/04/2023 6:49 pm, olcott wrote:
> On 4/20/2023 12:32 PM, Mr Flibble wrote:
>> On 19/04/2023 11:52 pm, olcott wrote:
>>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>>> A simulating halt decider correctly predicts whether or not
>>>>>>>>>>>>> its
>>>>>>>>>>>>> correctly simulated input can possibly reach its own final
>>>>>>>>>>>>> state and
>>>>>>>>>>>>> halt. It does this by correctly recognizing several
>>>>>>>>>>>>> non-halting behavior
>>>>>>>>>>>>> patterns in a finite number of steps of correct simulation.
>>>>>>>>>>>>> Inputs that
>>>>>>>>>>>>> do terminate are simply simulated until they complete.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Except t doesn't o this for the "pathological" program.
>>>>>>>>>>>>
>>>>>>>>>>>> The "Pathological Program" when built on such a Decider that
>>>>>>>>>>>> does give an answer, which you say will be non-halting, and
>>>>>>>>>>>> then "Correctly Simulated" by giving it representation to a
>>>>>>>>>>>> UTM, we see that the simulation reaches a final state.
>>>>>>>>>>>>
>>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the problem is
>>>>>>>>>>>> you have added a pattern that isn't always non-halting.
>>>>>>>>>>>>
>>>>>>>>>>>>> When a simulating halt decider correctly simulates N steps
>>>>>>>>>>>>> of its input
>>>>>>>>>>>>> it derives the exact same N steps that a pure UTM would
>>>>>>>>>>>>> derive because
>>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>>
>>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the features
>>>>>>>>>>>> you added have removed essential features needed for it to
>>>>>>>>>>>> be an actual UTM. That you make this claim shows you don't
>>>>>>>>>>>> actually know what a UTM is.
>>>>>>>>>>>>
>>>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street Legal
>>>>>>>>>>>> vehicle, since it started as one and just had some extra
>>>>>>>>>>>> features axded.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> My reviewers cannot show that any of the extra features
>>>>>>>>>>>>> added to the UTM
>>>>>>>>>>>>> change the behavior of the simulated input for the first N
>>>>>>>>>>>>> steps of simulation:
>>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't change it
>>>>>>>>>>>>> (c) Even aborting the simulation after N steps doesn't
>>>>>>>>>>>>> change the first N steps.
>>>>>>>>>>>>
>>>>>>>>>>>> No one claims that it doesn't correctly reproduce the first
>>>>>>>>>>>> N steps of the behavior, that is a Strawman argumen.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because of all this we can know that the first N steps of
>>>>>>>>>>>>> input D
>>>>>>>>>>>>> simulated by simulating halt decider H are the actual
>>>>>>>>>>>>> behavior that D
>>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *computation that halts*… “the Turing machine will halt
>>>>>>>>>>>>> whenever it enters a final state” (Linz:1990:234)rrr
>>>>>>>>>>>>
>>>>>>>>>>>> Right, so we are concerned about the behavior of the ACTUAL
>>>>>>>>>>>> machine, not a partial simulation of it.
>>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the answer is
>>>>>>>>>>>> wrong.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> When we see (after N steps) that D correctly simulated by H
>>>>>>>>>>>>> cannot
>>>>>>>>>>>>> possibly reach its simulated final state in any finite
>>>>>>>>>>>>> number of steps
>>>>>>>>>>>>> of correct simulation then we have conclusive proof that D
>>>>>>>>>>>>> presents non-
>>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>>
>>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>>> You agreed that the first N steps are correctly simulated.
>>>>>>>>>>>
>>>>>>>>>>> It turns out that the non-halting behavior pattern is correctly
>>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>>
>>>>>>>>>> Your assumption that a program that calls H is non-halting is
>>>>>>>>>> erroneous:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> My new paper anchors its ideas in actual Turing machines so it is
>>>>>>>>> unequivocal. The first two pages re only about the Linz Turing
>>>>>>>>> machine based proof.
>>>>>>>>>
>>>>>>>>> The H/D material is now on a single page and all reference
>>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>>> analysis entirely in C.
>>>>>>>>>
>>>>>>>>> With this new paper even Richard admits that the first N steps
>>>>>>>>> UTM based simulated by a simulating halt decider are
>>>>>>>>> necessarily the
>>>>>>>>> actual behavior of these N steps.
>>>>>>>>>
>>>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting Problem
>>>>>>>>> Proofs*
>>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>>
>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>> {
>>>>>>>>>>      (void) H(x, x);
>>>>>>>>>>      return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Px halts (it discards the result that H returns); your decider
>>>>>>>>>> thinks that Px is non-halting which is an obvious error due to
>>>>>>>>>> a design flaw in the architecture of your decider.  Only the
>>>>>>>>>> Flibble Signaling Simulating Halt Decider (SSHD) correctly
>>>>>>>>>> handles this case.
>>>>>>>>
>>>>>>>> Nope. For H to be a halt decider it must return a halt decision
>>>>>>>> to its caller in finite time
>>>>>>>
>>>>>>> Although H must always return to some caller H is not allowed to
>>>>>>> return
>>>>>>> to any caller that essentially calls H in infinite recursion.
>>>>>>
>>>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does not have
>>>>>> any infinite recursion thereby proving that
>>>>>
>>>>> It overrode that behavior that was specified by the machine code
>>>>> for Px.
>>>>
>>>> Nope. You SHD is not a halt decider as
>>>
>>> I was not even talking about my SHD, I was talking about how your
>>> program does its simulation incorrectly.
>>
>> My SSHD does not do its simulation incorrectly: it does its simulation
>> just like I have defined it as evidenced by the fact that it returns a
>> correct halting decision for Px; something your broken SHD gets wrong.
>>
>
> In order for you to have Px simulated by H terminate normally you must
> change the behavior of Px away from the behavior that its x86 code
> specifies.

On 4/20/2023 2:08 PM, Mr Flibble wrote:
> On 20/04/2023 6:49 pm, olcott wrote:
>> On 4/20/2023 12:32 PM, Mr Flibble wrote:
>>> On 19/04/2023 11:52 pm, olcott wrote:
>>>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>>>> A simulating halt decider correctly predicts whether or
>>>>>>>>>>>>>> not its
>>>>>>>>>>>>>> correctly simulated input can possibly reach its own final
>>>>>>>>>>>>>> state and
>>>>>>>>>>>>>> halt. It does this by correctly recognizing several
>>>>>>>>>>>>>> non-halting behavior
>>>>>>>>>>>>>> patterns in a finite number of steps of correct
>>>>>>>>>>>>>> simulation. Inputs that
>>>>>>>>>>>>>> do terminate are simply simulated until they complete.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Except t doesn't o this for the "pathological" program.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The "Pathological Program" when built on such a Decider
>>>>>>>>>>>>> that does give an answer, which you say will be
>>>>>>>>>>>>> non-halting, and then "Correctly Simulated" by giving it
>>>>>>>>>>>>> representation to a UTM, we see that the simulation reaches
>>>>>>>>>>>>> a final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the problem
>>>>>>>>>>>>> is you have added a pattern that isn't always non-halting.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> When a simulating halt decider correctly simulates N steps
>>>>>>>>>>>>>> of its input
>>>>>>>>>>>>>> it derives the exact same N steps that a pure UTM would
>>>>>>>>>>>>>> derive because
>>>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the features
>>>>>>>>>>>>> you added have removed essential features needed for it to
>>>>>>>>>>>>> be an actual UTM. That you make this claim shows you don't
>>>>>>>>>>>>> actually know what a UTM is.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street Legal
>>>>>>>>>>>>> vehicle, since it started as one and just had some extra
>>>>>>>>>>>>> features axded.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> My reviewers cannot show that any of the extra features
>>>>>>>>>>>>>> added to the UTM
>>>>>>>>>>>>>> change the behavior of the simulated input for the first N
>>>>>>>>>>>>>> steps of simulation:
>>>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't change it
>>>>>>>>>>>>>> (c) Even aborting the simulation after N steps doesn't
>>>>>>>>>>>>>> change the first N steps.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No one claims that it doesn't correctly reproduce the first
>>>>>>>>>>>>> N steps of the behavior, that is a Strawman argumen.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because of all this we can know that the first N steps of
>>>>>>>>>>>>>> input D
>>>>>>>>>>>>>> simulated by simulating halt decider H are the actual
>>>>>>>>>>>>>> behavior that D
>>>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *computation that halts*… “the Turing machine will halt
>>>>>>>>>>>>>> whenever it enters a final state” (Linz:1990:234)rrr
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, so we are concerned about the behavior of the ACTUAL
>>>>>>>>>>>>> machine, not a partial simulation of it.
>>>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the answer
>>>>>>>>>>>>> is wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When we see (after N steps) that D correctly simulated by
>>>>>>>>>>>>>> H cannot
>>>>>>>>>>>>>> possibly reach its simulated final state in any finite
>>>>>>>>>>>>>> number of steps
>>>>>>>>>>>>>> of correct simulation then we have conclusive proof that D
>>>>>>>>>>>>>> presents non-
>>>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>>>> You agreed that the first N steps are correctly simulated.
>>>>>>>>>>>>
>>>>>>>>>>>> It turns out that the non-halting behavior pattern is correctly
>>>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>>>
>>>>>>>>>>> Your assumption that a program that calls H is non-halting is
>>>>>>>>>>> erroneous:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> My new paper anchors its ideas in actual Turing machines so it is
>>>>>>>>>> unequivocal. The first two pages re only about the Linz Turing
>>>>>>>>>> machine based proof.
>>>>>>>>>>
>>>>>>>>>> The H/D material is now on a single page and all reference
>>>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>>>> analysis entirely in C.
>>>>>>>>>>
>>>>>>>>>> With this new paper even Richard admits that the first N steps
>>>>>>>>>> UTM based simulated by a simulating halt decider are
>>>>>>>>>> necessarily the
>>>>>>>>>> actual behavior of these N steps.
>>>>>>>>>>
>>>>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting Problem
>>>>>>>>>> Proofs*
>>>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>>>
>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>> {
>>>>>>>>>>>      (void) H(x, x);
>>>>>>>>>>>      return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Px halts (it discards the result that H returns); your
>>>>>>>>>>> decider thinks that Px is non-halting which is an obvious
>>>>>>>>>>> error due to a design flaw in the architecture of your
>>>>>>>>>>> decider.  Only the Flibble Signaling Simulating Halt Decider
>>>>>>>>>>> (SSHD) correctly handles this case.
>>>>>>>>>
>>>>>>>>> Nope. For H to be a halt decider it must return a halt decision
>>>>>>>>> to its caller in finite time
>>>>>>>>
>>>>>>>> Although H must always return to some caller H is not allowed to
>>>>>>>> return
>>>>>>>> to any caller that essentially calls H in infinite recursion.
>>>>>>>
>>>>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does not
>>>>>>> have any infinite recursion thereby proving that
>>>>>>
>>>>>> It overrode that behavior that was specified by the machine code
>>>>>> for Px.
>>>>>
>>>>> Nope. You SHD is not a halt decider as
>>>>
>>>> I was not even talking about my SHD, I was talking about how your
>>>> program does its simulation incorrectly.
>>>
>>> My SSHD does not do its simulation incorrectly: it does its
>>> simulation just like I have defined it as evidenced by the fact that
>>> it returns a correct halting decision for Px; something your broken
>>> SHD gets wrong.
>>>
>>
>> In order for you to have Px simulated by H terminate normally you must
>> change the behavior of Px away from the behavior that its x86 code
>> specifies.
>
> Your "x86 code" has nothing to do with how my halt decider works; I am
> using an entirely different simulation method, one that actually works.
>
>>
>> void Px(void (*x)())
>> {
>>    (void) H(x, x);
>>    return;
>> }
>>
>> Px correctly simulated by H cannot possibly reach past its machine
>> address of: [00001b3d].
>>
>> _Px()
>> [00001b32] 55         push ebp
>> [00001b33] 8bec       mov ebp,esp
>> [00001b35] 8b4508     mov eax,[ebp+08]
>> [00001b38] 50         push eax      // push address of Px
>> [00001b39] 8b4d08     mov ecx,[ebp+08]
>> [00001b3c] 51         push ecx      // push address of Px
>> [00001b3d] e800faffff call 00001542 // Call H
>> [00001b42] 83c408     add esp,+08
>> [00001b45] 5d         pop ebp
>> [00001b46] c3         ret
>> Size in bytes:(0021) [00001b46]
>>
>> What you are doing is the the same as recognizing that _Infinite_Loop()
>> never halts, forcing it to break out of its infinite loop and jump to
>> its "ret" instruction
>>
>> _Infinite_Loop()
>> [00001c62] 55         push ebp
>> [00001c63] 8bec       mov ebp,esp
>> [00001c65] ebfe       jmp 00001c65
>> [00001c67] 5d         pop ebp
>> [00001c68] c3         ret
>> Size in bytes:(0007) [00001c68]
>
> No I am not: there is no infinite loop in Px above; forking the
> simulation into two branches and returning a different halt decision to
> each branch is a perfectly valid SHD design; again a design, unlike
> yours, that actually works.

On 20/04/2023 8:20 pm, olcott wrote:
> On 4/20/2023 2:08 PM, Mr Flibble wrote:
>> On 20/04/2023 6:49 pm, olcott wrote:
>>> On 4/20/2023 12:32 PM, Mr Flibble wrote:
>>>> On 19/04/2023 11:52 pm, olcott wrote:
>>>>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>>>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>>>>> A simulating halt decider correctly predicts whether or
>>>>>>>>>>>>>>> not its
>>>>>>>>>>>>>>> correctly simulated input can possibly reach its own
>>>>>>>>>>>>>>> final state and
>>>>>>>>>>>>>>> halt. It does this by correctly recognizing several
>>>>>>>>>>>>>>> non-halting behavior
>>>>>>>>>>>>>>> patterns in a finite number of steps of correct
>>>>>>>>>>>>>>> simulation. Inputs that
>>>>>>>>>>>>>>> do terminate are simply simulated until they complete.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Except t doesn't o this for the "pathological" program.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The "Pathological Program" when built on such a Decider
>>>>>>>>>>>>>> that does give an answer, which you say will be
>>>>>>>>>>>>>> non-halting, and then "Correctly Simulated" by giving it
>>>>>>>>>>>>>> representation to a UTM, we see that the simulation
>>>>>>>>>>>>>> reaches a final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the problem
>>>>>>>>>>>>>> is you have added a pattern that isn't always non-halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When a simulating halt decider correctly simulates N
>>>>>>>>>>>>>>> steps of its input
>>>>>>>>>>>>>>> it derives the exact same N steps that a pure UTM would
>>>>>>>>>>>>>>> derive because
>>>>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the
>>>>>>>>>>>>>> features you added have removed essential features needed
>>>>>>>>>>>>>> for it to be an actual UTM. That you make this claim shows
>>>>>>>>>>>>>> you don't actually know what a UTM is.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street Legal
>>>>>>>>>>>>>> vehicle, since it started as one and just had some extra
>>>>>>>>>>>>>> features axded.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My reviewers cannot show that any of the extra features
>>>>>>>>>>>>>>> added to the UTM
>>>>>>>>>>>>>>> change the behavior of the simulated input for the first
>>>>>>>>>>>>>>> N steps of simulation:
>>>>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't change it
>>>>>>>>>>>>>>> (c) Even aborting the simulation after N steps doesn't
>>>>>>>>>>>>>>> change the first N steps.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No one claims that it doesn't correctly reproduce the
>>>>>>>>>>>>>> first N steps of the behavior, that is a Strawman argumen.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because of all this we can know that the first N steps of
>>>>>>>>>>>>>>> input D
>>>>>>>>>>>>>>> simulated by simulating halt decider H are the actual
>>>>>>>>>>>>>>> behavior that D
>>>>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *computation that halts*… “the Turing machine will halt
>>>>>>>>>>>>>>> whenever it enters a final state” (Linz:1990:234)rrr
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, so we are concerned about the behavior of the
>>>>>>>>>>>>>> ACTUAL machine, not a partial simulation of it.
>>>>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the answer
>>>>>>>>>>>>>> is wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When we see (after N steps) that D correctly simulated by
>>>>>>>>>>>>>>> H cannot
>>>>>>>>>>>>>>> possibly reach its simulated final state in any finite
>>>>>>>>>>>>>>> number of steps
>>>>>>>>>>>>>>> of correct simulation then we have conclusive proof that
>>>>>>>>>>>>>>> D presents non-
>>>>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>>>>> You agreed that the first N steps are correctly simulated.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It turns out that the non-halting behavior pattern is
>>>>>>>>>>>>> correctly
>>>>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>>>>
>>>>>>>>>>>> Your assumption that a program that calls H is non-halting
>>>>>>>>>>>> is erroneous:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> My new paper anchors its ideas in actual Turing machines so
>>>>>>>>>>> it is
>>>>>>>>>>> unequivocal. The first two pages re only about the Linz Turing
>>>>>>>>>>> machine based proof.
>>>>>>>>>>>
>>>>>>>>>>> The H/D material is now on a single page and all reference
>>>>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>>>>> analysis entirely in C.
>>>>>>>>>>>
>>>>>>>>>>> With this new paper even Richard admits that the first N steps
>>>>>>>>>>> UTM based simulated by a simulating halt decider are
>>>>>>>>>>> necessarily the
>>>>>>>>>>> actual behavior of these N steps.
>>>>>>>>>>>
>>>>>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting
>>>>>>>>>>> Problem Proofs*
>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>>>>
>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>> {
>>>>>>>>>>>>      (void) H(x, x);
>>>>>>>>>>>>      return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> Px halts (it discards the result that H returns); your
>>>>>>>>>>>> decider thinks that Px is non-halting which is an obvious
>>>>>>>>>>>> error due to a design flaw in the architecture of your
>>>>>>>>>>>> decider.  Only the Flibble Signaling Simulating Halt Decider
>>>>>>>>>>>> (SSHD) correctly handles this case.
>>>>>>>>>>
>>>>>>>>>> Nope. For H to be a halt decider it must return a halt
>>>>>>>>>> decision to its caller in finite time
>>>>>>>>>
>>>>>>>>> Although H must always return to some caller H is not allowed
>>>>>>>>> to return
>>>>>>>>> to any caller that essentially calls H in infinite recursion.
>>>>>>>>
>>>>>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does not
>>>>>>>> have any infinite recursion thereby proving that
>>>>>>>
>>>>>>> It overrode that behavior that was specified by the machine code
>>>>>>> for Px.
>>>>>>
>>>>>> Nope. You SHD is not a halt decider as
>>>>>
>>>>> I was not even talking about my SHD, I was talking about how your
>>>>> program does its simulation incorrectly.
>>>>
>>>> My SSHD does not do its simulation incorrectly: it does its
>>>> simulation just like I have defined it as evidenced by the fact that
>>>> it returns a correct halting decision for Px; something your broken
>>>> SHD gets wrong.
>>>>
>>>
>>> In order for you to have Px simulated by H terminate normally you
>>> must change the behavior of Px away from the behavior that its x86
>>> code specifies.
>>
>> Your "x86 code" has nothing to do with how my halt decider works; I am
>> using an entirely different simulation method, one that actually works.
>>
>>>
>>> void Px(void (*x)())
>>> {
>>>    (void) H(x, x);
>>>    return;
>>> }
>>>
>>> Px correctly simulated by H cannot possibly reach past its machine
>>> address of: [00001b3d].
>>>
>>> _Px()
>>> [00001b32] 55         push ebp
>>> [00001b33] 8bec       mov ebp,esp
>>> [00001b35] 8b4508     mov eax,[ebp+08]
>>> [00001b38] 50         push eax      // push address of Px
>>> [00001b39] 8b4d08     mov ecx,[ebp+08]
>>> [00001b3c] 51         push ecx      // push address of Px
>>> [00001b3d] e800faffff call 00001542 // Call H
>>> [00001b42] 83c408     add esp,+08
>>> [00001b45] 5d         pop ebp
>>> [00001b46] c3         ret
>>> Size in bytes:(0021) [00001b46]
>>>
>>> What you are doing is the the same as recognizing that _Infinite_Loop()
>>> never halts, forcing it to break out of its infinite loop and jump to
>>> its "ret" instruction
>>>
>>> _Infinite_Loop()
>>> [00001c62] 55         push ebp
>>> [00001c63] 8bec       mov ebp,esp
>>> [00001c65] ebfe       jmp 00001c65
>>> [00001c67] 5d         pop ebp
>>> [00001c68] c3         ret
>>> Size in bytes:(0007) [00001c68]
>>
>> No I am not: there is no infinite loop in Px above; forking the
>> simulation into two branches and returning a different halt decision
>> to each branch is a perfectly valid SHD design; again a design, unlike
>> yours, that actually works.
>
> If you say that Px correctly simulated by H ever reaches its own final
> "return" statement and halts you are incorrect.

On 4/21/2023 7:17 AM, Mr Flibble wrote:
> On 20/04/2023 8:20 pm, olcott wrote:
>> On 4/20/2023 2:08 PM, Mr Flibble wrote:
>>> On 20/04/2023 6:49 pm, olcott wrote:
>>>> On 4/20/2023 12:32 PM, Mr Flibble wrote:
>>>>> On 19/04/2023 11:52 pm, olcott wrote:
>>>>>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>>>>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>>>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>>>>>> A simulating halt decider correctly predicts whether or
>>>>>>>>>>>>>>>> not its
>>>>>>>>>>>>>>>> correctly simulated input can possibly reach its own
>>>>>>>>>>>>>>>> final state and
>>>>>>>>>>>>>>>> halt. It does this by correctly recognizing several
>>>>>>>>>>>>>>>> non-halting behavior
>>>>>>>>>>>>>>>> patterns in a finite number of steps of correct
>>>>>>>>>>>>>>>> simulation. Inputs that
>>>>>>>>>>>>>>>> do terminate are simply simulated until they complete.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Except t doesn't o this for the "pathological" program.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The "Pathological Program" when built on such a Decider
>>>>>>>>>>>>>>> that does give an answer, which you say will be
>>>>>>>>>>>>>>> non-halting, and then "Correctly Simulated" by giving it
>>>>>>>>>>>>>>> representation to a UTM, we see that the simulation
>>>>>>>>>>>>>>> reaches a final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the problem
>>>>>>>>>>>>>>> is you have added a pattern that isn't always non-halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When a simulating halt decider correctly simulates N
>>>>>>>>>>>>>>>> steps of its input
>>>>>>>>>>>>>>>> it derives the exact same N steps that a pure UTM would
>>>>>>>>>>>>>>>> derive because
>>>>>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the
>>>>>>>>>>>>>>> features you added have removed essential features needed
>>>>>>>>>>>>>>> for it to be an actual UTM. That you make this claim
>>>>>>>>>>>>>>> shows you don't actually know what a UTM is.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street Legal
>>>>>>>>>>>>>>> vehicle, since it started as one and just had some extra
>>>>>>>>>>>>>>> features axded.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> My reviewers cannot show that any of the extra features
>>>>>>>>>>>>>>>> added to the UTM
>>>>>>>>>>>>>>>> change the behavior of the simulated input for the first
>>>>>>>>>>>>>>>> N steps of simulation:
>>>>>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't
>>>>>>>>>>>>>>>> change it
>>>>>>>>>>>>>>>> (c) Even aborting the simulation after N steps doesn't
>>>>>>>>>>>>>>>> change the first N steps.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No one claims that it doesn't correctly reproduce the
>>>>>>>>>>>>>>> first N steps of the behavior, that is a Strawman argumen.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because of all this we can know that the first N steps
>>>>>>>>>>>>>>>> of input D
>>>>>>>>>>>>>>>> simulated by simulating halt decider H are the actual
>>>>>>>>>>>>>>>> behavior that D
>>>>>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *computation that halts*… “the Turing machine will halt
>>>>>>>>>>>>>>>> whenever it enters a final state” (Linz:1990:234)rrr
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right, so we are concerned about the behavior of the
>>>>>>>>>>>>>>> ACTUAL machine, not a partial simulation of it.
>>>>>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the answer
>>>>>>>>>>>>>>> is wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When we see (after N steps) that D correctly simulated
>>>>>>>>>>>>>>>> by H cannot
>>>>>>>>>>>>>>>> possibly reach its simulated final state in any finite
>>>>>>>>>>>>>>>> number of steps
>>>>>>>>>>>>>>>> of correct simulation then we have conclusive proof that
>>>>>>>>>>>>>>>> D presents non-
>>>>>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>>>>>> You agreed that the first N steps are correctly simulated.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It turns out that the non-halting behavior pattern is
>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Your assumption that a program that calls H is non-halting
>>>>>>>>>>>>> is erroneous:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> My new paper anchors its ideas in actual Turing machines so
>>>>>>>>>>>> it is
>>>>>>>>>>>> unequivocal. The first two pages re only about the Linz Turing
>>>>>>>>>>>> machine based proof.
>>>>>>>>>>>>
>>>>>>>>>>>> The H/D material is now on a single page and all reference
>>>>>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>>>>>> analysis entirely in C.
>>>>>>>>>>>>
>>>>>>>>>>>> With this new paper even Richard admits that the first N steps
>>>>>>>>>>>> UTM based simulated by a simulating halt decider are
>>>>>>>>>>>> necessarily the
>>>>>>>>>>>> actual behavior of these N steps.
>>>>>>>>>>>>
>>>>>>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting
>>>>>>>>>>>> Problem Proofs*
>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>>>>>
>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>> {
>>>>>>>>>>>>>      (void) H(x, x);
>>>>>>>>>>>>>      return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Px halts (it discards the result that H returns); your
>>>>>>>>>>>>> decider thinks that Px is non-halting which is an obvious
>>>>>>>>>>>>> error due to a design flaw in the architecture of your
>>>>>>>>>>>>> decider.  Only the Flibble Signaling Simulating Halt
>>>>>>>>>>>>> Decider (SSHD) correctly handles this case.
>>>>>>>>>>>
>>>>>>>>>>> Nope. For H to be a halt decider it must return a halt
>>>>>>>>>>> decision to its caller in finite time
>>>>>>>>>>
>>>>>>>>>> Although H must always return to some caller H is not allowed
>>>>>>>>>> to return
>>>>>>>>>> to any caller that essentially calls H in infinite recursion.
>>>>>>>>>
>>>>>>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does not
>>>>>>>>> have any infinite recursion thereby proving that
>>>>>>>>
>>>>>>>> It overrode that behavior that was specified by the machine code
>>>>>>>> for Px.
>>>>>>>
>>>>>>> Nope. You SHD is not a halt decider as
>>>>>>
>>>>>> I was not even talking about my SHD, I was talking about how your
>>>>>> program does its simulation incorrectly.
>>>>>
>>>>> My SSHD does not do its simulation incorrectly: it does its
>>>>> simulation just like I have defined it as evidenced by the fact
>>>>> that it returns a correct halting decision for Px; something your
>>>>> broken SHD gets wrong.
>>>>>
>>>>
>>>> In order for you to have Px simulated by H terminate normally you
>>>> must change the behavior of Px away from the behavior that its x86
>>>> code specifies.
>>>
>>> Your "x86 code" has nothing to do with how my halt decider works; I
>>> am using an entirely different simulation method, one that actually
>>> works.
>>>
>>>>
>>>> void Px(void (*x)())
>>>> {
>>>>    (void) H(x, x);
>>>>    return;
>>>> }
>>>>
>>>> Px correctly simulated by H cannot possibly reach past its machine
>>>> address of: [00001b3d].
>>>>
>>>> _Px()
>>>> [00001b32] 55         push ebp
>>>> [00001b33] 8bec       mov ebp,esp
>>>> [00001b35] 8b4508     mov eax,[ebp+08]
>>>> [00001b38] 50         push eax      // push address of Px
>>>> [00001b39] 8b4d08     mov ecx,[ebp+08]
>>>> [00001b3c] 51         push ecx      // push address of Px
>>>> [00001b3d] e800faffff call 00001542 // Call H
>>>> [00001b42] 83c408     add esp,+08
>>>> [00001b45] 5d         pop ebp
>>>> [00001b46] c3         ret
>>>> Size in bytes:(0021) [00001b46]
>>>>
>>>> What you are doing is the the same as recognizing that _Infinite_Loop()
>>>> never halts, forcing it to break out of its infinite loop and jump to
>>>> its "ret" instruction
>>>>
>>>> _Infinite_Loop()
>>>> [00001c62] 55         push ebp
>>>> [00001c63] 8bec       mov ebp,esp
>>>> [00001c65] ebfe       jmp 00001c65
>>>> [00001c67] 5d         pop ebp
>>>> [00001c68] c3         ret
>>>> Size in bytes:(0007) [00001c68]
>>>
>>> No I am not: there is no infinite loop in Px above; forking the
>>> simulation into two branches and returning a different halt decision
>>> to each branch is a perfectly valid SHD design; again a design,
>>> unlike yours, that actually works.
>>
>> If you say that Px correctly simulated by H ever reaches its own final
>> "return" statement and halts you are incorrect.
>
> Px halts if H is (or is part of) a genuine halt decider.

On 21/04/2023 4:16 pm, olcott wrote:
> On 4/21/2023 7:17 AM, Mr Flibble wrote:
>> On 20/04/2023 8:20 pm, olcott wrote:
>>> On 4/20/2023 2:08 PM, Mr Flibble wrote:
>>>> On 20/04/2023 6:49 pm, olcott wrote:
>>>>> On 4/20/2023 12:32 PM, Mr Flibble wrote:
>>>>>> On 19/04/2023 11:52 pm, olcott wrote:
>>>>>>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>>>>>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>>>>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>>>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>>>>>>> A simulating halt decider correctly predicts whether or
>>>>>>>>>>>>>>>>> not its
>>>>>>>>>>>>>>>>> correctly simulated input can possibly reach its own
>>>>>>>>>>>>>>>>> final state and
>>>>>>>>>>>>>>>>> halt. It does this by correctly recognizing several
>>>>>>>>>>>>>>>>> non-halting behavior
>>>>>>>>>>>>>>>>> patterns in a finite number of steps of correct
>>>>>>>>>>>>>>>>> simulation. Inputs that
>>>>>>>>>>>>>>>>> do terminate are simply simulated until they complete.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except t doesn't o this for the "pathological" program.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The "Pathological Program" when built on such a Decider
>>>>>>>>>>>>>>>> that does give an answer, which you say will be
>>>>>>>>>>>>>>>> non-halting, and then "Correctly Simulated" by giving it
>>>>>>>>>>>>>>>> representation to a UTM, we see that the simulation
>>>>>>>>>>>>>>>> reaches a final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the
>>>>>>>>>>>>>>>> problem is you have added a pattern that isn't always
>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When a simulating halt decider correctly simulates N
>>>>>>>>>>>>>>>>> steps of its input
>>>>>>>>>>>>>>>>> it derives the exact same N steps that a pure UTM would
>>>>>>>>>>>>>>>>> derive because
>>>>>>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the
>>>>>>>>>>>>>>>> features you added have removed essential features
>>>>>>>>>>>>>>>> needed for it to be an actual UTM. That you make this
>>>>>>>>>>>>>>>> claim shows you don't actually know what a UTM is.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street
>>>>>>>>>>>>>>>> Legal vehicle, since it started as one and just had some
>>>>>>>>>>>>>>>> extra features axded.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> My reviewers cannot show that any of the extra features
>>>>>>>>>>>>>>>>> added to the UTM
>>>>>>>>>>>>>>>>> change the behavior of the simulated input for the
>>>>>>>>>>>>>>>>> first N steps of simulation:
>>>>>>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't
>>>>>>>>>>>>>>>>> change it
>>>>>>>>>>>>>>>>> (c) Even aborting the simulation after N steps doesn't
>>>>>>>>>>>>>>>>> change the first N steps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No one claims that it doesn't correctly reproduce the
>>>>>>>>>>>>>>>> first N steps of the behavior, that is a Strawman argumen.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because of all this we can know that the first N steps
>>>>>>>>>>>>>>>>> of input D
>>>>>>>>>>>>>>>>> simulated by simulating halt decider H are the actual
>>>>>>>>>>>>>>>>> behavior that D
>>>>>>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *computation that halts*… “the Turing machine will halt
>>>>>>>>>>>>>>>>> whenever it enters a final state” (Linz:1990:234)rrr
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Right, so we are concerned about the behavior of the
>>>>>>>>>>>>>>>> ACTUAL machine, not a partial simulation of it.
>>>>>>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the
>>>>>>>>>>>>>>>> answer is wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When we see (after N steps) that D correctly simulated
>>>>>>>>>>>>>>>>> by H cannot
>>>>>>>>>>>>>>>>> possibly reach its simulated final state in any finite
>>>>>>>>>>>>>>>>> number of steps
>>>>>>>>>>>>>>>>> of correct simulation then we have conclusive proof
>>>>>>>>>>>>>>>>> that D presents non-
>>>>>>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>>>>>>> You agreed that the first N steps are correctly simulated.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It turns out that the non-halting behavior pattern is
>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Your assumption that a program that calls H is non-halting
>>>>>>>>>>>>>> is erroneous:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> My new paper anchors its ideas in actual Turing machines so
>>>>>>>>>>>>> it is
>>>>>>>>>>>>> unequivocal. The first two pages re only about the Linz Turing
>>>>>>>>>>>>> machine based proof.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The H/D material is now on a single page and all reference
>>>>>>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>>>>>>> analysis entirely in C.
>>>>>>>>>>>>>
>>>>>>>>>>>>> With this new paper even Richard admits that the first N steps
>>>>>>>>>>>>> UTM based simulated by a simulating halt decider are
>>>>>>>>>>>>> necessarily the
>>>>>>>>>>>>> actual behavior of these N steps.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting
>>>>>>>>>>>>> Problem Proofs*
>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>>>>>>
>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>      (void) H(x, x);
>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Px halts (it discards the result that H returns); your
>>>>>>>>>>>>>> decider thinks that Px is non-halting which is an obvious
>>>>>>>>>>>>>> error due to a design flaw in the architecture of your
>>>>>>>>>>>>>> decider.  Only the Flibble Signaling Simulating Halt
>>>>>>>>>>>>>> Decider (SSHD) correctly handles this case.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope. For H to be a halt decider it must return a halt
>>>>>>>>>>>> decision to its caller in finite time
>>>>>>>>>>>
>>>>>>>>>>> Although H must always return to some caller H is not allowed
>>>>>>>>>>> to return
>>>>>>>>>>> to any caller that essentially calls H in infinite recursion.
>>>>>>>>>>
>>>>>>>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does not
>>>>>>>>>> have any infinite recursion thereby proving that
>>>>>>>>>
>>>>>>>>> It overrode that behavior that was specified by the machine
>>>>>>>>> code for Px.
>>>>>>>>
>>>>>>>> Nope. You SHD is not a halt decider as
>>>>>>>
>>>>>>> I was not even talking about my SHD, I was talking about how your
>>>>>>> program does its simulation incorrectly.
>>>>>>
>>>>>> My SSHD does not do its simulation incorrectly: it does its
>>>>>> simulation just like I have defined it as evidenced by the fact
>>>>>> that it returns a correct halting decision for Px; something your
>>>>>> broken SHD gets wrong.
>>>>>>
>>>>>
>>>>> In order for you to have Px simulated by H terminate normally you
>>>>> must change the behavior of Px away from the behavior that its x86
>>>>> code specifies.
>>>>
>>>> Your "x86 code" has nothing to do with how my halt decider works; I
>>>> am using an entirely different simulation method, one that actually
>>>> works.
>>>>
>>>>>
>>>>> void Px(void (*x)())
>>>>> {
>>>>>    (void) H(x, x);
>>>>>    return;
>>>>> }
>>>>>
>>>>> Px correctly simulated by H cannot possibly reach past its machine
>>>>> address of: [00001b3d].
>>>>>
>>>>> _Px()
>>>>> [00001b32] 55         push ebp
>>>>> [00001b33] 8bec       mov ebp,esp
>>>>> [00001b35] 8b4508     mov eax,[ebp+08]
>>>>> [00001b38] 50         push eax      // push address of Px
>>>>> [00001b39] 8b4d08     mov ecx,[ebp+08]
>>>>> [00001b3c] 51         push ecx      // push address of Px
>>>>> [00001b3d] e800faffff call 00001542 // Call H
>>>>> [00001b42] 83c408     add esp,+08
>>>>> [00001b45] 5d         pop ebp
>>>>> [00001b46] c3         ret
>>>>> Size in bytes:(0021) [00001b46]
>>>>>
>>>>> What you are doing is the the same as recognizing that
>>>>> _Infinite_Loop()
>>>>> never halts, forcing it to break out of its infinite loop and jump to
>>>>> its "ret" instruction
>>>>>
>>>>> _Infinite_Loop()
>>>>> [00001c62] 55         push ebp
>>>>> [00001c63] 8bec       mov ebp,esp
>>>>> [00001c65] ebfe       jmp 00001c65
>>>>> [00001c67] 5d         pop ebp
>>>>> [00001c68] c3         ret
>>>>> Size in bytes:(0007) [00001c68]
>>>>
>>>> No I am not: there is no infinite loop in Px above; forking the
>>>> simulation into two branches and returning a different halt decision
>>>> to each branch is a perfectly valid SHD design; again a design,
>>>> unlike yours, that actually works.
>>>
>>> If you say that Px correctly simulated by H ever reaches its own final
>>> "return" statement and halts you are incorrect.
>>
>> Px halts if H is (or is part of) a genuine halt decider.
>
> The simulated Px only halts if it reaches its own final state in a
> finite number of steps of correct simulation. It can't possibly do this.

On 4/21/2023 11:36 AM, Mr Flibble wrote:
> On 21/04/2023 4:16 pm, olcott wrote:
>> On 4/21/2023 7:17 AM, Mr Flibble wrote:
>>> On 20/04/2023 8:20 pm, olcott wrote:
>>>> On 4/20/2023 2:08 PM, Mr Flibble wrote:
>>>>> On 20/04/2023 6:49 pm, olcott wrote:
>>>>>> On 4/20/2023 12:32 PM, Mr Flibble wrote:
>>>>>>> On 19/04/2023 11:52 pm, olcott wrote:
>>>>>>>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>>>>>>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>>>>>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>>>>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>>>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>>>>>>>> A simulating halt decider correctly predicts whether
>>>>>>>>>>>>>>>>>> or not its
>>>>>>>>>>>>>>>>>> correctly simulated input can possibly reach its own
>>>>>>>>>>>>>>>>>> final state and
>>>>>>>>>>>>>>>>>> halt. It does this by correctly recognizing several
>>>>>>>>>>>>>>>>>> non-halting behavior
>>>>>>>>>>>>>>>>>> patterns in a finite number of steps of correct
>>>>>>>>>>>>>>>>>> simulation. Inputs that
>>>>>>>>>>>>>>>>>> do terminate are simply simulated until they complete.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Except t doesn't o this for the "pathological" program.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The "Pathological Program" when built on such a Decider
>>>>>>>>>>>>>>>>> that does give an answer, which you say will be
>>>>>>>>>>>>>>>>> non-halting, and then "Correctly Simulated" by giving
>>>>>>>>>>>>>>>>> it representation to a UTM, we see that the simulation
>>>>>>>>>>>>>>>>> reaches a final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the
>>>>>>>>>>>>>>>>> problem is you have added a pattern that isn't always
>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When a simulating halt decider correctly simulates N
>>>>>>>>>>>>>>>>>> steps of its input
>>>>>>>>>>>>>>>>>> it derives the exact same N steps that a pure UTM
>>>>>>>>>>>>>>>>>> would derive because
>>>>>>>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the
>>>>>>>>>>>>>>>>> features you added have removed essential features
>>>>>>>>>>>>>>>>> needed for it to be an actual UTM. That you make this
>>>>>>>>>>>>>>>>> claim shows you don't actually know what a UTM is.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street
>>>>>>>>>>>>>>>>> Legal vehicle, since it started as one and just had
>>>>>>>>>>>>>>>>> some extra features axded.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> My reviewers cannot show that any of the extra
>>>>>>>>>>>>>>>>>> features added to the UTM
>>>>>>>>>>>>>>>>>> change the behavior of the simulated input for the
>>>>>>>>>>>>>>>>>> first N steps of simulation:
>>>>>>>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't
>>>>>>>>>>>>>>>>>> change it
>>>>>>>>>>>>>>>>>> (c) Even aborting the simulation after N steps doesn't
>>>>>>>>>>>>>>>>>> change the first N steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No one claims that it doesn't correctly reproduce the
>>>>>>>>>>>>>>>>> first N steps of the behavior, that is a Strawman argumen.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Because of all this we can know that the first N steps
>>>>>>>>>>>>>>>>>> of input D
>>>>>>>>>>>>>>>>>> simulated by simulating halt decider H are the actual
>>>>>>>>>>>>>>>>>> behavior that D
>>>>>>>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *computation that halts*… “the Turing machine will
>>>>>>>>>>>>>>>>>> halt whenever it enters a final state” (Linz:1990:234)rrr
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Right, so we are concerned about the behavior of the
>>>>>>>>>>>>>>>>> ACTUAL machine, not a partial simulation of it.
>>>>>>>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the
>>>>>>>>>>>>>>>>> answer is wrong.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When we see (after N steps) that D correctly simulated
>>>>>>>>>>>>>>>>>> by H cannot
>>>>>>>>>>>>>>>>>> possibly reach its simulated final state in any finite
>>>>>>>>>>>>>>>>>> number of steps
>>>>>>>>>>>>>>>>>> of correct simulation then we have conclusive proof
>>>>>>>>>>>>>>>>>> that D presents non-
>>>>>>>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>>>>>>>> You agreed that the first N steps are correctly simulated.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It turns out that the non-halting behavior pattern is
>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Your assumption that a program that calls H is
>>>>>>>>>>>>>>> non-halting is erroneous:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> My new paper anchors its ideas in actual Turing machines
>>>>>>>>>>>>>> so it is
>>>>>>>>>>>>>> unequivocal. The first two pages re only about the Linz
>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>> machine based proof.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The H/D material is now on a single page and all reference
>>>>>>>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>>>>>>>> analysis entirely in C.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With this new paper even Richard admits that the first N
>>>>>>>>>>>>>> steps
>>>>>>>>>>>>>> UTM based simulated by a simulating halt decider are
>>>>>>>>>>>>>> necessarily the
>>>>>>>>>>>>>> actual behavior of these N steps.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting
>>>>>>>>>>>>>> Problem Proofs*
>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>      (void) H(x, x);
>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Px halts (it discards the result that H returns); your
>>>>>>>>>>>>>>> decider thinks that Px is non-halting which is an obvious
>>>>>>>>>>>>>>> error due to a design flaw in the architecture of your
>>>>>>>>>>>>>>> decider.  Only the Flibble Signaling Simulating Halt
>>>>>>>>>>>>>>> Decider (SSHD) correctly handles this case.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope. For H to be a halt decider it must return a halt
>>>>>>>>>>>>> decision to its caller in finite time
>>>>>>>>>>>>
>>>>>>>>>>>> Although H must always return to some caller H is not
>>>>>>>>>>>> allowed to return
>>>>>>>>>>>> to any caller that essentially calls H in infinite recursion.
>>>>>>>>>>>
>>>>>>>>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does not
>>>>>>>>>>> have any infinite recursion thereby proving that
>>>>>>>>>>
>>>>>>>>>> It overrode that behavior that was specified by the machine
>>>>>>>>>> code for Px.
>>>>>>>>>
>>>>>>>>> Nope. You SHD is not a halt decider as
>>>>>>>>
>>>>>>>> I was not even talking about my SHD, I was talking about how
>>>>>>>> your program does its simulation incorrectly.
>>>>>>>
>>>>>>> My SSHD does not do its simulation incorrectly: it does its
>>>>>>> simulation just like I have defined it as evidenced by the fact
>>>>>>> that it returns a correct halting decision for Px; something your
>>>>>>> broken SHD gets wrong.
>>>>>>>
>>>>>>
>>>>>> In order for you to have Px simulated by H terminate normally you
>>>>>> must change the behavior of Px away from the behavior that its x86
>>>>>> code specifies.
>>>>>
>>>>> Your "x86 code" has nothing to do with how my halt decider works; I
>>>>> am using an entirely different simulation method, one that actually
>>>>> works.
>>>>>
>>>>>>
>>>>>> void Px(void (*x)())
>>>>>> {
>>>>>>    (void) H(x, x);
>>>>>>    return;
>>>>>> }
>>>>>>
>>>>>> Px correctly simulated by H cannot possibly reach past its machine
>>>>>> address of: [00001b3d].
>>>>>>
>>>>>> _Px()
>>>>>> [00001b32] 55         push ebp
>>>>>> [00001b33] 8bec       mov ebp,esp
>>>>>> [00001b35] 8b4508     mov eax,[ebp+08]
>>>>>> [00001b38] 50         push eax      // push address of Px
>>>>>> [00001b39] 8b4d08     mov ecx,[ebp+08]
>>>>>> [00001b3c] 51         push ecx      // push address of Px
>>>>>> [00001b3d] e800faffff call 00001542 // Call H
>>>>>> [00001b42] 83c408     add esp,+08
>>>>>> [00001b45] 5d         pop ebp
>>>>>> [00001b46] c3         ret
>>>>>> Size in bytes:(0021) [00001b46]
>>>>>>
>>>>>> What you are doing is the the same as recognizing that
>>>>>> _Infinite_Loop()
>>>>>> never halts, forcing it to break out of its infinite loop and jump to
>>>>>> its "ret" instruction
>>>>>>
>>>>>> _Infinite_Loop()
>>>>>> [00001c62] 55         push ebp
>>>>>> [00001c63] 8bec       mov ebp,esp
>>>>>> [00001c65] ebfe       jmp 00001c65
>>>>>> [00001c67] 5d         pop ebp
>>>>>> [00001c68] c3         ret
>>>>>> Size in bytes:(0007) [00001c68]
>>>>>
>>>>> No I am not: there is no infinite loop in Px above; forking the
>>>>> simulation into two branches and returning a different halt
>>>>> decision to each branch is a perfectly valid SHD design; again a
>>>>> design, unlike yours, that actually works.
>>>>
>>>> If you say that Px correctly simulated by H ever reaches its own final
>>>> "return" statement and halts you are incorrect.
>>>
>>> Px halts if H is (or is part of) a genuine halt decider.
>>
>> The simulated Px only halts if it reaches its own final state in a
>> finite number of steps of correct simulation. It can't possibly do this.
>
> Nope, a correctly simulated Px will allow it to reach its own final
> state (termination); your H does NOT perform a correct simulation
> because your H is broken.
>
> /Flibble
>

On 21/04/2023 5:41 pm, olcott wrote:
> On 4/21/2023 11:36 AM, Mr Flibble wrote:
>> On 21/04/2023 4:16 pm, olcott wrote:
>>> On 4/21/2023 7:17 AM, Mr Flibble wrote:
>>>> On 20/04/2023 8:20 pm, olcott wrote:
>>>>> On 4/20/2023 2:08 PM, Mr Flibble wrote:
>>>>>> On 20/04/2023 6:49 pm, olcott wrote:
>>>>>>> On 4/20/2023 12:32 PM, Mr Flibble wrote:
>>>>>>>> On 19/04/2023 11:52 pm, olcott wrote:
>>>>>>>>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>>>>>>>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>>>>>>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>>>>>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>>>>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> A simulating halt decider correctly predicts whether
>>>>>>>>>>>>>>>>>>> or not its
>>>>>>>>>>>>>>>>>>> correctly simulated input can possibly reach its own
>>>>>>>>>>>>>>>>>>> final state and
>>>>>>>>>>>>>>>>>>> halt. It does this by correctly recognizing several
>>>>>>>>>>>>>>>>>>> non-halting behavior
>>>>>>>>>>>>>>>>>>> patterns in a finite number of steps of correct
>>>>>>>>>>>>>>>>>>> simulation. Inputs that
>>>>>>>>>>>>>>>>>>> do terminate are simply simulated until they complete.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Except t doesn't o this for the "pathological" program.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The "Pathological Program" when built on such a
>>>>>>>>>>>>>>>>>> Decider that does give an answer, which you say will
>>>>>>>>>>>>>>>>>> be non-halting, and then "Correctly Simulated" by
>>>>>>>>>>>>>>>>>> giving it representation to a UTM, we see that the
>>>>>>>>>>>>>>>>>> simulation reaches a final state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the
>>>>>>>>>>>>>>>>>> problem is you have added a pattern that isn't always
>>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When a simulating halt decider correctly simulates N
>>>>>>>>>>>>>>>>>>> steps of its input
>>>>>>>>>>>>>>>>>>> it derives the exact same N steps that a pure UTM
>>>>>>>>>>>>>>>>>>> would derive because
>>>>>>>>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the
>>>>>>>>>>>>>>>>>> features you added have removed essential features
>>>>>>>>>>>>>>>>>> needed for it to be an actual UTM. That you make this
>>>>>>>>>>>>>>>>>> claim shows you don't actually know what a UTM is.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street
>>>>>>>>>>>>>>>>>> Legal vehicle, since it started as one and just had
>>>>>>>>>>>>>>>>>> some extra features axded.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> My reviewers cannot show that any of the extra
>>>>>>>>>>>>>>>>>>> features added to the UTM
>>>>>>>>>>>>>>>>>>> change the behavior of the simulated input for the
>>>>>>>>>>>>>>>>>>> first N steps of simulation:
>>>>>>>>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't
>>>>>>>>>>>>>>>>>>> change it
>>>>>>>>>>>>>>>>>>> (c) Even aborting the simulation after N steps
>>>>>>>>>>>>>>>>>>> doesn't change the first N steps.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No one claims that it doesn't correctly reproduce the
>>>>>>>>>>>>>>>>>> first N steps of the behavior, that is a Strawman
>>>>>>>>>>>>>>>>>> argumen.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Because of all this we can know that the first N
>>>>>>>>>>>>>>>>>>> steps of input D
>>>>>>>>>>>>>>>>>>> simulated by simulating halt decider H are the actual
>>>>>>>>>>>>>>>>>>> behavior that D
>>>>>>>>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *computation that halts*… “the Turing machine will
>>>>>>>>>>>>>>>>>>> halt whenever it enters a final state”
>>>>>>>>>>>>>>>>>>> (Linz:1990:234)rrr
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Right, so we are concerned about the behavior of the
>>>>>>>>>>>>>>>>>> ACTUAL machine, not a partial simulation of it.
>>>>>>>>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the
>>>>>>>>>>>>>>>>>> answer is wrong.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When we see (after N steps) that D correctly
>>>>>>>>>>>>>>>>>>> simulated by H cannot
>>>>>>>>>>>>>>>>>>> possibly reach its simulated final state in any
>>>>>>>>>>>>>>>>>>> finite number of steps
>>>>>>>>>>>>>>>>>>> of correct simulation then we have conclusive proof
>>>>>>>>>>>>>>>>>>> that D presents non-
>>>>>>>>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>>>>>>>>> You agreed that the first N steps are correctly simulated.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It turns out that the non-halting behavior pattern is
>>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Your assumption that a program that calls H is
>>>>>>>>>>>>>>>> non-halting is erroneous:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My new paper anchors its ideas in actual Turing machines
>>>>>>>>>>>>>>> so it is
>>>>>>>>>>>>>>> unequivocal. The first two pages re only about the Linz
>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>> machine based proof.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The H/D material is now on a single page and all reference
>>>>>>>>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>>>>>>>>> analysis entirely in C.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> With this new paper even Richard admits that the first N
>>>>>>>>>>>>>>> steps
>>>>>>>>>>>>>>> UTM based simulated by a simulating halt decider are
>>>>>>>>>>>>>>> necessarily the
>>>>>>>>>>>>>>> actual behavior of these N steps.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting
>>>>>>>>>>>>>>> Problem Proofs*
>>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>      (void) H(x, x);
>>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Px halts (it discards the result that H returns); your
>>>>>>>>>>>>>>>> decider thinks that Px is non-halting which is an
>>>>>>>>>>>>>>>> obvious error due to a design flaw in the architecture
>>>>>>>>>>>>>>>> of your decider.  Only the Flibble Signaling Simulating
>>>>>>>>>>>>>>>> Halt Decider (SSHD) correctly handles this case.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope. For H to be a halt decider it must return a halt
>>>>>>>>>>>>>> decision to its caller in finite time
>>>>>>>>>>>>>
>>>>>>>>>>>>> Although H must always return to some caller H is not
>>>>>>>>>>>>> allowed to return
>>>>>>>>>>>>> to any caller that essentially calls H in infinite recursion.
>>>>>>>>>>>>
>>>>>>>>>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does
>>>>>>>>>>>> not have any infinite recursion thereby proving that
>>>>>>>>>>>
>>>>>>>>>>> It overrode that behavior that was specified by the machine
>>>>>>>>>>> code for Px.
>>>>>>>>>>
>>>>>>>>>> Nope. You SHD is not a halt decider as
>>>>>>>>>
>>>>>>>>> I was not even talking about my SHD, I was talking about how
>>>>>>>>> your program does its simulation incorrectly.
>>>>>>>>
>>>>>>>> My SSHD does not do its simulation incorrectly: it does its
>>>>>>>> simulation just like I have defined it as evidenced by the fact
>>>>>>>> that it returns a correct halting decision for Px; something
>>>>>>>> your broken SHD gets wrong.
>>>>>>>>
>>>>>>>
>>>>>>> In order for you to have Px simulated by H terminate normally you
>>>>>>> must change the behavior of Px away from the behavior that its
>>>>>>> x86 code specifies.
>>>>>>
>>>>>> Your "x86 code" has nothing to do with how my halt decider works;
>>>>>> I am using an entirely different simulation method, one that
>>>>>> actually works.
>>>>>>
>>>>>>>
>>>>>>> void Px(void (*x)())
>>>>>>> {
>>>>>>>    (void) H(x, x);
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> Px correctly simulated by H cannot possibly reach past its
>>>>>>> machine address of: [00001b3d].
>>>>>>>
>>>>>>> _Px()
>>>>>>> [00001b32] 55         push ebp
>>>>>>> [00001b33] 8bec       mov ebp,esp
>>>>>>> [00001b35] 8b4508     mov eax,[ebp+08]
>>>>>>> [00001b38] 50         push eax      // push address of Px
>>>>>>> [00001b39] 8b4d08     mov ecx,[ebp+08]
>>>>>>> [00001b3c] 51         push ecx      // push address of Px
>>>>>>> [00001b3d] e800faffff call 00001542 // Call H
>>>>>>> [00001b42] 83c408     add esp,+08
>>>>>>> [00001b45] 5d         pop ebp
>>>>>>> [00001b46] c3         ret
>>>>>>> Size in bytes:(0021) [00001b46]
>>>>>>>
>>>>>>> What you are doing is the the same as recognizing that
>>>>>>> _Infinite_Loop()
>>>>>>> never halts, forcing it to break out of its infinite loop and
>>>>>>> jump to
>>>>>>> its "ret" instruction
>>>>>>>
>>>>>>> _Infinite_Loop()
>>>>>>> [00001c62] 55         push ebp
>>>>>>> [00001c63] 8bec       mov ebp,esp
>>>>>>> [00001c65] ebfe       jmp 00001c65
>>>>>>> [00001c67] 5d         pop ebp
>>>>>>> [00001c68] c3         ret
>>>>>>> Size in bytes:(0007) [00001c68]
>>>>>>
>>>>>> No I am not: there is no infinite loop in Px above; forking the
>>>>>> simulation into two branches and returning a different halt
>>>>>> decision to each branch is a perfectly valid SHD design; again a
>>>>>> design, unlike yours, that actually works.
>>>>>
>>>>> If you say that Px correctly simulated by H ever reaches its own final
>>>>> "return" statement and halts you are incorrect.
>>>>
>>>> Px halts if H is (or is part of) a genuine halt decider.
>>>
>>> The simulated Px only halts if it reaches its own final state in a
>>> finite number of steps of correct simulation. It can't possibly do this.
>>
>> Nope, a correctly simulated Px will allow it to reach its own final
>> state (termination); your H does NOT perform a correct simulation
>> because your H is broken.
>>
>> /Flibble
>>
>
> Strawman deception
> Px correctly simulated by H will never reach its own simulated final
> state of "return" because Px and H have a pathological relationship to
> each other.

On 4/21/2023 12:42 PM, Mr Flibble wrote:
> On 21/04/2023 5:41 pm, olcott wrote:
>> On 4/21/2023 11:36 AM, Mr Flibble wrote:
>>> On 21/04/2023 4:16 pm, olcott wrote:
>>>> On 4/21/2023 7:17 AM, Mr Flibble wrote:
>>>>> On 20/04/2023 8:20 pm, olcott wrote:
>>>>>> On 4/20/2023 2:08 PM, Mr Flibble wrote:
>>>>>>> On 20/04/2023 6:49 pm, olcott wrote:
>>>>>>>> On 4/20/2023 12:32 PM, Mr Flibble wrote:
>>>>>>>>> On 19/04/2023 11:52 pm, olcott wrote:
>>>>>>>>>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>>>>>>>>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>>>>>>>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>>>>>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>>>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> A simulating halt decider correctly predicts whether
>>>>>>>>>>>>>>>>>>>> or not its
>>>>>>>>>>>>>>>>>>>> correctly simulated input can possibly reach its own
>>>>>>>>>>>>>>>>>>>> final state and
>>>>>>>>>>>>>>>>>>>> halt. It does this by correctly recognizing several
>>>>>>>>>>>>>>>>>>>> non-halting behavior
>>>>>>>>>>>>>>>>>>>> patterns in a finite number of steps of correct
>>>>>>>>>>>>>>>>>>>> simulation. Inputs that
>>>>>>>>>>>>>>>>>>>> do terminate are simply simulated until they complete.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Except t doesn't o this for the "pathological" program.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The "Pathological Program" when built on such a
>>>>>>>>>>>>>>>>>>> Decider that does give an answer, which you say will
>>>>>>>>>>>>>>>>>>> be non-halting, and then "Correctly Simulated" by
>>>>>>>>>>>>>>>>>>> giving it representation to a UTM, we see that the
>>>>>>>>>>>>>>>>>>> simulation reaches a final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the
>>>>>>>>>>>>>>>>>>> problem is you have added a pattern that isn't always
>>>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> When a simulating halt decider correctly simulates N
>>>>>>>>>>>>>>>>>>>> steps of its input
>>>>>>>>>>>>>>>>>>>> it derives the exact same N steps that a pure UTM
>>>>>>>>>>>>>>>>>>>> would derive because
>>>>>>>>>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the
>>>>>>>>>>>>>>>>>>> features you added have removed essential features
>>>>>>>>>>>>>>>>>>> needed for it to be an actual UTM. That you make this
>>>>>>>>>>>>>>>>>>> claim shows you don't actually know what a UTM is.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street
>>>>>>>>>>>>>>>>>>> Legal vehicle, since it started as one and just had
>>>>>>>>>>>>>>>>>>> some extra features axded.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> My reviewers cannot show that any of the extra
>>>>>>>>>>>>>>>>>>>> features added to the UTM
>>>>>>>>>>>>>>>>>>>> change the behavior of the simulated input for the
>>>>>>>>>>>>>>>>>>>> first N steps of simulation:
>>>>>>>>>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't
>>>>>>>>>>>>>>>>>>>> change it
>>>>>>>>>>>>>>>>>>>> (c) Even aborting the simulation after N steps
>>>>>>>>>>>>>>>>>>>> doesn't change the first N steps.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No one claims that it doesn't correctly reproduce the
>>>>>>>>>>>>>>>>>>> first N steps of the behavior, that is a Strawman
>>>>>>>>>>>>>>>>>>> argumen.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Because of all this we can know that the first N
>>>>>>>>>>>>>>>>>>>> steps of input D
>>>>>>>>>>>>>>>>>>>> simulated by simulating halt decider H are the
>>>>>>>>>>>>>>>>>>>> actual behavior that D
>>>>>>>>>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *computation that halts*… “the Turing machine will
>>>>>>>>>>>>>>>>>>>> halt whenever it enters a final state”
>>>>>>>>>>>>>>>>>>>> (Linz:1990:234)rrr
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Right, so we are concerned about the behavior of the
>>>>>>>>>>>>>>>>>>> ACTUAL machine, not a partial simulation of it.
>>>>>>>>>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the
>>>>>>>>>>>>>>>>>>> answer is wrong.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> When we see (after N steps) that D correctly
>>>>>>>>>>>>>>>>>>>> simulated by H cannot
>>>>>>>>>>>>>>>>>>>> possibly reach its simulated final state in any
>>>>>>>>>>>>>>>>>>>> finite number of steps
>>>>>>>>>>>>>>>>>>>> of correct simulation then we have conclusive proof
>>>>>>>>>>>>>>>>>>>> that D presents non-
>>>>>>>>>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>>>>>>>>>> You agreed that the first N steps are correctly
>>>>>>>>>>>>>>>>>> simulated.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It turns out that the non-halting behavior pattern is
>>>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Your assumption that a program that calls H is
>>>>>>>>>>>>>>>>> non-halting is erroneous:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> My new paper anchors its ideas in actual Turing machines
>>>>>>>>>>>>>>>> so it is
>>>>>>>>>>>>>>>> unequivocal. The first two pages re only about the Linz
>>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>>> machine based proof.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The H/D material is now on a single page and all reference
>>>>>>>>>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>>>>>>>>>> analysis entirely in C.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> With this new paper even Richard admits that the first N
>>>>>>>>>>>>>>>> steps
>>>>>>>>>>>>>>>> UTM based simulated by a simulating halt decider are
>>>>>>>>>>>>>>>> necessarily the
>>>>>>>>>>>>>>>> actual behavior of these N steps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting
>>>>>>>>>>>>>>>> Problem Proofs*
>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>      (void) H(x, x);
>>>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Px halts (it discards the result that H returns); your
>>>>>>>>>>>>>>>>> decider thinks that Px is non-halting which is an
>>>>>>>>>>>>>>>>> obvious error due to a design flaw in the architecture
>>>>>>>>>>>>>>>>> of your decider.  Only the Flibble Signaling Simulating
>>>>>>>>>>>>>>>>> Halt Decider (SSHD) correctly handles this case.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope. For H to be a halt decider it must return a halt
>>>>>>>>>>>>>>> decision to its caller in finite time
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Although H must always return to some caller H is not
>>>>>>>>>>>>>> allowed to return
>>>>>>>>>>>>>> to any caller that essentially calls H in infinite recursion.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does
>>>>>>>>>>>>> not have any infinite recursion thereby proving that
>>>>>>>>>>>>
>>>>>>>>>>>> It overrode that behavior that was specified by the machine
>>>>>>>>>>>> code for Px.
>>>>>>>>>>>
>>>>>>>>>>> Nope. You SHD is not a halt decider as
>>>>>>>>>>
>>>>>>>>>> I was not even talking about my SHD, I was talking about how
>>>>>>>>>> your program does its simulation incorrectly.
>>>>>>>>>
>>>>>>>>> My SSHD does not do its simulation incorrectly: it does its
>>>>>>>>> simulation just like I have defined it as evidenced by the fact
>>>>>>>>> that it returns a correct halting decision for Px; something
>>>>>>>>> your broken SHD gets wrong.
>>>>>>>>>
>>>>>>>>
>>>>>>>> In order for you to have Px simulated by H terminate normally
>>>>>>>> you must change the behavior of Px away from the behavior that
>>>>>>>> its x86 code specifies.
>>>>>>>
>>>>>>> Your "x86 code" has nothing to do with how my halt decider works;
>>>>>>> I am using an entirely different simulation method, one that
>>>>>>> actually works.
>>>>>>>
>>>>>>>>
>>>>>>>> void Px(void (*x)())
>>>>>>>> {
>>>>>>>>    (void) H(x, x);
>>>>>>>>    return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> Px correctly simulated by H cannot possibly reach past its
>>>>>>>> machine address of: [00001b3d].
>>>>>>>>
>>>>>>>> _Px()
>>>>>>>> [00001b32] 55         push ebp
>>>>>>>> [00001b33] 8bec       mov ebp,esp
>>>>>>>> [00001b35] 8b4508     mov eax,[ebp+08]
>>>>>>>> [00001b38] 50         push eax      // push address of Px
>>>>>>>> [00001b39] 8b4d08     mov ecx,[ebp+08]
>>>>>>>> [00001b3c] 51         push ecx      // push address of Px
>>>>>>>> [00001b3d] e800faffff call 00001542 // Call H
>>>>>>>> [00001b42] 83c408     add esp,+08
>>>>>>>> [00001b45] 5d         pop ebp
>>>>>>>> [00001b46] c3         ret
>>>>>>>> Size in bytes:(0021) [00001b46]
>>>>>>>>
>>>>>>>> What you are doing is the the same as recognizing that
>>>>>>>> _Infinite_Loop()
>>>>>>>> never halts, forcing it to break out of its infinite loop and
>>>>>>>> jump to
>>>>>>>> its "ret" instruction
>>>>>>>>
>>>>>>>> _Infinite_Loop()
>>>>>>>> [00001c62] 55         push ebp
>>>>>>>> [00001c63] 8bec       mov ebp,esp
>>>>>>>> [00001c65] ebfe       jmp 00001c65
>>>>>>>> [00001c67] 5d         pop ebp
>>>>>>>> [00001c68] c3         ret
>>>>>>>> Size in bytes:(0007) [00001c68]
>>>>>>>
>>>>>>> No I am not: there is no infinite loop in Px above; forking the
>>>>>>> simulation into two branches and returning a different halt
>>>>>>> decision to each branch is a perfectly valid SHD design; again a
>>>>>>> design, unlike yours, that actually works.
>>>>>>
>>>>>> If you say that Px correctly simulated by H ever reaches its own
>>>>>> final
>>>>>> "return" statement and halts you are incorrect.
>>>>>
>>>>> Px halts if H is (or is part of) a genuine halt decider.
>>>>
>>>> The simulated Px only halts if it reaches its own final state in a
>>>> finite number of steps of correct simulation. It can't possibly do
>>>> this.
>>>
>>> Nope, a correctly simulated Px will allow it to reach its own final
>>> state (termination); your H does NOT perform a correct simulation
>>> because your H is broken.
>>>
>>> /Flibble
>>>
>>
>> Strawman deception
>> Px correctly simulated by H will never reach its own simulated final
>> state of "return" because Px and H have a pathological relationship to
>> each other.
>
> Nope, there is no pathological relationship between Px and H because Px
> discards the result of H (i.e. it does not try to do the opposite of the
> H halting result as per the definition of the Halting Problem).
>

On 21/04/2023 7:36 pm, olcott wrote:
> On 4/21/2023 12:42 PM, Mr Flibble wrote:
>> On 21/04/2023 5:41 pm, olcott wrote:
>>> On 4/21/2023 11:36 AM, Mr Flibble wrote:
>>>> On 21/04/2023 4:16 pm, olcott wrote:
>>>>> On 4/21/2023 7:17 AM, Mr Flibble wrote:
>>>>>> On 20/04/2023 8:20 pm, olcott wrote:
>>>>>>> On 4/20/2023 2:08 PM, Mr Flibble wrote:
>>>>>>>> On 20/04/2023 6:49 pm, olcott wrote:
>>>>>>>>> On 4/20/2023 12:32 PM, Mr Flibble wrote:
>>>>>>>>>> On 19/04/2023 11:52 pm, olcott wrote:
>>>>>>>>>>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>>>>>>>>>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>>>>>>>>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>>>>>>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>>>>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> A simulating halt decider correctly predicts
>>>>>>>>>>>>>>>>>>>>> whether or not its
>>>>>>>>>>>>>>>>>>>>> correctly simulated input can possibly reach its
>>>>>>>>>>>>>>>>>>>>> own final state and
>>>>>>>>>>>>>>>>>>>>> halt. It does this by correctly recognizing several
>>>>>>>>>>>>>>>>>>>>> non-halting behavior
>>>>>>>>>>>>>>>>>>>>> patterns in a finite number of steps of correct
>>>>>>>>>>>>>>>>>>>>> simulation. Inputs that
>>>>>>>>>>>>>>>>>>>>> do terminate are simply simulated until they complete.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Except t doesn't o this for the "pathological" program.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The "Pathological Program" when built on such a
>>>>>>>>>>>>>>>>>>>> Decider that does give an answer, which you say will
>>>>>>>>>>>>>>>>>>>> be non-halting, and then "Correctly Simulated" by
>>>>>>>>>>>>>>>>>>>> giving it representation to a UTM, we see that the
>>>>>>>>>>>>>>>>>>>> simulation reaches a final state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the
>>>>>>>>>>>>>>>>>>>> problem is you have added a pattern that isn't
>>>>>>>>>>>>>>>>>>>> always non-halting.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> When a simulating halt decider correctly simulates
>>>>>>>>>>>>>>>>>>>>> N steps of its input
>>>>>>>>>>>>>>>>>>>>> it derives the exact same N steps that a pure UTM
>>>>>>>>>>>>>>>>>>>>> would derive because
>>>>>>>>>>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the
>>>>>>>>>>>>>>>>>>>> features you added have removed essential features
>>>>>>>>>>>>>>>>>>>> needed for it to be an actual UTM. That you make
>>>>>>>>>>>>>>>>>>>> this claim shows you don't actually know what a UTM is.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street
>>>>>>>>>>>>>>>>>>>> Legal vehicle, since it started as one and just had
>>>>>>>>>>>>>>>>>>>> some extra features axded.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> My reviewers cannot show that any of the extra
>>>>>>>>>>>>>>>>>>>>> features added to the UTM
>>>>>>>>>>>>>>>>>>>>> change the behavior of the simulated input for the
>>>>>>>>>>>>>>>>>>>>> first N steps of simulation:
>>>>>>>>>>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't
>>>>>>>>>>>>>>>>>>>>> change it
>>>>>>>>>>>>>>>>>>>>> (c) Even aborting the simulation after N steps
>>>>>>>>>>>>>>>>>>>>> doesn't change the first N steps.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No one claims that it doesn't correctly reproduce
>>>>>>>>>>>>>>>>>>>> the first N steps of the behavior, that is a
>>>>>>>>>>>>>>>>>>>> Strawman argumen.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Because of all this we can know that the first N
>>>>>>>>>>>>>>>>>>>>> steps of input D
>>>>>>>>>>>>>>>>>>>>> simulated by simulating halt decider H are the
>>>>>>>>>>>>>>>>>>>>> actual behavior that D
>>>>>>>>>>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *computation that halts*… “the Turing machine will
>>>>>>>>>>>>>>>>>>>>> halt whenever it enters a final state”
>>>>>>>>>>>>>>>>>>>>> (Linz:1990:234)rrr
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Right, so we are concerned about the behavior of the
>>>>>>>>>>>>>>>>>>>> ACTUAL machine, not a partial simulation of it.
>>>>>>>>>>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the
>>>>>>>>>>>>>>>>>>>> answer is wrong.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> When we see (after N steps) that D correctly
>>>>>>>>>>>>>>>>>>>>> simulated by H cannot
>>>>>>>>>>>>>>>>>>>>> possibly reach its simulated final state in any
>>>>>>>>>>>>>>>>>>>>> finite number of steps
>>>>>>>>>>>>>>>>>>>>> of correct simulation then we have conclusive proof
>>>>>>>>>>>>>>>>>>>>> that D presents non-
>>>>>>>>>>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>>>>>>>>>>> You agreed that the first N steps are correctly
>>>>>>>>>>>>>>>>>>> simulated.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It turns out that the non-halting behavior pattern is
>>>>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Your assumption that a program that calls H is
>>>>>>>>>>>>>>>>>> non-halting is erroneous:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> My new paper anchors its ideas in actual Turing
>>>>>>>>>>>>>>>>> machines so it is
>>>>>>>>>>>>>>>>> unequivocal. The first two pages re only about the Linz
>>>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>>>> machine based proof.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The H/D material is now on a single page and all reference
>>>>>>>>>>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>>>>>>>>>>> analysis entirely in C.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> With this new paper even Richard admits that the first
>>>>>>>>>>>>>>>>> N steps
>>>>>>>>>>>>>>>>> UTM based simulated by a simulating halt decider are
>>>>>>>>>>>>>>>>> necessarily the
>>>>>>>>>>>>>>>>> actual behavior of these N steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting
>>>>>>>>>>>>>>>>> Problem Proofs*
>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>      (void) H(x, x);
>>>>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Px halts (it discards the result that H returns); your
>>>>>>>>>>>>>>>>>> decider thinks that Px is non-halting which is an
>>>>>>>>>>>>>>>>>> obvious error due to a design flaw in the architecture
>>>>>>>>>>>>>>>>>> of your decider.  Only the Flibble Signaling
>>>>>>>>>>>>>>>>>> Simulating Halt Decider (SSHD) correctly handles this
>>>>>>>>>>>>>>>>>> case.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope. For H to be a halt decider it must return a halt
>>>>>>>>>>>>>>>> decision to its caller in finite time
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Although H must always return to some caller H is not
>>>>>>>>>>>>>>> allowed to return
>>>>>>>>>>>>>>> to any caller that essentially calls H in infinite
>>>>>>>>>>>>>>> recursion.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does
>>>>>>>>>>>>>> not have any infinite recursion thereby proving that
>>>>>>>>>>>>>
>>>>>>>>>>>>> It overrode that behavior that was specified by the machine
>>>>>>>>>>>>> code for Px.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope. You SHD is not a halt decider as
>>>>>>>>>>>
>>>>>>>>>>> I was not even talking about my SHD, I was talking about how
>>>>>>>>>>> your program does its simulation incorrectly.
>>>>>>>>>>
>>>>>>>>>> My SSHD does not do its simulation incorrectly: it does its
>>>>>>>>>> simulation just like I have defined it as evidenced by the
>>>>>>>>>> fact that it returns a correct halting decision for Px;
>>>>>>>>>> something your broken SHD gets wrong.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In order for you to have Px simulated by H terminate normally
>>>>>>>>> you must change the behavior of Px away from the behavior that
>>>>>>>>> its x86 code specifies.
>>>>>>>>
>>>>>>>> Your "x86 code" has nothing to do with how my halt decider
>>>>>>>> works; I am using an entirely different simulation method, one
>>>>>>>> that actually works.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> void Px(void (*x)())
>>>>>>>>> {
>>>>>>>>>    (void) H(x, x);
>>>>>>>>>    return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Px correctly simulated by H cannot possibly reach past its
>>>>>>>>> machine address of: [00001b3d].
>>>>>>>>>
>>>>>>>>> _Px()
>>>>>>>>> [00001b32] 55         push ebp
>>>>>>>>> [00001b33] 8bec       mov ebp,esp
>>>>>>>>> [00001b35] 8b4508     mov eax,[ebp+08]
>>>>>>>>> [00001b38] 50         push eax      // push address of Px
>>>>>>>>> [00001b39] 8b4d08     mov ecx,[ebp+08]
>>>>>>>>> [00001b3c] 51         push ecx      // push address of Px
>>>>>>>>> [00001b3d] e800faffff call 00001542 // Call H
>>>>>>>>> [00001b42] 83c408     add esp,+08
>>>>>>>>> [00001b45] 5d         pop ebp
>>>>>>>>> [00001b46] c3         ret
>>>>>>>>> Size in bytes:(0021) [00001b46]
>>>>>>>>>
>>>>>>>>> What you are doing is the the same as recognizing that
>>>>>>>>> _Infinite_Loop()
>>>>>>>>> never halts, forcing it to break out of its infinite loop and
>>>>>>>>> jump to
>>>>>>>>> its "ret" instruction
>>>>>>>>>
>>>>>>>>> _Infinite_Loop()
>>>>>>>>> [00001c62] 55         push ebp
>>>>>>>>> [00001c63] 8bec       mov ebp,esp
>>>>>>>>> [00001c65] ebfe       jmp 00001c65
>>>>>>>>> [00001c67] 5d         pop ebp
>>>>>>>>> [00001c68] c3         ret
>>>>>>>>> Size in bytes:(0007) [00001c68]
>>>>>>>>
>>>>>>>> No I am not: there is no infinite loop in Px above; forking the
>>>>>>>> simulation into two branches and returning a different halt
>>>>>>>> decision to each branch is a perfectly valid SHD design; again a
>>>>>>>> design, unlike yours, that actually works.
>>>>>>>
>>>>>>> If you say that Px correctly simulated by H ever reaches its own
>>>>>>> final
>>>>>>> "return" statement and halts you are incorrect.
>>>>>>
>>>>>> Px halts if H is (or is part of) a genuine halt decider.
>>>>>
>>>>> The simulated Px only halts if it reaches its own final state in a
>>>>> finite number of steps of correct simulation. It can't possibly do
>>>>> this.
>>>>
>>>> Nope, a correctly simulated Px will allow it to reach its own final
>>>> state (termination); your H does NOT perform a correct simulation
>>>> because your H is broken.
>>>>
>>>> /Flibble
>>>>
>>>
>>> Strawman deception
>>> Px correctly simulated by H will never reach its own simulated final
>>> state of "return" because Px and H have a pathological relationship to
>>> each other.
>>
>> Nope, there is no pathological relationship between Px and H because
>> Px discards the result of H (i.e. it does not try to do the opposite
>> of the H halting result as per the definition of the Halting Problem).
>>
>
> It seems that you continue to fail to see the nested simulation
>
> 01 void Px(void (*x)())
> 02 {
> 03  (void) H(x, x);
> 04  return;
> 05 }
> 06
> 07 void main()
> 08 {
> 09  H(Px,Px);
> 10 }
>
> *Execution Trace when H never aborts its simulation*
> main() calls H(Px,Px) that simulates Px(Px) at line 09
> *keeps repeating*
>    simulated Px(Px) calls simulated H(Px,Px) that simulates Px(Px) at
> line 03 ...

On 4/21/2023 3:02 PM, Mr Flibble wrote:
> On 21/04/2023 7:36 pm, olcott wrote:
>> On 4/21/2023 12:42 PM, Mr Flibble wrote:
>>> On 21/04/2023 5:41 pm, olcott wrote:
>>>> On 4/21/2023 11:36 AM, Mr Flibble wrote:
>>>>> On 21/04/2023 4:16 pm, olcott wrote:
>>>>>> On 4/21/2023 7:17 AM, Mr Flibble wrote:
>>>>>>> On 20/04/2023 8:20 pm, olcott wrote:
>>>>>>>> On 4/20/2023 2:08 PM, Mr Flibble wrote:
>>>>>>>>> On 20/04/2023 6:49 pm, olcott wrote:
>>>>>>>>>> On 4/20/2023 12:32 PM, Mr Flibble wrote:
>>>>>>>>>>> On 19/04/2023 11:52 pm, olcott wrote:
>>>>>>>>>>>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>>>>>>>>>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>>>>>>>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>>>>>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> A simulating halt decider correctly predicts
>>>>>>>>>>>>>>>>>>>>>> whether or not its
>>>>>>>>>>>>>>>>>>>>>> correctly simulated input can possibly reach its
>>>>>>>>>>>>>>>>>>>>>> own final state and
>>>>>>>>>>>>>>>>>>>>>> halt. It does this by correctly recognizing
>>>>>>>>>>>>>>>>>>>>>> several non-halting behavior
>>>>>>>>>>>>>>>>>>>>>> patterns in a finite number of steps of correct
>>>>>>>>>>>>>>>>>>>>>> simulation. Inputs that
>>>>>>>>>>>>>>>>>>>>>> do terminate are simply simulated until they
>>>>>>>>>>>>>>>>>>>>>> complete.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Except t doesn't o this for the "pathological"
>>>>>>>>>>>>>>>>>>>>> program.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The "Pathological Program" when built on such a
>>>>>>>>>>>>>>>>>>>>> Decider that does give an answer, which you say
>>>>>>>>>>>>>>>>>>>>> will be non-halting, and then "Correctly Simulated"
>>>>>>>>>>>>>>>>>>>>> by giving it representation to a UTM, we see that
>>>>>>>>>>>>>>>>>>>>> the simulation reaches a final state.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the
>>>>>>>>>>>>>>>>>>>>> problem is you have added a pattern that isn't
>>>>>>>>>>>>>>>>>>>>> always non-halting.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> When a simulating halt decider correctly simulates
>>>>>>>>>>>>>>>>>>>>>> N steps of its input
>>>>>>>>>>>>>>>>>>>>>> it derives the exact same N steps that a pure UTM
>>>>>>>>>>>>>>>>>>>>>> would derive because
>>>>>>>>>>>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the
>>>>>>>>>>>>>>>>>>>>> features you added have removed essential features
>>>>>>>>>>>>>>>>>>>>> needed for it to be an actual UTM. That you make
>>>>>>>>>>>>>>>>>>>>> this claim shows you don't actually know what a UTM
>>>>>>>>>>>>>>>>>>>>> is.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street
>>>>>>>>>>>>>>>>>>>>> Legal vehicle, since it started as one and just had
>>>>>>>>>>>>>>>>>>>>> some extra features axded.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> My reviewers cannot show that any of the extra
>>>>>>>>>>>>>>>>>>>>>> features added to the UTM
>>>>>>>>>>>>>>>>>>>>>> change the behavior of the simulated input for the
>>>>>>>>>>>>>>>>>>>>>> first N steps of simulation:
>>>>>>>>>>>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't
>>>>>>>>>>>>>>>>>>>>>> change it
>>>>>>>>>>>>>>>>>>>>>> (c) Even aborting the simulation after N steps
>>>>>>>>>>>>>>>>>>>>>> doesn't change the first N steps.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No one claims that it doesn't correctly reproduce
>>>>>>>>>>>>>>>>>>>>> the first N steps of the behavior, that is a
>>>>>>>>>>>>>>>>>>>>> Strawman argumen.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Because of all this we can know that the first N
>>>>>>>>>>>>>>>>>>>>>> steps of input D
>>>>>>>>>>>>>>>>>>>>>> simulated by simulating halt decider H are the
>>>>>>>>>>>>>>>>>>>>>> actual behavior that D
>>>>>>>>>>>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> *computation that halts*… “the Turing machine will
>>>>>>>>>>>>>>>>>>>>>> halt whenever it enters a final state”
>>>>>>>>>>>>>>>>>>>>>> (Linz:1990:234)rrr
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Right, so we are concerned about the behavior of
>>>>>>>>>>>>>>>>>>>>> the ACTUAL machine, not a partial simulation of it.
>>>>>>>>>>>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the
>>>>>>>>>>>>>>>>>>>>> answer is wrong.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> When we see (after N steps) that D correctly
>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot
>>>>>>>>>>>>>>>>>>>>>> possibly reach its simulated final state in any
>>>>>>>>>>>>>>>>>>>>>> finite number of steps
>>>>>>>>>>>>>>>>>>>>>> of correct simulation then we have conclusive
>>>>>>>>>>>>>>>>>>>>>> proof that D presents non-
>>>>>>>>>>>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>>>>>>>>>>>> You agreed that the first N steps are correctly
>>>>>>>>>>>>>>>>>>>> simulated.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It turns out that the non-halting behavior pattern
>>>>>>>>>>>>>>>>>>>> is correctly
>>>>>>>>>>>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Your assumption that a program that calls H is
>>>>>>>>>>>>>>>>>>> non-halting is erroneous:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> My new paper anchors its ideas in actual Turing
>>>>>>>>>>>>>>>>>> machines so it is
>>>>>>>>>>>>>>>>>> unequivocal. The first two pages re only about the
>>>>>>>>>>>>>>>>>> Linz Turing
>>>>>>>>>>>>>>>>>> machine based proof.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The H/D material is now on a single page and all
>>>>>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>>>>>>>>>>>> analysis entirely in C.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> With this new paper even Richard admits that the first
>>>>>>>>>>>>>>>>>> N steps
>>>>>>>>>>>>>>>>>> UTM based simulated by a simulating halt decider are
>>>>>>>>>>>>>>>>>> necessarily the
>>>>>>>>>>>>>>>>>> actual behavior of these N steps.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting
>>>>>>>>>>>>>>>>>> Problem Proofs*
>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>      (void) H(x, x);
>>>>>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Px halts (it discards the result that H returns);
>>>>>>>>>>>>>>>>>>> your decider thinks that Px is non-halting which is
>>>>>>>>>>>>>>>>>>> an obvious error due to a design flaw in the
>>>>>>>>>>>>>>>>>>> architecture of your decider.  Only the Flibble
>>>>>>>>>>>>>>>>>>> Signaling Simulating Halt Decider (SSHD) correctly
>>>>>>>>>>>>>>>>>>> handles this case.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope. For H to be a halt decider it must return a halt
>>>>>>>>>>>>>>>>> decision to its caller in finite time
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Although H must always return to some caller H is not
>>>>>>>>>>>>>>>> allowed to return
>>>>>>>>>>>>>>>> to any caller that essentially calls H in infinite
>>>>>>>>>>>>>>>> recursion.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does
>>>>>>>>>>>>>>> not have any infinite recursion thereby proving that
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It overrode that behavior that was specified by the
>>>>>>>>>>>>>> machine code for Px.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope. You SHD is not a halt decider as
>>>>>>>>>>>>
>>>>>>>>>>>> I was not even talking about my SHD, I was talking about how
>>>>>>>>>>>> your program does its simulation incorrectly.
>>>>>>>>>>>
>>>>>>>>>>> My SSHD does not do its simulation incorrectly: it does its
>>>>>>>>>>> simulation just like I have defined it as evidenced by the
>>>>>>>>>>> fact that it returns a correct halting decision for Px;
>>>>>>>>>>> something your broken SHD gets wrong.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In order for you to have Px simulated by H terminate normally
>>>>>>>>>> you must change the behavior of Px away from the behavior that
>>>>>>>>>> its x86 code specifies.
>>>>>>>>>
>>>>>>>>> Your "x86 code" has nothing to do with how my halt decider
>>>>>>>>> works; I am using an entirely different simulation method, one
>>>>>>>>> that actually works.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>> {
>>>>>>>>>>    (void) H(x, x);
>>>>>>>>>>    return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Px correctly simulated by H cannot possibly reach past its
>>>>>>>>>> machine address of: [00001b3d].
>>>>>>>>>>
>>>>>>>>>> _Px()
>>>>>>>>>> [00001b32] 55         push ebp
>>>>>>>>>> [00001b33] 8bec       mov ebp,esp
>>>>>>>>>> [00001b35] 8b4508     mov eax,[ebp+08]
>>>>>>>>>> [00001b38] 50         push eax      // push address of Px
>>>>>>>>>> [00001b39] 8b4d08     mov ecx,[ebp+08]
>>>>>>>>>> [00001b3c] 51         push ecx      // push address of Px
>>>>>>>>>> [00001b3d] e800faffff call 00001542 // Call H
>>>>>>>>>> [00001b42] 83c408     add esp,+08
>>>>>>>>>> [00001b45] 5d         pop ebp
>>>>>>>>>> [00001b46] c3         ret
>>>>>>>>>> Size in bytes:(0021) [00001b46]
>>>>>>>>>>
>>>>>>>>>> What you are doing is the the same as recognizing that
>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>> never halts, forcing it to break out of its infinite loop and
>>>>>>>>>> jump to
>>>>>>>>>> its "ret" instruction
>>>>>>>>>>
>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>> [00001c62] 55         push ebp
>>>>>>>>>> [00001c63] 8bec       mov ebp,esp
>>>>>>>>>> [00001c65] ebfe       jmp 00001c65
>>>>>>>>>> [00001c67] 5d         pop ebp
>>>>>>>>>> [00001c68] c3         ret
>>>>>>>>>> Size in bytes:(0007) [00001c68]
>>>>>>>>>
>>>>>>>>> No I am not: there is no infinite loop in Px above; forking the
>>>>>>>>> simulation into two branches and returning a different halt
>>>>>>>>> decision to each branch is a perfectly valid SHD design; again
>>>>>>>>> a design, unlike yours, that actually works.
>>>>>>>>
>>>>>>>> If you say that Px correctly simulated by H ever reaches its own
>>>>>>>> final
>>>>>>>> "return" statement and halts you are incorrect.
>>>>>>>
>>>>>>> Px halts if H is (or is part of) a genuine halt decider.
>>>>>>
>>>>>> The simulated Px only halts if it reaches its own final state in a
>>>>>> finite number of steps of correct simulation. It can't possibly do
>>>>>> this.
>>>>>
>>>>> Nope, a correctly simulated Px will allow it to reach its own final
>>>>> state (termination); your H does NOT perform a correct simulation
>>>>> because your H is broken.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> Strawman deception
>>>> Px correctly simulated by H will never reach its own simulated final
>>>> state of "return" because Px and H have a pathological relationship to
>>>> each other.
>>>
>>> Nope, there is no pathological relationship between Px and H because
>>> Px discards the result of H (i.e. it does not try to do the opposite
>>> of the H halting result as per the definition of the Halting Problem).
>>>
>>
>> It seems that you continue to fail to see the nested simulation
>>
>> 01 void Px(void (*x)())
>> 02 {
>> 03  (void) H(x, x);
>> 04  return;
>> 05 }
>> 06
>> 07 void main()
>> 08 {
>> 09  H(Px,Px);
>> 10 }
>>
>> *Execution Trace when H never aborts its simulation*
>> main() calls H(Px,Px) that simulates Px(Px) at line 09
>> *keeps repeating*
>>     simulated Px(Px) calls simulated H(Px,Px) that simulates Px(Px) at
>> line 03 ...
>
> "nested simulation" (recursion) is a property of your broken halt
> decider

On 21/04/2023 10:06 pm, olcott wrote:
> On 4/21/2023 3:02 PM, Mr Flibble wrote:
>> On 21/04/2023 7:36 pm, olcott wrote:
>>> On 4/21/2023 12:42 PM, Mr Flibble wrote:
>>>> On 21/04/2023 5:41 pm, olcott wrote:
>>>>> On 4/21/2023 11:36 AM, Mr Flibble wrote:
>>>>>> On 21/04/2023 4:16 pm, olcott wrote:
>>>>>>> On 4/21/2023 7:17 AM, Mr Flibble wrote:
>>>>>>>> On 20/04/2023 8:20 pm, olcott wrote:
>>>>>>>>> On 4/20/2023 2:08 PM, Mr Flibble wrote:
>>>>>>>>>> On 20/04/2023 6:49 pm, olcott wrote:
>>>>>>>>>>> On 4/20/2023 12:32 PM, Mr Flibble wrote:
>>>>>>>>>>>> On 19/04/2023 11:52 pm, olcott wrote:
>>>>>>>>>>>>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>>>>>>>>>>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>>>>>>>>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> A simulating halt decider correctly predicts
>>>>>>>>>>>>>>>>>>>>>>> whether or not its
>>>>>>>>>>>>>>>>>>>>>>> correctly simulated input can possibly reach its
>>>>>>>>>>>>>>>>>>>>>>> own final state and
>>>>>>>>>>>>>>>>>>>>>>> halt. It does this by correctly recognizing
>>>>>>>>>>>>>>>>>>>>>>> several non-halting behavior
>>>>>>>>>>>>>>>>>>>>>>> patterns in a finite number of steps of correct
>>>>>>>>>>>>>>>>>>>>>>> simulation. Inputs that
>>>>>>>>>>>>>>>>>>>>>>> do terminate are simply simulated until they
>>>>>>>>>>>>>>>>>>>>>>> complete.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Except t doesn't o this for the "pathological"
>>>>>>>>>>>>>>>>>>>>>> program.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The "Pathological Program" when built on such a
>>>>>>>>>>>>>>>>>>>>>> Decider that does give an answer, which you say
>>>>>>>>>>>>>>>>>>>>>> will be non-halting, and then "Correctly
>>>>>>>>>>>>>>>>>>>>>> Simulated" by giving it representation to a UTM,
>>>>>>>>>>>>>>>>>>>>>> we see that the simulation reaches a final state.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the
>>>>>>>>>>>>>>>>>>>>>> problem is you have added a pattern that isn't
>>>>>>>>>>>>>>>>>>>>>> always non-halting.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> When a simulating halt decider correctly
>>>>>>>>>>>>>>>>>>>>>>> simulates N steps of its input
>>>>>>>>>>>>>>>>>>>>>>> it derives the exact same N steps that a pure UTM
>>>>>>>>>>>>>>>>>>>>>>> would derive because
>>>>>>>>>>>>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the
>>>>>>>>>>>>>>>>>>>>>> features you added have removed essential features
>>>>>>>>>>>>>>>>>>>>>> needed for it to be an actual UTM. That you make
>>>>>>>>>>>>>>>>>>>>>> this claim shows you don't actually know what a
>>>>>>>>>>>>>>>>>>>>>> UTM is.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> This is like saying a NASCAR Racing Car is a
>>>>>>>>>>>>>>>>>>>>>> Street Legal vehicle, since it started as one and
>>>>>>>>>>>>>>>>>>>>>> just had some extra features axded.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> My reviewers cannot show that any of the extra
>>>>>>>>>>>>>>>>>>>>>>> features added to the UTM
>>>>>>>>>>>>>>>>>>>>>>> change the behavior of the simulated input for
>>>>>>>>>>>>>>>>>>>>>>> the first N steps of simulation:
>>>>>>>>>>>>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>>>>>>>>>>>>> (b) Matching non-halting behavior patterns
>>>>>>>>>>>>>>>>>>>>>>> doesn't change it
>>>>>>>>>>>>>>>>>>>>>>> (c) Even aborting the simulation after N steps
>>>>>>>>>>>>>>>>>>>>>>> doesn't change the first N steps.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> No one claims that it doesn't correctly reproduce
>>>>>>>>>>>>>>>>>>>>>> the first N steps of the behavior, that is a
>>>>>>>>>>>>>>>>>>>>>> Strawman argumen.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Because of all this we can know that the first N
>>>>>>>>>>>>>>>>>>>>>>> steps of input D
>>>>>>>>>>>>>>>>>>>>>>> simulated by simulating halt decider H are the
>>>>>>>>>>>>>>>>>>>>>>> actual behavior that D
>>>>>>>>>>>>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> *computation that halts*… “the Turing machine
>>>>>>>>>>>>>>>>>>>>>>> will halt whenever it enters a final state”
>>>>>>>>>>>>>>>>>>>>>>> (Linz:1990:234)rrr
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Right, so we are concerned about the behavior of
>>>>>>>>>>>>>>>>>>>>>> the ACTUAL machine, not a partial simulation of it.
>>>>>>>>>>>>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the
>>>>>>>>>>>>>>>>>>>>>> answer is wrong.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> When we see (after N steps) that D correctly
>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot
>>>>>>>>>>>>>>>>>>>>>>> possibly reach its simulated final state in any
>>>>>>>>>>>>>>>>>>>>>>> finite number of steps
>>>>>>>>>>>>>>>>>>>>>>> of correct simulation then we have conclusive
>>>>>>>>>>>>>>>>>>>>>>> proof that D presents non-
>>>>>>>>>>>>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>>>>>>>>>>>>> You agreed that the first N steps are correctly
>>>>>>>>>>>>>>>>>>>>> simulated.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It turns out that the non-halting behavior pattern
>>>>>>>>>>>>>>>>>>>>> is correctly
>>>>>>>>>>>>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Your assumption that a program that calls H is
>>>>>>>>>>>>>>>>>>>> non-halting is erroneous:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> My new paper anchors its ideas in actual Turing
>>>>>>>>>>>>>>>>>>> machines so it is
>>>>>>>>>>>>>>>>>>> unequivocal. The first two pages re only about the
>>>>>>>>>>>>>>>>>>> Linz Turing
>>>>>>>>>>>>>>>>>>> machine based proof.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The H/D material is now on a single page and all
>>>>>>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>>>>>>>>>>>>> analysis entirely in C.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> With this new paper even Richard admits that the
>>>>>>>>>>>>>>>>>>> first N steps
>>>>>>>>>>>>>>>>>>> UTM based simulated by a simulating halt decider are
>>>>>>>>>>>>>>>>>>> necessarily the
>>>>>>>>>>>>>>>>>>> actual behavior of these N steps.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *Simulating (partial) Halt Deciders Defeat the
>>>>>>>>>>>>>>>>>>> Halting Problem Proofs*
>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>      (void) H(x, x);
>>>>>>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Px halts (it discards the result that H returns);
>>>>>>>>>>>>>>>>>>>> your decider thinks that Px is non-halting which is
>>>>>>>>>>>>>>>>>>>> an obvious error due to a design flaw in the
>>>>>>>>>>>>>>>>>>>> architecture of your decider.  Only the Flibble
>>>>>>>>>>>>>>>>>>>> Signaling Simulating Halt Decider (SSHD) correctly
>>>>>>>>>>>>>>>>>>>> handles this case.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nope. For H to be a halt decider it must return a halt
>>>>>>>>>>>>>>>>>> decision to its caller in finite time
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Although H must always return to some caller H is not
>>>>>>>>>>>>>>>>> allowed to return
>>>>>>>>>>>>>>>>> to any caller that essentially calls H in infinite
>>>>>>>>>>>>>>>>> recursion.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The Flibble Signaling Simulating Halt Decider (SSHD)
>>>>>>>>>>>>>>>> does not have any infinite recursion thereby proving that
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It overrode that behavior that was specified by the
>>>>>>>>>>>>>>> machine code for Px.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope. You SHD is not a halt decider as
>>>>>>>>>>>>>
>>>>>>>>>>>>> I was not even talking about my SHD, I was talking about
>>>>>>>>>>>>> how your program does its simulation incorrectly.
>>>>>>>>>>>>
>>>>>>>>>>>> My SSHD does not do its simulation incorrectly: it does its
>>>>>>>>>>>> simulation just like I have defined it as evidenced by the
>>>>>>>>>>>> fact that it returns a correct halting decision for Px;
>>>>>>>>>>>> something your broken SHD gets wrong.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> In order for you to have Px simulated by H terminate normally
>>>>>>>>>>> you must change the behavior of Px away from the behavior
>>>>>>>>>>> that its x86 code specifies.
>>>>>>>>>>
>>>>>>>>>> Your "x86 code" has nothing to do with how my halt decider
>>>>>>>>>> works; I am using an entirely different simulation method, one
>>>>>>>>>> that actually works.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>> {
>>>>>>>>>>>    (void) H(x, x);
>>>>>>>>>>>    return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Px correctly simulated by H cannot possibly reach past its
>>>>>>>>>>> machine address of: [00001b3d].
>>>>>>>>>>>
>>>>>>>>>>> _Px()
>>>>>>>>>>> [00001b32] 55         push ebp
>>>>>>>>>>> [00001b33] 8bec       mov ebp,esp
>>>>>>>>>>> [00001b35] 8b4508     mov eax,[ebp+08]
>>>>>>>>>>> [00001b38] 50         push eax      // push address of Px
>>>>>>>>>>> [00001b39] 8b4d08     mov ecx,[ebp+08]
>>>>>>>>>>> [00001b3c] 51         push ecx      // push address of Px
>>>>>>>>>>> [00001b3d] e800faffff call 00001542 // Call H
>>>>>>>>>>> [00001b42] 83c408     add esp,+08
>>>>>>>>>>> [00001b45] 5d         pop ebp
>>>>>>>>>>> [00001b46] c3         ret
>>>>>>>>>>> Size in bytes:(0021) [00001b46]
>>>>>>>>>>>
>>>>>>>>>>> What you are doing is the the same as recognizing that
>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>> never halts, forcing it to break out of its infinite loop and
>>>>>>>>>>> jump to
>>>>>>>>>>> its "ret" instruction
>>>>>>>>>>>
>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>> [00001c62] 55         push ebp
>>>>>>>>>>> [00001c63] 8bec       mov ebp,esp
>>>>>>>>>>> [00001c65] ebfe       jmp 00001c65
>>>>>>>>>>> [00001c67] 5d         pop ebp
>>>>>>>>>>> [00001c68] c3         ret
>>>>>>>>>>> Size in bytes:(0007) [00001c68]
>>>>>>>>>>
>>>>>>>>>> No I am not: there is no infinite loop in Px above; forking
>>>>>>>>>> the simulation into two branches and returning a different
>>>>>>>>>> halt decision to each branch is a perfectly valid SHD design;
>>>>>>>>>> again a design, unlike yours, that actually works.
>>>>>>>>>
>>>>>>>>> If you say that Px correctly simulated by H ever reaches its
>>>>>>>>> own final
>>>>>>>>> "return" statement and halts you are incorrect.
>>>>>>>>
>>>>>>>> Px halts if H is (or is part of) a genuine halt decider.
>>>>>>>
>>>>>>> The simulated Px only halts if it reaches its own final state in a
>>>>>>> finite number of steps of correct simulation. It can't possibly
>>>>>>> do this.
>>>>>>
>>>>>> Nope, a correctly simulated Px will allow it to reach its own
>>>>>> final state (termination); your H does NOT perform a correct
>>>>>> simulation because your H is broken.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> Strawman deception
>>>>> Px correctly simulated by H will never reach its own simulated final
>>>>> state of "return" because Px and H have a pathological relationship to
>>>>> each other.
>>>>
>>>> Nope, there is no pathological relationship between Px and H because
>>>> Px discards the result of H (i.e. it does not try to do the opposite
>>>> of the H halting result as per the definition of the Halting Problem).
>>>>
>>>
>>> It seems that you continue to fail to see the nested simulation
>>>
>>> 01 void Px(void (*x)())
>>> 02 {
>>> 03  (void) H(x, x);
>>> 04  return;
>>> 05 }
>>> 06
>>> 07 void main()
>>> 08 {
>>> 09  H(Px,Px);
>>> 10 }
>>>
>>> *Execution Trace when H never aborts its simulation*
>>> main() calls H(Px,Px) that simulates Px(Px) at line 09
>>> *keeps repeating*
>>>     simulated Px(Px) calls simulated H(Px,Px) that simulates Px(Px)
>>> at line 03 ...
>>
>> "nested simulation" (recursion) is a property of your broken halt decider
>
> Nested simulation is inherent when any simulating halt decider is
> applied to any of the conventional halting problem counter-example
> inputs. That you may fail to comprehend this is not my mistake.

On 4/21/23 11:16 AM, olcott wrote:
> On 4/21/2023 7:17 AM, Mr Flibble wrote:
>> On 20/04/2023 8:20 pm, olcott wrote:
>>> On 4/20/2023 2:08 PM, Mr Flibble wrote:
>>>> On 20/04/2023 6:49 pm, olcott wrote:
>>>>> On 4/20/2023 12:32 PM, Mr Flibble wrote:
>>>>>> On 19/04/2023 11:52 pm, olcott wrote:
>>>>>>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>>>>>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>>>>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>>>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>>>>>>> A simulating halt decider correctly predicts whether or
>>>>>>>>>>>>>>>>> not its
>>>>>>>>>>>>>>>>> correctly simulated input can possibly reach its own
>>>>>>>>>>>>>>>>> final state and
>>>>>>>>>>>>>>>>> halt. It does this by correctly recognizing several
>>>>>>>>>>>>>>>>> non-halting behavior
>>>>>>>>>>>>>>>>> patterns in a finite number of steps of correct
>>>>>>>>>>>>>>>>> simulation. Inputs that
>>>>>>>>>>>>>>>>> do terminate are simply simulated until they complete.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except t doesn't o this for the "pathological" program.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The "Pathological Program" when built on such a Decider
>>>>>>>>>>>>>>>> that does give an answer, which you say will be
>>>>>>>>>>>>>>>> non-halting, and then "Correctly Simulated" by giving it
>>>>>>>>>>>>>>>> representation to a UTM, we see that the simulation
>>>>>>>>>>>>>>>> reaches a final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the
>>>>>>>>>>>>>>>> problem is you have added a pattern that isn't always
>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When a simulating halt decider correctly simulates N
>>>>>>>>>>>>>>>>> steps of its input
>>>>>>>>>>>>>>>>> it derives the exact same N steps that a pure UTM would
>>>>>>>>>>>>>>>>> derive because
>>>>>>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the
>>>>>>>>>>>>>>>> features you added have removed essential features
>>>>>>>>>>>>>>>> needed for it to be an actual UTM. That you make this
>>>>>>>>>>>>>>>> claim shows you don't actually know what a UTM is.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street
>>>>>>>>>>>>>>>> Legal vehicle, since it started as one and just had some
>>>>>>>>>>>>>>>> extra features axded.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> My reviewers cannot show that any of the extra features
>>>>>>>>>>>>>>>>> added to the UTM
>>>>>>>>>>>>>>>>> change the behavior of the simulated input for the
>>>>>>>>>>>>>>>>> first N steps of simulation:
>>>>>>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't
>>>>>>>>>>>>>>>>> change it
>>>>>>>>>>>>>>>>> (c) Even aborting the simulation after N steps doesn't
>>>>>>>>>>>>>>>>> change the first N steps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No one claims that it doesn't correctly reproduce the
>>>>>>>>>>>>>>>> first N steps of the behavior, that is a Strawman argumen.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because of all this we can know that the first N steps
>>>>>>>>>>>>>>>>> of input D
>>>>>>>>>>>>>>>>> simulated by simulating halt decider H are the actual
>>>>>>>>>>>>>>>>> behavior that D
>>>>>>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *computation that halts*… “the Turing machine will halt
>>>>>>>>>>>>>>>>> whenever it enters a final state” (Linz:1990:234)rrr
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Right, so we are concerned about the behavior of the
>>>>>>>>>>>>>>>> ACTUAL machine, not a partial simulation of it.
>>>>>>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the
>>>>>>>>>>>>>>>> answer is wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When we see (after N steps) that D correctly simulated
>>>>>>>>>>>>>>>>> by H cannot
>>>>>>>>>>>>>>>>> possibly reach its simulated final state in any finite
>>>>>>>>>>>>>>>>> number of steps
>>>>>>>>>>>>>>>>> of correct simulation then we have conclusive proof
>>>>>>>>>>>>>>>>> that D presents non-
>>>>>>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>>>>>>> You agreed that the first N steps are correctly simulated.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It turns out that the non-halting behavior pattern is
>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Your assumption that a program that calls H is non-halting
>>>>>>>>>>>>>> is erroneous:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> My new paper anchors its ideas in actual Turing machines so
>>>>>>>>>>>>> it is
>>>>>>>>>>>>> unequivocal. The first two pages re only about the Linz Turing
>>>>>>>>>>>>> machine based proof.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The H/D material is now on a single page and all reference
>>>>>>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>>>>>>> analysis entirely in C.
>>>>>>>>>>>>>
>>>>>>>>>>>>> With this new paper even Richard admits that the first N steps
>>>>>>>>>>>>> UTM based simulated by a simulating halt decider are
>>>>>>>>>>>>> necessarily the
>>>>>>>>>>>>> actual behavior of these N steps.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting
>>>>>>>>>>>>> Problem Proofs*
>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>>>>>>
>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>      (void) H(x, x);
>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Px halts (it discards the result that H returns); your
>>>>>>>>>>>>>> decider thinks that Px is non-halting which is an obvious
>>>>>>>>>>>>>> error due to a design flaw in the architecture of your
>>>>>>>>>>>>>> decider.  Only the Flibble Signaling Simulating Halt
>>>>>>>>>>>>>> Decider (SSHD) correctly handles this case.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope. For H to be a halt decider it must return a halt
>>>>>>>>>>>> decision to its caller in finite time
>>>>>>>>>>>
>>>>>>>>>>> Although H must always return to some caller H is not allowed
>>>>>>>>>>> to return
>>>>>>>>>>> to any caller that essentially calls H in infinite recursion.
>>>>>>>>>>
>>>>>>>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does not
>>>>>>>>>> have any infinite recursion thereby proving that
>>>>>>>>>
>>>>>>>>> It overrode that behavior that was specified by the machine
>>>>>>>>> code for Px.
>>>>>>>>
>>>>>>>> Nope. You SHD is not a halt decider as
>>>>>>>
>>>>>>> I was not even talking about my SHD, I was talking about how your
>>>>>>> program does its simulation incorrectly.
>>>>>>
>>>>>> My SSHD does not do its simulation incorrectly: it does its
>>>>>> simulation just like I have defined it as evidenced by the fact
>>>>>> that it returns a correct halting decision for Px; something your
>>>>>> broken SHD gets wrong.
>>>>>>
>>>>>
>>>>> In order for you to have Px simulated by H terminate normally you
>>>>> must change the behavior of Px away from the behavior that its x86
>>>>> code specifies.
>>>>
>>>> Your "x86 code" has nothing to do with how my halt decider works; I
>>>> am using an entirely different simulation method, one that actually
>>>> works.
>>>>
>>>>>
>>>>> void Px(void (*x)())
>>>>> {
>>>>>    (void) H(x, x);
>>>>>    return;
>>>>> }
>>>>>
>>>>> Px correctly simulated by H cannot possibly reach past its machine
>>>>> address of: [00001b3d].
>>>>>
>>>>> _Px()
>>>>> [00001b32] 55         push ebp
>>>>> [00001b33] 8bec       mov ebp,esp
>>>>> [00001b35] 8b4508     mov eax,[ebp+08]
>>>>> [00001b38] 50         push eax      // push address of Px
>>>>> [00001b39] 8b4d08     mov ecx,[ebp+08]
>>>>> [00001b3c] 51         push ecx      // push address of Px
>>>>> [00001b3d] e800faffff call 00001542 // Call H
>>>>> [00001b42] 83c408     add esp,+08
>>>>> [00001b45] 5d         pop ebp
>>>>> [00001b46] c3         ret
>>>>> Size in bytes:(0021) [00001b46]
>>>>>
>>>>> What you are doing is the the same as recognizing that
>>>>> _Infinite_Loop()
>>>>> never halts, forcing it to break out of its infinite loop and jump to
>>>>> its "ret" instruction
>>>>>
>>>>> _Infinite_Loop()
>>>>> [00001c62] 55         push ebp
>>>>> [00001c63] 8bec       mov ebp,esp
>>>>> [00001c65] ebfe       jmp 00001c65
>>>>> [00001c67] 5d         pop ebp
>>>>> [00001c68] c3         ret
>>>>> Size in bytes:(0007) [00001c68]
>>>>
>>>> No I am not: there is no infinite loop in Px above; forking the
>>>> simulation into two branches and returning a different halt decision
>>>> to each branch is a perfectly valid SHD design; again a design,
>>>> unlike yours, that actually works.
>>>
>>> If you say that Px correctly simulated by H ever reaches its own final
>>> "return" statement and halts you are incorrect.
>>
>> Px halts if H is (or is part of) a genuine halt decider.
>
> The simulated Px only halts if it reaches its own final state in a
> finite number of steps of correct simulation. It can't possibly do this.

On 4/21/2023 5:34 PM, Richard Damon wrote:
> On 4/21/23 11:16 AM, olcott wrote:
>> On 4/21/2023 7:17 AM, Mr Flibble wrote:
>>> On 20/04/2023 8:20 pm, olcott wrote:
>>>> On 4/20/2023 2:08 PM, Mr Flibble wrote:
>>>>> On 20/04/2023 6:49 pm, olcott wrote:
>>>>>> On 4/20/2023 12:32 PM, Mr Flibble wrote:
>>>>>>> On 19/04/2023 11:52 pm, olcott wrote:
>>>>>>>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>>>>>>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>>>>>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>>>>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>>>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>>>>>>>> A simulating halt decider correctly predicts whether
>>>>>>>>>>>>>>>>>> or not its
>>>>>>>>>>>>>>>>>> correctly simulated input can possibly reach its own
>>>>>>>>>>>>>>>>>> final state and
>>>>>>>>>>>>>>>>>> halt. It does this by correctly recognizing several
>>>>>>>>>>>>>>>>>> non-halting behavior
>>>>>>>>>>>>>>>>>> patterns in a finite number of steps of correct
>>>>>>>>>>>>>>>>>> simulation. Inputs that
>>>>>>>>>>>>>>>>>> do terminate are simply simulated until they complete.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Except t doesn't o this for the "pathological" program.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The "Pathological Program" when built on such a Decider
>>>>>>>>>>>>>>>>> that does give an answer, which you say will be
>>>>>>>>>>>>>>>>> non-halting, and then "Correctly Simulated" by giving
>>>>>>>>>>>>>>>>> it representation to a UTM, we see that the simulation
>>>>>>>>>>>>>>>>> reaches a final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the
>>>>>>>>>>>>>>>>> problem is you have added a pattern that isn't always
>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When a simulating halt decider correctly simulates N
>>>>>>>>>>>>>>>>>> steps of its input
>>>>>>>>>>>>>>>>>> it derives the exact same N steps that a pure UTM
>>>>>>>>>>>>>>>>>> would derive because
>>>>>>>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the
>>>>>>>>>>>>>>>>> features you added have removed essential features
>>>>>>>>>>>>>>>>> needed for it to be an actual UTM. That you make this
>>>>>>>>>>>>>>>>> claim shows you don't actually know what a UTM is.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street
>>>>>>>>>>>>>>>>> Legal vehicle, since it started as one and just had
>>>>>>>>>>>>>>>>> some extra features axded.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> My reviewers cannot show that any of the extra
>>>>>>>>>>>>>>>>>> features added to the UTM
>>>>>>>>>>>>>>>>>> change the behavior of the simulated input for the
>>>>>>>>>>>>>>>>>> first N steps of simulation:
>>>>>>>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't
>>>>>>>>>>>>>>>>>> change it
>>>>>>>>>>>>>>>>>> (c) Even aborting the simulation after N steps doesn't
>>>>>>>>>>>>>>>>>> change the first N steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No one claims that it doesn't correctly reproduce the
>>>>>>>>>>>>>>>>> first N steps of the behavior, that is a Strawman argumen.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Because of all this we can know that the first N steps
>>>>>>>>>>>>>>>>>> of input D
>>>>>>>>>>>>>>>>>> simulated by simulating halt decider H are the actual
>>>>>>>>>>>>>>>>>> behavior that D
>>>>>>>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *computation that halts*… “the Turing machine will
>>>>>>>>>>>>>>>>>> halt whenever it enters a final state” (Linz:1990:234)rrr
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Right, so we are concerned about the behavior of the
>>>>>>>>>>>>>>>>> ACTUAL machine, not a partial simulation of it.
>>>>>>>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the
>>>>>>>>>>>>>>>>> answer is wrong.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When we see (after N steps) that D correctly simulated
>>>>>>>>>>>>>>>>>> by H cannot
>>>>>>>>>>>>>>>>>> possibly reach its simulated final state in any finite
>>>>>>>>>>>>>>>>>> number of steps
>>>>>>>>>>>>>>>>>> of correct simulation then we have conclusive proof
>>>>>>>>>>>>>>>>>> that D presents non-
>>>>>>>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>>>>>>>> You agreed that the first N steps are correctly simulated.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It turns out that the non-halting behavior pattern is
>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Your assumption that a program that calls H is
>>>>>>>>>>>>>>> non-halting is erroneous:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> My new paper anchors its ideas in actual Turing machines
>>>>>>>>>>>>>> so it is
>>>>>>>>>>>>>> unequivocal. The first two pages re only about the Linz
>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>> machine based proof.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The H/D material is now on a single page and all reference
>>>>>>>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>>>>>>>> analysis entirely in C.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With this new paper even Richard admits that the first N
>>>>>>>>>>>>>> steps
>>>>>>>>>>>>>> UTM based simulated by a simulating halt decider are
>>>>>>>>>>>>>> necessarily the
>>>>>>>>>>>>>> actual behavior of these N steps.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting
>>>>>>>>>>>>>> Problem Proofs*
>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>      (void) H(x, x);
>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Px halts (it discards the result that H returns); your
>>>>>>>>>>>>>>> decider thinks that Px is non-halting which is an obvious
>>>>>>>>>>>>>>> error due to a design flaw in the architecture of your
>>>>>>>>>>>>>>> decider.  Only the Flibble Signaling Simulating Halt
>>>>>>>>>>>>>>> Decider (SSHD) correctly handles this case.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope. For H to be a halt decider it must return a halt
>>>>>>>>>>>>> decision to its caller in finite time
>>>>>>>>>>>>
>>>>>>>>>>>> Although H must always return to some caller H is not
>>>>>>>>>>>> allowed to return
>>>>>>>>>>>> to any caller that essentially calls H in infinite recursion.
>>>>>>>>>>>
>>>>>>>>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does not
>>>>>>>>>>> have any infinite recursion thereby proving that
>>>>>>>>>>
>>>>>>>>>> It overrode that behavior that was specified by the machine
>>>>>>>>>> code for Px.
>>>>>>>>>
>>>>>>>>> Nope. You SHD is not a halt decider as
>>>>>>>>
>>>>>>>> I was not even talking about my SHD, I was talking about how
>>>>>>>> your program does its simulation incorrectly.
>>>>>>>
>>>>>>> My SSHD does not do its simulation incorrectly: it does its
>>>>>>> simulation just like I have defined it as evidenced by the fact
>>>>>>> that it returns a correct halting decision for Px; something your
>>>>>>> broken SHD gets wrong.
>>>>>>>
>>>>>>
>>>>>> In order for you to have Px simulated by H terminate normally you
>>>>>> must change the behavior of Px away from the behavior that its x86
>>>>>> code specifies.
>>>>>
>>>>> Your "x86 code" has nothing to do with how my halt decider works; I
>>>>> am using an entirely different simulation method, one that actually
>>>>> works.
>>>>>
>>>>>>
>>>>>> void Px(void (*x)())
>>>>>> {
>>>>>>    (void) H(x, x);
>>>>>>    return;
>>>>>> }
>>>>>>
>>>>>> Px correctly simulated by H cannot possibly reach past its machine
>>>>>> address of: [00001b3d].
>>>>>>
>>>>>> _Px()
>>>>>> [00001b32] 55         push ebp
>>>>>> [00001b33] 8bec       mov ebp,esp
>>>>>> [00001b35] 8b4508     mov eax,[ebp+08]
>>>>>> [00001b38] 50         push eax      // push address of Px
>>>>>> [00001b39] 8b4d08     mov ecx,[ebp+08]
>>>>>> [00001b3c] 51         push ecx      // push address of Px
>>>>>> [00001b3d] e800faffff call 00001542 // Call H
>>>>>> [00001b42] 83c408     add esp,+08
>>>>>> [00001b45] 5d         pop ebp
>>>>>> [00001b46] c3         ret
>>>>>> Size in bytes:(0021) [00001b46]
>>>>>>
>>>>>> What you are doing is the the same as recognizing that
>>>>>> _Infinite_Loop()
>>>>>> never halts, forcing it to break out of its infinite loop and jump to
>>>>>> its "ret" instruction
>>>>>>
>>>>>> _Infinite_Loop()
>>>>>> [00001c62] 55         push ebp
>>>>>> [00001c63] 8bec       mov ebp,esp
>>>>>> [00001c65] ebfe       jmp 00001c65
>>>>>> [00001c67] 5d         pop ebp
>>>>>> [00001c68] c3         ret
>>>>>> Size in bytes:(0007) [00001c68]
>>>>>
>>>>> No I am not: there is no infinite loop in Px above; forking the
>>>>> simulation into two branches and returning a different halt
>>>>> decision to each branch is a perfectly valid SHD design; again a
>>>>> design, unlike yours, that actually works.
>>>>
>>>> If you say that Px correctly simulated by H ever reaches its own final
>>>> "return" statement and halts you are incorrect.
>>>
>>> Px halts if H is (or is part of) a genuine halt decider.
>>
>> The simulated Px only halts if it reaches its own final state in a
>> finite number of steps of correct simulation. It can't possibly do this.
>
> So, you're saying that a UTM doesn't do a "Correct Simulation"?
>

On 4/21/23 7:18 PM, olcott wrote:
> On 4/21/2023 5:34 PM, Richard Damon wrote:
>> On 4/21/23 11:16 AM, olcott wrote:
>>> On 4/21/2023 7:17 AM, Mr Flibble wrote:
>>>> On 20/04/2023 8:20 pm, olcott wrote:
>>>>> On 4/20/2023 2:08 PM, Mr Flibble wrote:
>>>>>> On 20/04/2023 6:49 pm, olcott wrote:
>>>>>>> On 4/20/2023 12:32 PM, Mr Flibble wrote:
>>>>>>>> On 19/04/2023 11:52 pm, olcott wrote:
>>>>>>>>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>>>>>>>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>>>>>>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>>>>>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>>>>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> A simulating halt decider correctly predicts whether
>>>>>>>>>>>>>>>>>>> or not its
>>>>>>>>>>>>>>>>>>> correctly simulated input can possibly reach its own
>>>>>>>>>>>>>>>>>>> final state and
>>>>>>>>>>>>>>>>>>> halt. It does this by correctly recognizing several
>>>>>>>>>>>>>>>>>>> non-halting behavior
>>>>>>>>>>>>>>>>>>> patterns in a finite number of steps of correct
>>>>>>>>>>>>>>>>>>> simulation. Inputs that
>>>>>>>>>>>>>>>>>>> do terminate are simply simulated until they complete.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Except t doesn't o this for the "pathological" program.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The "Pathological Program" when built on such a
>>>>>>>>>>>>>>>>>> Decider that does give an answer, which you say will
>>>>>>>>>>>>>>>>>> be non-halting, and then "Correctly Simulated" by
>>>>>>>>>>>>>>>>>> giving it representation to a UTM, we see that the
>>>>>>>>>>>>>>>>>> simulation reaches a final state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the
>>>>>>>>>>>>>>>>>> problem is you have added a pattern that isn't always
>>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When a simulating halt decider correctly simulates N
>>>>>>>>>>>>>>>>>>> steps of its input
>>>>>>>>>>>>>>>>>>> it derives the exact same N steps that a pure UTM
>>>>>>>>>>>>>>>>>>> would derive because
>>>>>>>>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the
>>>>>>>>>>>>>>>>>> features you added have removed essential features
>>>>>>>>>>>>>>>>>> needed for it to be an actual UTM. That you make this
>>>>>>>>>>>>>>>>>> claim shows you don't actually know what a UTM is.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street
>>>>>>>>>>>>>>>>>> Legal vehicle, since it started as one and just had
>>>>>>>>>>>>>>>>>> some extra features axded.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> My reviewers cannot show that any of the extra
>>>>>>>>>>>>>>>>>>> features added to the UTM
>>>>>>>>>>>>>>>>>>> change the behavior of the simulated input for the
>>>>>>>>>>>>>>>>>>> first N steps of simulation:
>>>>>>>>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't
>>>>>>>>>>>>>>>>>>> change it
>>>>>>>>>>>>>>>>>>> (c) Even aborting the simulation after N steps
>>>>>>>>>>>>>>>>>>> doesn't change the first N steps.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No one claims that it doesn't correctly reproduce the
>>>>>>>>>>>>>>>>>> first N steps of the behavior, that is a Strawman
>>>>>>>>>>>>>>>>>> argumen.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Because of all this we can know that the first N
>>>>>>>>>>>>>>>>>>> steps of input D
>>>>>>>>>>>>>>>>>>> simulated by simulating halt decider H are the actual
>>>>>>>>>>>>>>>>>>> behavior that D
>>>>>>>>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *computation that halts*… “the Turing machine will
>>>>>>>>>>>>>>>>>>> halt whenever it enters a final state”
>>>>>>>>>>>>>>>>>>> (Linz:1990:234)rrr
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Right, so we are concerned about the behavior of the
>>>>>>>>>>>>>>>>>> ACTUAL machine, not a partial simulation of it.
>>>>>>>>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the
>>>>>>>>>>>>>>>>>> answer is wrong.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When we see (after N steps) that D correctly
>>>>>>>>>>>>>>>>>>> simulated by H cannot
>>>>>>>>>>>>>>>>>>> possibly reach its simulated final state in any
>>>>>>>>>>>>>>>>>>> finite number of steps
>>>>>>>>>>>>>>>>>>> of correct simulation then we have conclusive proof
>>>>>>>>>>>>>>>>>>> that D presents non-
>>>>>>>>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>>>>>>>>> You agreed that the first N steps are correctly simulated.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It turns out that the non-halting behavior pattern is
>>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Your assumption that a program that calls H is
>>>>>>>>>>>>>>>> non-halting is erroneous:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My new paper anchors its ideas in actual Turing machines
>>>>>>>>>>>>>>> so it is
>>>>>>>>>>>>>>> unequivocal. The first two pages re only about the Linz
>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>> machine based proof.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The H/D material is now on a single page and all reference
>>>>>>>>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>>>>>>>>> analysis entirely in C.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> With this new paper even Richard admits that the first N
>>>>>>>>>>>>>>> steps
>>>>>>>>>>>>>>> UTM based simulated by a simulating halt decider are
>>>>>>>>>>>>>>> necessarily the
>>>>>>>>>>>>>>> actual behavior of these N steps.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting
>>>>>>>>>>>>>>> Problem Proofs*
>>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>      (void) H(x, x);
>>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Px halts (it discards the result that H returns); your
>>>>>>>>>>>>>>>> decider thinks that Px is non-halting which is an
>>>>>>>>>>>>>>>> obvious error due to a design flaw in the architecture
>>>>>>>>>>>>>>>> of your decider.  Only the Flibble Signaling Simulating
>>>>>>>>>>>>>>>> Halt Decider (SSHD) correctly handles this case.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope. For H to be a halt decider it must return a halt
>>>>>>>>>>>>>> decision to its caller in finite time
>>>>>>>>>>>>>
>>>>>>>>>>>>> Although H must always return to some caller H is not
>>>>>>>>>>>>> allowed to return
>>>>>>>>>>>>> to any caller that essentially calls H in infinite recursion.
>>>>>>>>>>>>
>>>>>>>>>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does
>>>>>>>>>>>> not have any infinite recursion thereby proving that
>>>>>>>>>>>
>>>>>>>>>>> It overrode that behavior that was specified by the machine
>>>>>>>>>>> code for Px.
>>>>>>>>>>
>>>>>>>>>> Nope. You SHD is not a halt decider as
>>>>>>>>>
>>>>>>>>> I was not even talking about my SHD, I was talking about how
>>>>>>>>> your program does its simulation incorrectly.
>>>>>>>>
>>>>>>>> My SSHD does not do its simulation incorrectly: it does its
>>>>>>>> simulation just like I have defined it as evidenced by the fact
>>>>>>>> that it returns a correct halting decision for Px; something
>>>>>>>> your broken SHD gets wrong.
>>>>>>>>
>>>>>>>
>>>>>>> In order for you to have Px simulated by H terminate normally you
>>>>>>> must change the behavior of Px away from the behavior that its
>>>>>>> x86 code specifies.
>>>>>>
>>>>>> Your "x86 code" has nothing to do with how my halt decider works;
>>>>>> I am using an entirely different simulation method, one that
>>>>>> actually works.
>>>>>>
>>>>>>>
>>>>>>> void Px(void (*x)())
>>>>>>> {
>>>>>>>    (void) H(x, x);
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> Px correctly simulated by H cannot possibly reach past its
>>>>>>> machine address of: [00001b3d].
>>>>>>>
>>>>>>> _Px()
>>>>>>> [00001b32] 55         push ebp
>>>>>>> [00001b33] 8bec       mov ebp,esp
>>>>>>> [00001b35] 8b4508     mov eax,[ebp+08]
>>>>>>> [00001b38] 50         push eax      // push address of Px
>>>>>>> [00001b39] 8b4d08     mov ecx,[ebp+08]
>>>>>>> [00001b3c] 51         push ecx      // push address of Px
>>>>>>> [00001b3d] e800faffff call 00001542 // Call H
>>>>>>> [00001b42] 83c408     add esp,+08
>>>>>>> [00001b45] 5d         pop ebp
>>>>>>> [00001b46] c3         ret
>>>>>>> Size in bytes:(0021) [00001b46]
>>>>>>>
>>>>>>> What you are doing is the the same as recognizing that
>>>>>>> _Infinite_Loop()
>>>>>>> never halts, forcing it to break out of its infinite loop and
>>>>>>> jump to
>>>>>>> its "ret" instruction
>>>>>>>
>>>>>>> _Infinite_Loop()
>>>>>>> [00001c62] 55         push ebp
>>>>>>> [00001c63] 8bec       mov ebp,esp
>>>>>>> [00001c65] ebfe       jmp 00001c65
>>>>>>> [00001c67] 5d         pop ebp
>>>>>>> [00001c68] c3         ret
>>>>>>> Size in bytes:(0007) [00001c68]
>>>>>>
>>>>>> No I am not: there is no infinite loop in Px above; forking the
>>>>>> simulation into two branches and returning a different halt
>>>>>> decision to each branch is a perfectly valid SHD design; again a
>>>>>> design, unlike yours, that actually works.
>>>>>
>>>>> If you say that Px correctly simulated by H ever reaches its own final
>>>>> "return" statement and halts you are incorrect.
>>>>
>>>> Px halts if H is (or is part of) a genuine halt decider.
>>>
>>> The simulated Px only halts if it reaches its own final state in a
>>> finite number of steps of correct simulation. It can't possibly do this.
>>
>> So, you're saying that a UTM doesn't do a "Correct Simulation"?
>>
>
> Always with the strawman error.
> I am saying that when Px is correctly simulated by H it cannot possibly
> reach its own simulated "return" instruction in any finite number of
> steps because Px is defined to have a pathological relationship to H.

On 22/04/2023 12:18 am, olcott wrote:
> On 4/21/2023 5:34 PM, Richard Damon wrote:
>> On 4/21/23 11:16 AM, olcott wrote:
>>> On 4/21/2023 7:17 AM, Mr Flibble wrote:
>>>> On 20/04/2023 8:20 pm, olcott wrote:
>>>>> On 4/20/2023 2:08 PM, Mr Flibble wrote:
>>>>>> On 20/04/2023 6:49 pm, olcott wrote:
>>>>>>> On 4/20/2023 12:32 PM, Mr Flibble wrote:
>>>>>>>> On 19/04/2023 11:52 pm, olcott wrote:
>>>>>>>>> On 4/19/2023 4:14 PM, Mr Flibble wrote:
>>>>>>>>>> On 19/04/2023 10:10 pm, olcott wrote:
>>>>>>>>>>> On 4/19/2023 3:32 PM, Mr Flibble wrote:
>>>>>>>>>>>> On 19/04/2023 8:39 pm, olcott wrote:
>>>>>>>>>>>>> On 4/19/2023 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On 18/04/2023 11:39 pm, olcott wrote:
>>>>>>>>>>>>>>> On 4/18/2023 4:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On 18/04/2023 4:58 pm, olcott wrote:
>>>>>>>>>>>>>>>>> On 4/18/2023 6:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 4/18/23 1:00 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> A simulating halt decider correctly predicts whether
>>>>>>>>>>>>>>>>>>> or not its
>>>>>>>>>>>>>>>>>>> correctly simulated input can possibly reach its own
>>>>>>>>>>>>>>>>>>> final state and
>>>>>>>>>>>>>>>>>>> halt. It does this by correctly recognizing several
>>>>>>>>>>>>>>>>>>> non-halting behavior
>>>>>>>>>>>>>>>>>>> patterns in a finite number of steps of correct
>>>>>>>>>>>>>>>>>>> simulation. Inputs that
>>>>>>>>>>>>>>>>>>> do terminate are simply simulated until they complete.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Except t doesn't o this for the "pathological" program.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The "Pathological Program" when built on such a
>>>>>>>>>>>>>>>>>> Decider that does give an answer, which you say will
>>>>>>>>>>>>>>>>>> be non-halting, and then "Correctly Simulated" by
>>>>>>>>>>>>>>>>>> giving it representation to a UTM, we see that the
>>>>>>>>>>>>>>>>>> simulation reaches a final state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thus, your H was WRONG t make the answer. And the
>>>>>>>>>>>>>>>>>> problem is you have added a pattern that isn't always
>>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When a simulating halt decider correctly simulates N
>>>>>>>>>>>>>>>>>>> steps of its input
>>>>>>>>>>>>>>>>>>> it derives the exact same N steps that a pure UTM
>>>>>>>>>>>>>>>>>>> would derive because
>>>>>>>>>>>>>>>>>>> it is itself a UTM with extra features.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> But if ISN'T a "UTM" any more, because some of the
>>>>>>>>>>>>>>>>>> features you added have removed essential features
>>>>>>>>>>>>>>>>>> needed for it to be an actual UTM. That you make this
>>>>>>>>>>>>>>>>>> claim shows you don't actually know what a UTM is.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This is like saying a NASCAR Racing Car is a Street
>>>>>>>>>>>>>>>>>> Legal vehicle, since it started as one and just had
>>>>>>>>>>>>>>>>>> some extra features axded.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> My reviewers cannot show that any of the extra
>>>>>>>>>>>>>>>>>>> features added to the UTM
>>>>>>>>>>>>>>>>>>> change the behavior of the simulated input for the
>>>>>>>>>>>>>>>>>>> first N steps of simulation:
>>>>>>>>>>>>>>>>>>> (a) Watching the behavior doesn't change it.
>>>>>>>>>>>>>>>>>>> (b) Matching non-halting behavior patterns doesn't
>>>>>>>>>>>>>>>>>>> change it
>>>>>>>>>>>>>>>>>>> (c) Even aborting the simulation after N steps
>>>>>>>>>>>>>>>>>>> doesn't change the first N steps.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No one claims that it doesn't correctly reproduce the
>>>>>>>>>>>>>>>>>> first N steps of the behavior, that is a Strawman
>>>>>>>>>>>>>>>>>> argumen.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Because of all this we can know that the first N
>>>>>>>>>>>>>>>>>>> steps of input D
>>>>>>>>>>>>>>>>>>> simulated by simulating halt decider H are the actual
>>>>>>>>>>>>>>>>>>> behavior that D
>>>>>>>>>>>>>>>>>>> presents to H for these same N steps.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *computation that halts*… “the Turing machine will
>>>>>>>>>>>>>>>>>>> halt whenever it enters a final state”
>>>>>>>>>>>>>>>>>>> (Linz:1990:234)rrr
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Right, so we are concerned about the behavior of the
>>>>>>>>>>>>>>>>>> ACTUAL machine, not a partial simulation of it.
>>>>>>>>>>>>>>>>>> H(D,D) returns non-halting, but D(D) Halts, so the
>>>>>>>>>>>>>>>>>> answer is wrong.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When we see (after N steps) that D correctly
>>>>>>>>>>>>>>>>>>> simulated by H cannot
>>>>>>>>>>>>>>>>>>> possibly reach its simulated final state in any
>>>>>>>>>>>>>>>>>>> finite number of steps
>>>>>>>>>>>>>>>>>>> of correct simulation then we have conclusive proof
>>>>>>>>>>>>>>>>>>> that D presents non-
>>>>>>>>>>>>>>>>>>> halting behavior to H.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> But it isn't "Correctly Simulated by H"
>>>>>>>>>>>>>>>>> You agreed that the first N steps are correctly simulated.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It turns out that the non-halting behavior pattern is
>>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>>> recognized in the first N steps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Your assumption that a program that calls H is
>>>>>>>>>>>>>>>> non-halting is erroneous:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My new paper anchors its ideas in actual Turing machines
>>>>>>>>>>>>>>> so it is
>>>>>>>>>>>>>>> unequivocal. The first two pages re only about the Linz
>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>> machine based proof.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The H/D material is now on a single page and all reference
>>>>>>>>>>>>>>> to the x86 language has been stripped and replaced with
>>>>>>>>>>>>>>> analysis entirely in C.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> With this new paper even Richard admits that the first N
>>>>>>>>>>>>>>> steps
>>>>>>>>>>>>>>> UTM based simulated by a simulating halt decider are
>>>>>>>>>>>>>>> necessarily the
>>>>>>>>>>>>>>> actual behavior of these N steps.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Simulating (partial) Halt Deciders Defeat the Halting
>>>>>>>>>>>>>>> Problem Proofs*
>>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>      (void) H(x, x);
>>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Px halts (it discards the result that H returns); your
>>>>>>>>>>>>>>>> decider thinks that Px is non-halting which is an
>>>>>>>>>>>>>>>> obvious error due to a design flaw in the architecture
>>>>>>>>>>>>>>>> of your decider.  Only the Flibble Signaling Simulating
>>>>>>>>>>>>>>>> Halt Decider (SSHD) correctly handles this case.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope. For H to be a halt decider it must return a halt
>>>>>>>>>>>>>> decision to its caller in finite time
>>>>>>>>>>>>>
>>>>>>>>>>>>> Although H must always return to some caller H is not
>>>>>>>>>>>>> allowed to return
>>>>>>>>>>>>> to any caller that essentially calls H in infinite recursion.
>>>>>>>>>>>>
>>>>>>>>>>>> The Flibble Signaling Simulating Halt Decider (SSHD) does
>>>>>>>>>>>> not have any infinite recursion thereby proving that
>>>>>>>>>>>
>>>>>>>>>>> It overrode that behavior that was specified by the machine
>>>>>>>>>>> code for Px.
>>>>>>>>>>
>>>>>>>>>> Nope. You SHD is not a halt decider as
>>>>>>>>>
>>>>>>>>> I was not even talking about my SHD, I was talking about how
>>>>>>>>> your program does its simulation incorrectly.
>>>>>>>>
>>>>>>>> My SSHD does not do its simulation incorrectly: it does its
>>>>>>>> simulation just like I have defined it as evidenced by the fact
>>>>>>>> that it returns a correct halting decision for Px; something
>>>>>>>> your broken SHD gets wrong.
>>>>>>>>
>>>>>>>
>>>>>>> In order for you to have Px simulated by H terminate normally you
>>>>>>> must change the behavior of Px away from the behavior that its
>>>>>>> x86 code specifies.
>>>>>>
>>>>>> Your "x86 code" has nothing to do with how my halt decider works;
>>>>>> I am using an entirely different simulation method, one that
>>>>>> actually works.
>>>>>>
>>>>>>>
>>>>>>> void Px(void (*x)())
>>>>>>> {
>>>>>>>    (void) H(x, x);
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> Px correctly simulated by H cannot possibly reach past its
>>>>>>> machine address of: [00001b3d].
>>>>>>>
>>>>>>> _Px()
>>>>>>> [00001b32] 55         push ebp
>>>>>>> [00001b33] 8bec       mov ebp,esp
>>>>>>> [00001b35] 8b4508     mov eax,[ebp+08]
>>>>>>> [00001b38] 50         push eax      // push address of Px
>>>>>>> [00001b39] 8b4d08     mov ecx,[ebp+08]
>>>>>>> [00001b3c] 51         push ecx      // push address of Px
>>>>>>> [00001b3d] e800faffff call 00001542 // Call H
>>>>>>> [00001b42] 83c408     add esp,+08
>>>>>>> [00001b45] 5d         pop ebp
>>>>>>> [00001b46] c3         ret
>>>>>>> Size in bytes:(0021) [00001b46]
>>>>>>>
>>>>>>> What you are doing is the the same as recognizing that
>>>>>>> _Infinite_Loop()
>>>>>>> never halts, forcing it to break out of its infinite loop and
>>>>>>> jump to
>>>>>>> its "ret" instruction
>>>>>>>
>>>>>>> _Infinite_Loop()
>>>>>>> [00001c62] 55         push ebp
>>>>>>> [00001c63] 8bec       mov ebp,esp
>>>>>>> [00001c65] ebfe       jmp 00001c65
>>>>>>> [00001c67] 5d         pop ebp
>>>>>>> [00001c68] c3         ret
>>>>>>> Size in bytes:(0007) [00001c68]
>>>>>>
>>>>>> No I am not: there is no infinite loop in Px above; forking the
>>>>>> simulation into two branches and returning a different halt
>>>>>> decision to each branch is a perfectly valid SHD design; again a
>>>>>> design, unlike yours, that actually works.
>>>>>
>>>>> If you say that Px correctly simulated by H ever reaches its own final
>>>>> "return" statement and halts you are incorrect.
>>>>
>>>> Px halts if H is (or is part of) a genuine halt decider.
>>>
>>> The simulated Px only halts if it reaches its own final state in a
>>> finite number of steps of correct simulation. It can't possibly do this.
>>
>> So, you're saying that a UTM doesn't do a "Correct Simulation"?
>>
>
> Always with the strawman error.
> I am saying that when Px is correctly simulated by H it cannot possibly
> reach its own simulated "return" instruction in any finite number of
> steps because Px is defined to have a pathological relationship to H.
>
> When we examine the behavior of Px simulated by a pure simulator or even
> another simulating halt decider such as H1 having no such pathological
> relationship as the basis of the actual behavior of the input to H we
> are comparing apples to lemons and rejecting the apples because lemons
> are too sour.