On 8/1/2022 6:17 AM, Richard Damon wrote:
>
> On 7/31/22 11:46 PM, olcott wrote:
>> On 7/31/2022 9:58 PM, Dennis Bush wrote:
>>> On Sunday, July 31, 2022 at 10:32:39 PM UTC-4, olcott wrote:
>>>> On 7/31/2022 9:20 PM, Dennis Bush wrote:
>>>>> On Sunday, July 31, 2022 at 10:00:34 PM UTC-4, olcott wrote:
>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that
>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>> never
>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its
>>>>>>>>>>>>>>>> input:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>> emulator...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation.
>>>>>>>>>>>>>>> If H ever
>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Good, I agree.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY
>>>>>>>>>>>>>>> determine that
>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>> NEVER
>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the
>>>>>>>>>>>>>>> input is
>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
>>>>>>>>>>>>>>> stops its
>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P)
>>>>>>>>>>>>>>> to Halt.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P)
>>>>>>>>>>>>>>> if H is
>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
>>>>>>>>>>>>>>> return 0
>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
>>>>>>>>>>>>>>> Halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
>>>>>>>>>>>>>>> generate a
>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
>>>>>>>>>>>>>>> provide the
>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different,
>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
>>>>>>>>>>>>>>> "proof"
>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
>>>>>>>>>>>>>>> invalid, and
>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
>>>>>>>>>>>>>>> into the
>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is
>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret"
>>>>>>>>>>>>>>>> instruction
>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So you believe that when H aborts its simulation this
>>>>>>>>>>>>>> causes the
>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it
>>>>>>>>>>>>>> has been
>>>>>>>>>>>>>> aborted before reaching this instruction?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Unless you reverse your position technically competent
>>>>>>>>>>>>>> reviewers
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> understand that you are not a sufficiently technically
>>>>>>>>>>>>>> competent
>>>>>>>>>>>>>> reviewer.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>> the input will reach the return instruction.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that
>>>>>>>>>>>>>> is no
>>>>>>>>>>>>>> longer
>>>>>>>>>>>>>> running will continue several more execution steps and
>>>>>>>>>>>>>> reach its
>>>>>>>>>>>>>> "ret"
>>>>>>>>>>>>>> instruction even though it has been forced to stop running
>>>>>>>>>>>>>> before ever
>>>>>>>>>>>>>> reaching the "ret" instruction.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
>>>>>>>>>>>> There is only a simulated P in the following:
>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>
>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>> {
>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>> }
>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
>>>>>>>>>>>> simulated
>>>>>>>>>>>> by H
>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
>>>>>>>>>>>> whether
>>>>>>>>>>>> or not H aborts its simulation or not?
>>>>>>>>>>>
>>>>>>>>>>> Yes, I agree that there is no implementation of the function
>>>>>>>>>>> H that
>>>>>>>>>>> can simulate the function call P(P) to a final state. Which has
>>>>>>>>>>> nothing to do with the requirements of a halt decider.
>>>>>>>>>>>
>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>>>>>>>>>>
>>>>>>>>>> In other words you are saying that this is incorrect:
>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>> accept
>>>>>>>>>> or reject state on the basis of the actual behavior that is
>>>>>>>>>> actually
>>>>>>>>>> specified by these inputs.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
>>>>>>>>> behavior of the program the input represents,
>>>>>>>> In other words you do not believe that the correct simulation of an
>>>>>>>> input necessarily has the exact same sequence of instructions
>>>>>>>> that are
>>>>>>>> specified by this input, thus you reject the concept of UTM
>>>>>>>> simulation.
>>>>>>>>
>>>>>>>
>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior
>>>>>>> of the
>>>>>>> input. The COMPLETE part is important.
>>>>>>>
>>>>>> Not at all, as long as the partial simulation correctly matches any
>>>>>> correct infinite behavior pattern then there is no need to wait until
>>>>>> the end of time to see that an infinite loop never halts.
>>>>>
>>>>> But it doesn't match an infinite behavior pattern as demonstrated
>>>>> by Pa(Pa) halting, or equivalently the correct and COMPLETE
>>>>> simulation by UTM(Pa,Pa).
>>>> That is like checking for black dogs in your living room by looking for
>>>> white cats in your kitchen.
>>>>
>>>> A halt decider must only examine the sequence of instructions that it
>>>> was presented with, not any other sequence.
>>>
>>> Then why do you insist that Ha(Pa,Pa) must report the halt status of
>>> Pn(Pn)?
>>>
>>
>> H(P,P) correctly predicts that its correct and complete simulation of
>> its input would never reach the "ret" instruction of this input.
>
> No, it doesn't.

*When you deny basic facts than I have to stop talking to you*
*When you deny basic facts than I have to stop talking to you*
*When you deny basic facts than I have to stop talking to you*
*When you deny basic facts than I have to stop talking to you*
*When you deny basic facts than I have to stop talking to you*

H(P,P) correctly aborts its simulation when the simulated input matches
correctly this correct generic infinite recursion behavior pattern:

If the execution trace of function Y() shows:
(1) Function X() is called twice in sequence from the same machine
address of Y().
(2) With the same arguments to X().
(3) With no control flow instructions between the invocation of Y() and
its call to X().

Hs(Ps,Ps) is a purely hypothetical halt decider that is exactly the same
as H(P,P) except that it never aborts its simulation, it also matches
the same infinite recursion behavior pattern and reports that is input
does not halt through an output mechanism instead of a return value.
This could be a TM writing 0 to a tape location. This tape location is
initialized to blank, thus as soon as a 1 or a 0 is written to it the
decider has made its decision.

In no possible case does of either H(P,P) or Hs(Ps,Ps) does the
simulated P / Ps ever reach its "ret" instruction final state.

--
Copyright 2022 Pete Olcott

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