On 7/23/2022 6:12 PM, Dennis Bush wrote:
> On Saturday, July 23, 2022 at 7:09:14 PM UTC-4, olcott wrote:
>> On 7/23/2022 5:59 PM, Dennis Bush wrote:
>>> On Saturday, July 23, 2022 at 6:54:24 PM UTC-4, olcott wrote:
>>>> On 7/23/2022 5:29 PM, Dennis Bush wrote:
>>>>> On Saturday, July 23, 2022 at 6:10:50 PM UTC-4, olcott wrote:
>>>>>> On 7/23/2022 4:48 PM, Richard Damon wrote:
>>>>>>> On 7/23/22 5:27 PM, olcott wrote:
>>>>>>>> On 7/23/2022 4:17 PM, Richard Damon wrote:
>>>>>>>>> On 7/23/22 5:11 PM, olcott wrote:
>>>>>>>>>> On 7/23/2022 3:59 PM, Richard Damon wrote:
>>>>>>>>>>> On 7/23/22 4:51 PM, olcott wrote:
>>>>>>>>>>>> On 7/23/2022 3:45 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 7/23/22 4:33 PM, olcott wrote:
>>>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 7/23/22 4:08 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 7/23/2022 2:50 PM, Skep Dick wrote:
>>>>>>>>>>>>>>>>> On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott wrote:
>>>>>>>>>>>>>>>>>> This H correctly determines that its simulated input: (P,P)
>>>>>>>>>>>>>>>>>> would never
>>>>>>>>>>>>>>>>>> stop unless aborted.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Then how come P does the exact opposite of what H "correctly
>>>>>>>>>>>>>>>>> determines"?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Every time!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It has been conclusively proven that the directly executed
>>>>>>>>>>>>>>>> P(P) specifies a different sequence of instructions than the
>>>>>>>>>>>>>>>> correctly simulated input to H(P,P) that H correctly simulates.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Then you are admitting that P is not the "impossible program"
>>>>>>>>>>>>>>> of the proof, so your setup is NOT a counter example.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That you don't believe this proof because you don't understand
>>>>>>>>>>>>>>>> the execution trace that proves this is less than no actual
>>>>>>>>>>>>>>>> rebuttal at all.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86
>>>>>>>>>>>>>>> question for you, what is the first instruction executed in
>>>>>>>>>>>>>>> P(P) that differs from the correct simulation of H(P,P)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>> [000013c6](01) 55 push ebp // Save Base
>>>>>>>>>>>>>> Pointer register onto the stack
>>>>>>>>>>>>>> [000013c7](02) 8bec mov ebp,esp // Load Base
>>>>>>>>>>>>>> Pointer with Stack Pointer
>>>>>>>>>>>>>> [000013c9](01) 51 push ecx // Save the
>>>>>>>>>>>>>> value of ecx on the stack
>>>>>>>>>>>>>> [000013ca](03) 8b4508 mov eax,[ebp+08] // Load eax
>>>>>>>>>>>>>> with argument to P
>>>>>>>>>>>>>> [000013cd](01) 50 push eax // push 2nd
>>>>>>>>>>>>>> argument to H onto the stack
>>>>>>>>>>>>>> [000013ce](03) 8b4d08 mov ecx,[ebp+08] // Load ecx
>>>>>>>>>>>>>> with with argument to P
>>>>>>>>>>>>>> [000013d1](01) 51 push ecx // push 1st
>>>>>>>>>>>>>> argument to H onto the stack
>>>>>>>>>>>>>> [000013d2](05) e82ffdffff call 00001106 // push return
>>>>>>>>>>>>>> address on the stack; call simulated H
>>>>>>>>>>>>>> [000013d7](03) 83c408 add esp,+08 // remove call
>>>>>>>>>>>>>> arguments from stack
>>>>>>>>>>>>>> [000013da](03) 8945fc mov [ebp-04],eax // load
>>>>>>>>>>>>>> Halt_Status with return value from H
>>>>>>>>>>>>>> [000013dd](04) 837dfc00 cmp dword [ebp-04],+00 // compare
>>>>>>>>>>>>>> Halt_Status to 0
>>>>>>>>>>>>>> [000013e1](02) 7402 jz 000013e5 // if
>>>>>>>>>>>>>> Halt_Status == 0 goto 000013e5
>>>>>>>>>>>>>> [000013e3](02) ebfe jmp 000013e3 // goto 13e3
>>>>>>>>>>>>>> [000013e5](02) 8be5 mov esp,ebp // Load Stack
>>>>>>>>>>>>>> Pointer with Base Pointer
>>>>>>>>>>>>>> [000013e7](01) 5d pop ebp // Restore
>>>>>>>>>>>>>> Base Pointer value from stack
>>>>>>>>>>>>>> [000013e8](01) c3 ret // return to
>>>>>>>>>>>>>> caller
>>>>>>>>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The instruction at machine address 13d7
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, where is the difference between P(P) and the correct
>>>>>>>>>>>>> simulation of the input to H(P,P).
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The instruction at machine address 13d7 cannot possibly be reached
>>>>>>>>>>>> by the correctly simulated input to H(P,P) when correctly
>>>>>>>>>>>> simulated by H.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Who said anything about the simulation by H?
>>>>>>>>>>>
>>>>>>>>>> I have kept repeating that thousands of times.
>>>>>>>>>> You just noticed that I was *always* referring to a simulation by H?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Then you aren't working on the Halting Problem.
>>>>>>>>
>>>>>>>> That is currently beside the point, we can address that as a separate
>>>>>>>> point *only after this point has been fully addressed*
>>>>>>>>
>>>>>>>> *The current point is*
>>>>>>>> *The current point is*
>>>>>>>> *The current point is*
>>>>>>>>
>>>>>>>> It has been conclusively proven that the the correctly simulated input
>>>>>>>> to H(P,P) correctly simulated by H cannot possibly reach its "return"
>>>>>>>> instruction.
>>>>>>>>
>>>>>>>
>>>>>>> If you are admitting that H isn't a halt decider, what is the point?
>>>>>>>
>>>>>> I am not admitting that H is not a halt decider.
>>>>>> *The current point is*
>>>>>> *The current point is*
>>>>>> *The current point is*
>>>>>> It has been conclusively proven that the the correctly simulated input
>>>>>> to H(P,P) correctly simulated by H cannot possibly reach its "return"
>>>>>> instruction.
>>>>>
>>>>> What you are actually saying here is:
>>>> For any program H that might determine if programs halt, a
>>>> "pathological" program P, called with some input, can pass its own
>>>> source and its input to H and then specifically do the opposite of what
>>>> H predicts P will do. No H can exist that handles this case.
>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>
>>>> That when any TM or C simulating halt decider H correctly simulates any
>>>> input matching the above defined "pathological" input template P, that P
>>>> presents the infinitely recursive non-halting behavior pattern to H.
>>>
>>> But your Ha is not a halt decider because it doesn't map the halting function.
>> WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD
>> It has been conclusively proven that the correctly simulated
>> input to H(P,P) correctly simulated by H cannot possibly
>> reach its "return" instruction.
>
> Yes, we've established that there is no implementation of the function H that can simulate the function call P(P) to a final state.

On Saturday, July 23, 2022 at 7:18:27 PM UTC-4, olcott wrote:
> On 7/23/2022 6:12 PM, Dennis Bush wrote:
> > On Saturday, July 23, 2022 at 7:09:14 PM UTC-4, olcott wrote:
> >> On 7/23/2022 5:59 PM, Dennis Bush wrote:
> >>> On Saturday, July 23, 2022 at 6:54:24 PM UTC-4, olcott wrote:
> >>>> On 7/23/2022 5:29 PM, Dennis Bush wrote:
> >>>>> On Saturday, July 23, 2022 at 6:10:50 PM UTC-4, olcott wrote:
> >>>>>> On 7/23/2022 4:48 PM, Richard Damon wrote:
> >>>>>>> On 7/23/22 5:27 PM, olcott wrote:
> >>>>>>>> On 7/23/2022 4:17 PM, Richard Damon wrote:
> >>>>>>>>> On 7/23/22 5:11 PM, olcott wrote:
> >>>>>>>>>> On 7/23/2022 3:59 PM, Richard Damon wrote:
> >>>>>>>>>>> On 7/23/22 4:51 PM, olcott wrote:
> >>>>>>>>>>>> On 7/23/2022 3:45 PM, Richard Damon wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 7/23/22 4:33 PM, olcott wrote:
> >>>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 7/23/22 4:08 PM, olcott wrote:
> >>>>>>>>>>>>>>>> On 7/23/2022 2:50 PM, Skep Dick wrote:
> >>>>>>>>>>>>>>>>> On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott wrote:
> >>>>>>>>>>>>>>>>>> This H correctly determines that its simulated input: (P,P)
> >>>>>>>>>>>>>>>>>> would never
> >>>>>>>>>>>>>>>>>> stop unless aborted.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Then how come P does the exact opposite of what H "correctly
> >>>>>>>>>>>>>>>>> determines"?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Every time!
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It has been conclusively proven that the directly executed
> >>>>>>>>>>>>>>>> P(P) specifies a different sequence of instructions than the
> >>>>>>>>>>>>>>>> correctly simulated input to H(P,P) that H correctly simulates.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Then you are admitting that P is not the "impossible program"
> >>>>>>>>>>>>>>> of the proof, so your setup is NOT a counter example.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> That you don't believe this proof because you don't understand
> >>>>>>>>>>>>>>>> the execution trace that proves this is less than no actual
> >>>>>>>>>>>>>>>> rebuttal at all.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86
> >>>>>>>>>>>>>>> question for you, what is the first instruction executed in
> >>>>>>>>>>>>>>> P(P) that differs from the correct simulation of H(P,P)?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>> [000013c6](01) 55 push ebp // Save Base
> >>>>>>>>>>>>>> Pointer register onto the stack
> >>>>>>>>>>>>>> [000013c7](02) 8bec mov ebp,esp // Load Base
> >>>>>>>>>>>>>> Pointer with Stack Pointer
> >>>>>>>>>>>>>> [000013c9](01) 51 push ecx // Save the
> >>>>>>>>>>>>>> value of ecx on the stack
> >>>>>>>>>>>>>> [000013ca](03) 8b4508 mov eax,[ebp+08] // Load eax
> >>>>>>>>>>>>>> with argument to P
> >>>>>>>>>>>>>> [000013cd](01) 50 push eax // push 2nd
> >>>>>>>>>>>>>> argument to H onto the stack
> >>>>>>>>>>>>>> [000013ce](03) 8b4d08 mov ecx,[ebp+08] // Load ecx
> >>>>>>>>>>>>>> with with argument to P
> >>>>>>>>>>>>>> [000013d1](01) 51 push ecx // push 1st
> >>>>>>>>>>>>>> argument to H onto the stack
> >>>>>>>>>>>>>> [000013d2](05) e82ffdffff call 00001106 // push return
> >>>>>>>>>>>>>> address on the stack; call simulated H
> >>>>>>>>>>>>>> [000013d7](03) 83c408 add esp,+08 // remove call
> >>>>>>>>>>>>>> arguments from stack
> >>>>>>>>>>>>>> [000013da](03) 8945fc mov [ebp-04],eax // load
> >>>>>>>>>>>>>> Halt_Status with return value from H
> >>>>>>>>>>>>>> [000013dd](04) 837dfc00 cmp dword [ebp-04],+00 // compare
> >>>>>>>>>>>>>> Halt_Status to 0
> >>>>>>>>>>>>>> [000013e1](02) 7402 jz 000013e5 // if
> >>>>>>>>>>>>>> Halt_Status == 0 goto 000013e5
> >>>>>>>>>>>>>> [000013e3](02) ebfe jmp 000013e3 // goto 13e3
> >>>>>>>>>>>>>> [000013e5](02) 8be5 mov esp,ebp // Load Stack
> >>>>>>>>>>>>>> Pointer with Base Pointer
> >>>>>>>>>>>>>> [000013e7](01) 5d pop ebp // Restore
> >>>>>>>>>>>>>> Base Pointer value from stack
> >>>>>>>>>>>>>> [000013e8](01) c3 ret // return to
> >>>>>>>>>>>>>> caller
> >>>>>>>>>>>>>> Size in bytes:(0035) [000013e8]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The instruction at machine address 13d7
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So, where is the difference between P(P) and the correct
> >>>>>>>>>>>>> simulation of the input to H(P,P).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> The instruction at machine address 13d7 cannot possibly be reached
> >>>>>>>>>>>> by the correctly simulated input to H(P,P) when correctly
> >>>>>>>>>>>> simulated by H.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Who said anything about the simulation by H?
> >>>>>>>>>>>
> >>>>>>>>>> I have kept repeating that thousands of times.
> >>>>>>>>>> You just noticed that I was *always* referring to a simulation by H?
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Then you aren't working on the Halting Problem.
> >>>>>>>>
> >>>>>>>> That is currently beside the point, we can address that as a separate
> >>>>>>>> point *only after this point has been fully addressed*
> >>>>>>>>
> >>>>>>>> *The current point is*
> >>>>>>>> *The current point is*
> >>>>>>>> *The current point is*
> >>>>>>>>
> >>>>>>>> It has been conclusively proven that the the correctly simulated input
> >>>>>>>> to H(P,P) correctly simulated by H cannot possibly reach its "return"
> >>>>>>>> instruction.
> >>>>>>>>
> >>>>>>>
> >>>>>>> If you are admitting that H isn't a halt decider, what is the point?
> >>>>>>>
> >>>>>> I am not admitting that H is not a halt decider.
> >>>>>> *The current point is*
> >>>>>> *The current point is*
> >>>>>> *The current point is*
> >>>>>> It has been conclusively proven that the the correctly simulated input
> >>>>>> to H(P,P) correctly simulated by H cannot possibly reach its "return"
> >>>>>> instruction.
> >>>>>
> >>>>> What you are actually saying here is:
> >>>> For any program H that might determine if programs halt, a
> >>>> "pathological" program P, called with some input, can pass its own
> >>>> source and its input to H and then specifically do the opposite of what
> >>>> H predicts P will do. No H can exist that handles this case.
> >>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>
> >>>> That when any TM or C simulating halt decider H correctly simulates any
> >>>> input matching the above defined "pathological" input template P, that P
> >>>> presents the infinitely recursive non-halting behavior pattern to H.
> >>>
> >>> But your Ha is not a halt decider because it doesn't map the halting function.
> >> WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD
> >> It has been conclusively proven that the correctly simulated
> >> input to H(P,P) correctly simulated by H cannot possibly
> >> reach its "return" instruction.
> >
> > Yes, we've established that there is no implementation of the function H that can simulate the function call P(P) to a final state.
> This is the correct way of saying that:
> For any program H that might determine if programs halt, a
> "pathological" program P, called with some input, can pass its own
> source and its input to H and then specifically do the opposite of what
> H predicts P will do. No H can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
> That when any TM or C simulating halt decider H correctly simulates any
> input matching the above defined "pathological" input template P, that P
> presents the infinitely recursive non-halting behavior pattern to H.
> Furthermore H can correctly use this pattern match as its basis to abort
> its simulation and correctly reject this input as non-halting.

On Sat, 23 Jul 2022 18:18:19 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/23/2022 6:12 PM, Dennis Bush wrote:
> > On Saturday, July 23, 2022 at 7:09:14 PM UTC-4, olcott wrote:
> >> On 7/23/2022 5:59 PM, Dennis Bush wrote:
> >>> On Saturday, July 23, 2022 at 6:54:24 PM UTC-4, olcott wrote:
> >>>> On 7/23/2022 5:29 PM, Dennis Bush wrote:
> >>>>> On Saturday, July 23, 2022 at 6:10:50 PM UTC-4, olcott wrote:
> >>>>>> On 7/23/2022 4:48 PM, Richard Damon wrote:
> >>>>>>> On 7/23/22 5:27 PM, olcott wrote:
> >>>>>>>> On 7/23/2022 4:17 PM, Richard Damon wrote:
> >>>>>>>>> On 7/23/22 5:11 PM, olcott wrote:
> >>>>>>>>>> On 7/23/2022 3:59 PM, Richard Damon wrote:
> >>>>>>>>>>> On 7/23/22 4:51 PM, olcott wrote:
> >>>>>>>>>>>> On 7/23/2022 3:45 PM, Richard Damon wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 7/23/22 4:33 PM, olcott wrote:
> >>>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 7/23/22 4:08 PM, olcott wrote:
> >>>>>>>>>>>>>>>> On 7/23/2022 2:50 PM, Skep Dick wrote:
> >>>>>>>>>>>>>>>>> On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>> This H correctly determines that its simulated
> >>>>>>>>>>>>>>>>>> input: (P,P) would never
> >>>>>>>>>>>>>>>>>> stop unless aborted.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Then how come P does the exact opposite of what H
> >>>>>>>>>>>>>>>>> "correctly determines"?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Every time!
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It has been conclusively proven that the directly
> >>>>>>>>>>>>>>>> executed P(P) specifies a different sequence of
> >>>>>>>>>>>>>>>> instructions than the correctly simulated input to
> >>>>>>>>>>>>>>>> H(P,P) that H correctly simulates.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Then you are admitting that P is not the "impossible
> >>>>>>>>>>>>>>> program" of the proof, so your setup is NOT a counter
> >>>>>>>>>>>>>>> example.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> That you don't believe this proof because you don't
> >>>>>>>>>>>>>>>> understand the execution trace that proves this is
> >>>>>>>>>>>>>>>> less than no actual rebuttal at all.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of
> >>>>>>>>>>>>>>> the x86 question for you, what is the first
> >>>>>>>>>>>>>>> instruction executed in P(P) that differs from the
> >>>>>>>>>>>>>>> correct simulation of H(P,P)?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>> [000013c6](01) 55 push ebp // Save Base
> >>>>>>>>>>>>>> Pointer register onto the stack
> >>>>>>>>>>>>>> [000013c7](02) 8bec mov ebp,esp // Load Base
> >>>>>>>>>>>>>> Pointer with Stack Pointer
> >>>>>>>>>>>>>> [000013c9](01) 51 push ecx // Save the
> >>>>>>>>>>>>>> value of ecx on the stack
> >>>>>>>>>>>>>> [000013ca](03) 8b4508 mov eax,[ebp+08] // Load eax
> >>>>>>>>>>>>>> with argument to P
> >>>>>>>>>>>>>> [000013cd](01) 50 push eax // push 2nd
> >>>>>>>>>>>>>> argument to H onto the stack
> >>>>>>>>>>>>>> [000013ce](03) 8b4d08 mov ecx,[ebp+08] // Load ecx
> >>>>>>>>>>>>>> with with argument to P
> >>>>>>>>>>>>>> [000013d1](01) 51 push ecx // push 1st
> >>>>>>>>>>>>>> argument to H onto the stack
> >>>>>>>>>>>>>> [000013d2](05) e82ffdffff call 00001106 // push return
> >>>>>>>>>>>>>> address on the stack; call simulated H
> >>>>>>>>>>>>>> [000013d7](03) 83c408 add esp,+08 // remove call
> >>>>>>>>>>>>>> arguments from stack
> >>>>>>>>>>>>>> [000013da](03) 8945fc mov [ebp-04],eax // load
> >>>>>>>>>>>>>> Halt_Status with return value from H
> >>>>>>>>>>>>>> [000013dd](04) 837dfc00 cmp dword [ebp-04],+00 //
> >>>>>>>>>>>>>> compare Halt_Status to 0
> >>>>>>>>>>>>>> [000013e1](02) 7402 jz 000013e5 // if
> >>>>>>>>>>>>>> Halt_Status == 0 goto 000013e5
> >>>>>>>>>>>>>> [000013e3](02) ebfe jmp 000013e3 // goto 13e3
> >>>>>>>>>>>>>> [000013e5](02) 8be5 mov esp,ebp // Load Stack
> >>>>>>>>>>>>>> Pointer with Base Pointer
> >>>>>>>>>>>>>> [000013e7](01) 5d pop ebp // Restore
> >>>>>>>>>>>>>> Base Pointer value from stack
> >>>>>>>>>>>>>> [000013e8](01) c3 ret // return to
> >>>>>>>>>>>>>> caller
> >>>>>>>>>>>>>> Size in bytes:(0035) [000013e8]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The instruction at machine address 13d7
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So, where is the difference between P(P) and the correct
> >>>>>>>>>>>>> simulation of the input to H(P,P).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> The instruction at machine address 13d7 cannot possibly
> >>>>>>>>>>>> be reached by the correctly simulated input to H(P,P)
> >>>>>>>>>>>> when correctly simulated by H.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Who said anything about the simulation by H?
> >>>>>>>>>>>
> >>>>>>>>>> I have kept repeating that thousands of times.
> >>>>>>>>>> You just noticed that I was *always* referring to a
> >>>>>>>>>> simulation by H?
> >>>>>>>>>
> >>>>>>>>> Then you aren't working on the Halting Problem.
> >>>>>>>>
> >>>>>>>> That is currently beside the point, we can address that as a
> >>>>>>>> separate point *only after this point has been fully
> >>>>>>>> addressed*
> >>>>>>>>
> >>>>>>>> *The current point is*
> >>>>>>>> *The current point is*
> >>>>>>>> *The current point is*
> >>>>>>>>
> >>>>>>>> It has been conclusively proven that the the correctly
> >>>>>>>> simulated input to H(P,P) correctly simulated by H cannot
> >>>>>>>> possibly reach its "return" instruction.
> >>>>>>>>
> >>>>>>>
> >>>>>>> If you are admitting that H isn't a halt decider, what is the
> >>>>>>> point?
> >>>>>> I am not admitting that H is not a halt decider.
> >>>>>> *The current point is*
> >>>>>> *The current point is*
> >>>>>> *The current point is*
> >>>>>> It has been conclusively proven that the the correctly
> >>>>>> simulated input to H(P,P) correctly simulated by H cannot
> >>>>>> possibly reach its "return" instruction.
> >>>>>
> >>>>> What you are actually saying here is:
> >>>> For any program H that might determine if programs halt, a
> >>>> "pathological" program P, called with some input, can pass its
> >>>> own source and its input to H and then specifically do the
> >>>> opposite of what H predicts P will do. No H can exist that
> >>>> handles this case. https://en.wikipedia.org/wiki/Halting_problem
> >>>>
> >>>> That when any TM or C simulating halt decider H correctly
> >>>> simulates any input matching the above defined "pathological"
> >>>> input template P, that P presents the infinitely recursive
> >>>> non-halting behavior pattern to H.
> >>>
> >>> But your Ha is not a halt decider because it doesn't map the
> >>> halting function.
> >> WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD
> >> It has been conclusively proven that the correctly simulated
> >> input to H(P,P) correctly simulated by H cannot possibly
> >> reach its "return" instruction.
> >
> > Yes, we've established that there is no implementation of the
> > function H that can simulate the function call P(P) to a final
> > state.
>
> This is the correct way of saying that:
>
> For any program H that might determine if programs halt, a
> "pathological" program P, called with some input, can pass its own
> source and its input to H and then specifically do the opposite of
> what H predicts P will do. No H can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
> That when any TM or C simulating halt decider H correctly simulates
> any input matching the above defined "pathological" input template P,
> that P presents the infinitely recursive non-halting behavior pattern
> to H.

On 7/23/22 6:54 PM, olcott wrote:
> On 7/23/2022 5:29 PM, Dennis Bush wrote:
>> On Saturday, July 23, 2022 at 6:10:50 PM UTC-4, olcott wrote:
>>> On 7/23/2022 4:48 PM, Richard Damon wrote:
>>>> On 7/23/22 5:27 PM, olcott wrote:
>>>>> On 7/23/2022 4:17 PM, Richard Damon wrote:
>>>>>> On 7/23/22 5:11 PM, olcott wrote:
>>>>>>> On 7/23/2022 3:59 PM, Richard Damon wrote:
>>>>>>>> On 7/23/22 4:51 PM, olcott wrote:
>>>>>>>>> On 7/23/2022 3:45 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 7/23/22 4:33 PM, olcott wrote:
>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 7/23/22 4:08 PM, olcott wrote:
>>>>>>>>>>>>> On 7/23/2022 2:50 PM, Skep Dick wrote:
>>>>>>>>>>>>>> On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott wrote:
>>>>>>>>>>>>>>> This H correctly determines that its simulated input: (P,P)
>>>>>>>>>>>>>>> would never
>>>>>>>>>>>>>>> stop unless aborted.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Then how come P does the exact opposite of what H "correctly
>>>>>>>>>>>>>> determines"?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Every time!
>>>>>>>>>>>>>
>>>>>>>>>>>>> It has been conclusively proven that the directly executed
>>>>>>>>>>>>> P(P) specifies a different sequence of instructions than the
>>>>>>>>>>>>> correctly simulated input to H(P,P) that H correctly
>>>>>>>>>>>>> simulates.
>>>>>>>>>>>>
>>>>>>>>>>>> Then you are admitting that P is not the "impossible program"
>>>>>>>>>>>> of the proof, so your setup is NOT a counter example.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That you don't believe this proof because you don't understand
>>>>>>>>>>>>> the execution trace that proves this is less than no actual
>>>>>>>>>>>>> rebuttal at all.
>>>>>>>>>>>>
>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86
>>>>>>>>>>>> question for you, what is the first instruction executed in
>>>>>>>>>>>> P(P) that differs from the correct simulation of H(P,P)?
>>>>>>>>>>>
>>>>>>>>>>> _P()
>>>>>>>>>>> [000013c6](01)  55         push ebp               // Save Base
>>>>>>>>>>> Pointer register onto the stack
>>>>>>>>>>> [000013c7](02)  8bec       mov ebp,esp            // Load Base
>>>>>>>>>>> Pointer with Stack Pointer
>>>>>>>>>>> [000013c9](01)  51         push ecx               // Save the
>>>>>>>>>>> value of ecx on the stack
>>>>>>>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]       // Load eax
>>>>>>>>>>> with argument to P
>>>>>>>>>>> [000013cd](01)  50         push eax               // push 2nd
>>>>>>>>>>> argument to H onto the stack
>>>>>>>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]       // Load ecx
>>>>>>>>>>> with with argument to P
>>>>>>>>>>> [000013d1](01)  51         push ecx               // push 1st
>>>>>>>>>>> argument to H onto the stack
>>>>>>>>>>> [000013d2](05)  e82ffdffff call 00001106          // push return
>>>>>>>>>>> address on the stack; call simulated H
>>>>>>>>>>> [000013d7](03)  83c408     add esp,+08            // remove call
>>>>>>>>>>> arguments from stack
>>>>>>>>>>> [000013da](03)  8945fc     mov [ebp-04],eax       // load
>>>>>>>>>>> Halt_Status with return value from H
>>>>>>>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00 // compare
>>>>>>>>>>> Halt_Status to 0
>>>>>>>>>>> [000013e1](02)  7402       jz 000013e5            // if
>>>>>>>>>>> Halt_Status == 0 goto 000013e5
>>>>>>>>>>> [000013e3](02)  ebfe       jmp 000013e3           // goto 13e3
>>>>>>>>>>> [000013e5](02)  8be5       mov esp,ebp            // Load Stack
>>>>>>>>>>> Pointer with Base Pointer
>>>>>>>>>>> [000013e7](01)  5d         pop ebp                // Restore
>>>>>>>>>>> Base Pointer value from stack
>>>>>>>>>>> [000013e8](01)  c3         ret                    // return to
>>>>>>>>>>> caller
>>>>>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>>>>>
>>>>>>>>>>> The instruction at machine address 13d7
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, where is the difference between P(P) and the correct
>>>>>>>>>> simulation of the input to H(P,P).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The instruction at machine address 13d7 cannot possibly be reached
>>>>>>>>> by the correctly simulated input to H(P,P) when correctly
>>>>>>>>> simulated by H.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Who said anything about the simulation by H?
>>>>>>>>
>>>>>>> I have kept repeating that thousands of times.
>>>>>>> You just noticed that I was *always* referring to a simulation by H?
>>>>>>>
>>>>>>
>>>>>> Then you aren't working on the Halting Problem.
>>>>>
>>>>> That is currently beside the point, we can address that as a separate
>>>>> point *only after this point has been fully addressed*
>>>>>
>>>>> *The current point is*
>>>>> *The current point is*
>>>>> *The current point is*
>>>>>
>>>>> It has been conclusively proven that the the correctly simulated input
>>>>> to H(P,P) correctly simulated by H cannot possibly reach its "return"
>>>>> instruction.
>>>>>
>>>>
>>>> If you are admitting that H isn't a halt decider, what is the point?
>>>>
>>> I am not admitting that H is not a halt decider.
>>> *The current point is*
>>> *The current point is*
>>> *The current point is*
>>> It has been conclusively proven that the the correctly simulated input
>>> to H(P,P) correctly simulated by H cannot possibly reach its "return"
>>> instruction.
>>
>> What you are actually saying here is:
>
> For any program H that might determine if programs halt, a
> "pathological" program P, called with some input, can pass its own
> source and its input to H and then specifically do the opposite of what
> H predicts P will do. No H can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
> That when any TM or C simulating halt decider H correctly simulates any
> input matching the above defined "pathological" input template P, that P
> presents the infinitely recursive non-halting behavior pattern to H.
>
> Furthermore H can correctly use this pattern match as its basis to abort
> its simulation and correctly reject this input as non-halting.
>
>

On 7/23/22 6:57 PM, olcott wrote:
> On 7/23/2022 5:22 PM, Richard Damon wrote:
>> On 7/23/22 6:10 PM, olcott wrote:
>>> On 7/23/2022 4:48 PM, Richard Damon wrote:
>>>> On 7/23/22 5:27 PM, olcott wrote:
>>>>> On 7/23/2022 4:17 PM, Richard Damon wrote:
>>>>>> On 7/23/22 5:11 PM, olcott wrote:
>>>>>>> On 7/23/2022 3:59 PM, Richard Damon wrote:
>>>>>>>> On 7/23/22 4:51 PM, olcott wrote:
>>>>>>>>> On 7/23/2022 3:45 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 7/23/22 4:33 PM, olcott wrote:
>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 7/23/22 4:08 PM, olcott wrote:
>>>>>>>>>>>>> On 7/23/2022 2:50 PM, Skep Dick wrote:
>>>>>>>>>>>>>> On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott wrote:
>>>>>>>>>>>>>>> This H correctly determines that its simulated input:
>>>>>>>>>>>>>>> (P,P) would never
>>>>>>>>>>>>>>> stop unless aborted.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Then how come P does the exact opposite of what H
>>>>>>>>>>>>>> "correctly determines"?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Every time!
>>>>>>>>>>>>>
>>>>>>>>>>>>> It has been conclusively proven that the directly executed
>>>>>>>>>>>>> P(P) specifies a different sequence of instructions than
>>>>>>>>>>>>> the correctly simulated input to H(P,P) that H correctly
>>>>>>>>>>>>> simulates.
>>>>>>>>>>>>
>>>>>>>>>>>> Then you are admitting that P is not the "impossible
>>>>>>>>>>>> program" of the proof, so your setup is NOT a counter example.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That you don't believe this proof because you don't
>>>>>>>>>>>>> understand the execution trace that proves this is less
>>>>>>>>>>>>> than no actual rebuttal at all.
>>>>>>>>>>>>
>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86
>>>>>>>>>>>> question for you, what is the first instruction executed in
>>>>>>>>>>>> P(P) that differs from the correct simulation of H(P,P)?
>>>>>>>>>>>
>>>>>>>>>>> _P()
>>>>>>>>>>> [000013c6](01)  55         push ebp               // Save
>>>>>>>>>>> Base Pointer register onto the stack
>>>>>>>>>>> [000013c7](02)  8bec       mov ebp,esp            // Load
>>>>>>>>>>> Base Pointer with Stack Pointer
>>>>>>>>>>> [000013c9](01)  51         push ecx               // Save the
>>>>>>>>>>> value of ecx on the stack
>>>>>>>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]       // Load eax
>>>>>>>>>>> with argument to P
>>>>>>>>>>> [000013cd](01)  50         push eax               // push 2nd
>>>>>>>>>>> argument to H onto the stack
>>>>>>>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]       // Load ecx
>>>>>>>>>>> with with argument to P
>>>>>>>>>>> [000013d1](01)  51         push ecx               // push 1st
>>>>>>>>>>> argument to H onto the stack
>>>>>>>>>>> [000013d2](05)  e82ffdffff call 00001106          // push
>>>>>>>>>>> return address on the stack; call simulated H
>>>>>>>>>>> [000013d7](03)  83c408     add esp,+08            // remove
>>>>>>>>>>> call arguments from stack
>>>>>>>>>>> [000013da](03)  8945fc     mov [ebp-04],eax       // load
>>>>>>>>>>> Halt_Status with return value from H
>>>>>>>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00 // compare
>>>>>>>>>>> Halt_Status to 0
>>>>>>>>>>> [000013e1](02)  7402       jz 000013e5            // if
>>>>>>>>>>> Halt_Status == 0 goto 000013e5
>>>>>>>>>>> [000013e3](02)  ebfe       jmp 000013e3           // goto 13e3
>>>>>>>>>>> [000013e5](02)  8be5       mov esp,ebp            // Load
>>>>>>>>>>> Stack Pointer with Base Pointer
>>>>>>>>>>> [000013e7](01)  5d         pop ebp                // Restore
>>>>>>>>>>> Base Pointer value from stack
>>>>>>>>>>> [000013e8](01)  c3         ret                    // return
>>>>>>>>>>> to caller
>>>>>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>>>>>
>>>>>>>>>>> The instruction at machine address 13d7
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, where is the difference between P(P) and the correct
>>>>>>>>>> simulation of the input to H(P,P).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The instruction at machine address 13d7 cannot possibly be
>>>>>>>>> reached by the correctly simulated input to H(P,P) when
>>>>>>>>> correctly simulated by H.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Who said anything about the simulation by H?
>>>>>>>>
>>>>>>> I have kept repeating that thousands of times.
>>>>>>> You just noticed that I was *always* referring to a simulation by H?
>>>>>>>
>>>>>>
>>>>>> Then you aren't working on the Halting Problem.
>>>>>
>>>>> That is currently beside the point, we can address that as a
>>>>> separate point *only after this point has been fully addressed*
>>>>>
>>>>> *The current point is*
>>>>> *The current point is*
>>>>> *The current point is*
>>>>>
>>>>> It has been conclusively proven that the the correctly simulated
>>>>> input to H(P,P) correctly simulated by H cannot possibly reach its
>>>>> "return" instruction.
>>>>>
>>>>
>>>> If you are admitting that H isn't a halt decider, what is the point?
>>>>
>>>
>>> I am not admitting that H is not a halt decider.
>>>
>>> *The current point is*
>>> *The current point is*
>>> *The current point is*
>>> It has been conclusively proven that the the correctly simulated input
>>> to H(P,P) correctly simulated by H cannot possibly reach its "return"
>>> instruction.
>>>
>>> I will not diverge from this specific point until it has been fully
>>> understood.
>>>
>>>
>>
>> Why should I spend any time on something that isn't actually a Halt
>> Decider.
>>
>
> It is a halt decider. Why should I spend any time with someone that
> changes the subject as their rebuttal?
>
> WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD
> It has been conclusively proven that the correctly simulated
> input to H(P,P) correctly simulated by H cannot possibly
> reach its "return" instruction.
>

On 7/23/22 7:18 PM, olcott wrote:
> On 7/23/2022 6:12 PM, Dennis Bush wrote:
>> On Saturday, July 23, 2022 at 7:09:14 PM UTC-4, olcott wrote:
>>> On 7/23/2022 5:59 PM, Dennis Bush wrote:
>>>> On Saturday, July 23, 2022 at 6:54:24 PM UTC-4, olcott wrote:
>>>>> On 7/23/2022 5:29 PM, Dennis Bush wrote:
>>>>>> On Saturday, July 23, 2022 at 6:10:50 PM UTC-4, olcott wrote:
>>>>>>> On 7/23/2022 4:48 PM, Richard Damon wrote:
>>>>>>>> On 7/23/22 5:27 PM, olcott wrote:
>>>>>>>>> On 7/23/2022 4:17 PM, Richard Damon wrote:
>>>>>>>>>> On 7/23/22 5:11 PM, olcott wrote:
>>>>>>>>>>> On 7/23/2022 3:59 PM, Richard Damon wrote:
>>>>>>>>>>>> On 7/23/22 4:51 PM, olcott wrote:
>>>>>>>>>>>>> On 7/23/2022 3:45 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7/23/22 4:33 PM, olcott wrote:
>>>>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 7/23/22 4:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 7/23/2022 2:50 PM, Skep Dick wrote:
>>>>>>>>>>>>>>>>>> On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> This H correctly determines that its simulated input:
>>>>>>>>>>>>>>>>>>> (P,P)
>>>>>>>>>>>>>>>>>>> would never
>>>>>>>>>>>>>>>>>>> stop unless aborted.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Then how come P does the exact opposite of what H
>>>>>>>>>>>>>>>>>> "correctly
>>>>>>>>>>>>>>>>>> determines"?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Every time!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It has been conclusively proven that the directly executed
>>>>>>>>>>>>>>>>> P(P) specifies a different sequence of instructions
>>>>>>>>>>>>>>>>> than the
>>>>>>>>>>>>>>>>> correctly simulated input to H(P,P) that H correctly
>>>>>>>>>>>>>>>>> simulates.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Then you are admitting that P is not the "impossible
>>>>>>>>>>>>>>>> program"
>>>>>>>>>>>>>>>> of the proof, so your setup is NOT a counter example.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That you don't believe this proof because you don't
>>>>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>>> the execution trace that proves this is less than no
>>>>>>>>>>>>>>>>> actual
>>>>>>>>>>>>>>>>> rebuttal at all.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86
>>>>>>>>>>>>>>>> question for you, what is the first instruction executed in
>>>>>>>>>>>>>>>> P(P) that differs from the correct simulation of H(P,P)?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>> [000013c6](01) 55 push ebp // Save Base
>>>>>>>>>>>>>>> Pointer register onto the stack
>>>>>>>>>>>>>>> [000013c7](02) 8bec mov ebp,esp // Load Base
>>>>>>>>>>>>>>> Pointer with Stack Pointer
>>>>>>>>>>>>>>> [000013c9](01) 51 push ecx // Save the
>>>>>>>>>>>>>>> value of ecx on the stack
>>>>>>>>>>>>>>> [000013ca](03) 8b4508 mov eax,[ebp+08] // Load eax
>>>>>>>>>>>>>>> with argument to P
>>>>>>>>>>>>>>> [000013cd](01) 50 push eax // push 2nd
>>>>>>>>>>>>>>> argument to H onto the stack
>>>>>>>>>>>>>>> [000013ce](03) 8b4d08 mov ecx,[ebp+08] // Load ecx
>>>>>>>>>>>>>>> with with argument to P
>>>>>>>>>>>>>>> [000013d1](01) 51 push ecx // push 1st
>>>>>>>>>>>>>>> argument to H onto the stack
>>>>>>>>>>>>>>> [000013d2](05) e82ffdffff call 00001106 // push return
>>>>>>>>>>>>>>> address on the stack; call simulated H
>>>>>>>>>>>>>>> [000013d7](03) 83c408 add esp,+08 // remove call
>>>>>>>>>>>>>>> arguments from stack
>>>>>>>>>>>>>>> [000013da](03) 8945fc mov [ebp-04],eax // load
>>>>>>>>>>>>>>> Halt_Status with return value from H
>>>>>>>>>>>>>>> [000013dd](04) 837dfc00 cmp dword [ebp-04],+00 // compare
>>>>>>>>>>>>>>> Halt_Status to 0
>>>>>>>>>>>>>>> [000013e1](02) 7402 jz 000013e5 // if
>>>>>>>>>>>>>>> Halt_Status == 0 goto 000013e5
>>>>>>>>>>>>>>> [000013e3](02) ebfe jmp 000013e3 // goto 13e3
>>>>>>>>>>>>>>> [000013e5](02) 8be5 mov esp,ebp // Load Stack
>>>>>>>>>>>>>>> Pointer with Base Pointer
>>>>>>>>>>>>>>> [000013e7](01) 5d pop ebp // Restore
>>>>>>>>>>>>>>> Base Pointer value from stack
>>>>>>>>>>>>>>> [000013e8](01) c3 ret // return to
>>>>>>>>>>>>>>> caller
>>>>>>>>>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The instruction at machine address 13d7
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, where is the difference between P(P) and the correct
>>>>>>>>>>>>>> simulation of the input to H(P,P).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The instruction at machine address 13d7 cannot possibly be
>>>>>>>>>>>>> reached
>>>>>>>>>>>>> by the correctly simulated input to H(P,P) when correctly
>>>>>>>>>>>>> simulated by H.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Who said anything about the simulation by H?
>>>>>>>>>>>>
>>>>>>>>>>> I have kept repeating that thousands of times.
>>>>>>>>>>> You just noticed that I was *always* referring to a
>>>>>>>>>>> simulation by H?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Then you aren't working on the Halting Problem.
>>>>>>>>>
>>>>>>>>> That is currently beside the point, we can address that as a
>>>>>>>>> separate
>>>>>>>>> point *only after this point has been fully addressed*
>>>>>>>>>
>>>>>>>>> *The current point is*
>>>>>>>>> *The current point is*
>>>>>>>>> *The current point is*
>>>>>>>>>
>>>>>>>>> It has been conclusively proven that the the correctly
>>>>>>>>> simulated input
>>>>>>>>> to H(P,P) correctly simulated by H cannot possibly reach its
>>>>>>>>> "return"
>>>>>>>>> instruction.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If you are admitting that H isn't a halt decider, what is the
>>>>>>>> point?
>>>>>>>>
>>>>>>> I am not admitting that H is not a halt decider.
>>>>>>> *The current point is*
>>>>>>> *The current point is*
>>>>>>> *The current point is*
>>>>>>> It has been conclusively proven that the the correctly simulated
>>>>>>> input
>>>>>>> to H(P,P) correctly simulated by H cannot possibly reach its
>>>>>>> "return"
>>>>>>> instruction.
>>>>>>
>>>>>> What you are actually saying here is:
>>>>> For any program H that might determine if programs halt, a
>>>>> "pathological" program P, called with some input, can pass its own
>>>>> source and its input to H and then specifically do the opposite of
>>>>> what
>>>>> H predicts P will do. No H can exist that handles this case.
>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>
>>>>> That when any TM or C simulating halt decider H correctly simulates
>>>>> any
>>>>> input matching the above defined "pathological" input template P,
>>>>> that P
>>>>> presents the infinitely recursive non-halting behavior pattern to H.
>>>>
>>>> But your Ha is not a halt decider because it doesn't map the halting
>>>> function.
>>> WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD
>>> It has been conclusively proven that the correctly simulated
>>> input to H(P,P) correctly simulated by H cannot possibly
>>> reach its "return" instruction.
>>
>> Yes, we've established that there is no implementation of the function
>> H that can simulate the function call P(P) to a final state.
>
> This is the correct way of saying that:
>
> For any program H that might determine if programs halt, a
> "pathological" program P, called with some input, can pass its own
> source and its input to H and then specifically do the opposite of what
> H predicts P will do. No H can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
> That when any TM or C simulating halt decider H correctly simulates any
> input matching the above defined "pathological" input template P, that P
> presents the infinitely recursive non-halting behavior pattern to H.
>
> Furthermore H can correctly use this pattern match as its basis to abort
> its simulation and correctly reject this input as non-halting.
>

On 7/23/2022 6:37 PM, Richard Damon wrote:
> On 7/23/22 6:57 PM, olcott wrote:
>> On 7/23/2022 5:22 PM, Richard Damon wrote:
>>> On 7/23/22 6:10 PM, olcott wrote:
>>>> On 7/23/2022 4:48 PM, Richard Damon wrote:
>>>>> On 7/23/22 5:27 PM, olcott wrote:
>>>>>> On 7/23/2022 4:17 PM, Richard Damon wrote:
>>>>>>> On 7/23/22 5:11 PM, olcott wrote:
>>>>>>>> On 7/23/2022 3:59 PM, Richard Damon wrote:
>>>>>>>>> On 7/23/22 4:51 PM, olcott wrote:
>>>>>>>>>> On 7/23/2022 3:45 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 7/23/22 4:33 PM, olcott wrote:
>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 7/23/22 4:08 PM, olcott wrote:
>>>>>>>>>>>>>> On 7/23/2022 2:50 PM, Skep Dick wrote:
>>>>>>>>>>>>>>> On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott wrote:
>>>>>>>>>>>>>>>> This H correctly determines that its simulated input:
>>>>>>>>>>>>>>>> (P,P) would never
>>>>>>>>>>>>>>>> stop unless aborted.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Then how come P does the exact opposite of what H
>>>>>>>>>>>>>>> "correctly determines"?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Every time!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It has been conclusively proven that the directly executed
>>>>>>>>>>>>>> P(P) specifies a different sequence of instructions than
>>>>>>>>>>>>>> the correctly simulated input to H(P,P) that H correctly
>>>>>>>>>>>>>> simulates.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then you are admitting that P is not the "impossible
>>>>>>>>>>>>> program" of the proof, so your setup is NOT a counter example.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That you don't believe this proof because you don't
>>>>>>>>>>>>>> understand the execution trace that proves this is less
>>>>>>>>>>>>>> than no actual rebuttal at all.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86
>>>>>>>>>>>>> question for you, what is the first instruction executed in
>>>>>>>>>>>>> P(P) that differs from the correct simulation of H(P,P)?
>>>>>>>>>>>>
>>>>>>>>>>>> _P()
>>>>>>>>>>>> [000013c6](01)  55         push ebp               // Save
>>>>>>>>>>>> Base Pointer register onto the stack
>>>>>>>>>>>> [000013c7](02)  8bec       mov ebp,esp            // Load
>>>>>>>>>>>> Base Pointer with Stack Pointer
>>>>>>>>>>>> [000013c9](01)  51         push ecx               // Save
>>>>>>>>>>>> the value of ecx on the stack
>>>>>>>>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]       // Load
>>>>>>>>>>>> eax with argument to P
>>>>>>>>>>>> [000013cd](01)  50         push eax               // push
>>>>>>>>>>>> 2nd argument to H onto the stack
>>>>>>>>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]       // Load
>>>>>>>>>>>> ecx with with argument to P
>>>>>>>>>>>> [000013d1](01)  51         push ecx               // push
>>>>>>>>>>>> 1st argument to H onto the stack
>>>>>>>>>>>> [000013d2](05)  e82ffdffff call 00001106          // push
>>>>>>>>>>>> return address on the stack; call simulated H
>>>>>>>>>>>> [000013d7](03)  83c408     add esp,+08            // remove
>>>>>>>>>>>> call arguments from stack
>>>>>>>>>>>> [000013da](03)  8945fc     mov [ebp-04],eax       // load
>>>>>>>>>>>> Halt_Status with return value from H
>>>>>>>>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00 // compare
>>>>>>>>>>>> Halt_Status to 0
>>>>>>>>>>>> [000013e1](02)  7402       jz 000013e5            // if
>>>>>>>>>>>> Halt_Status == 0 goto 000013e5
>>>>>>>>>>>> [000013e3](02)  ebfe       jmp 000013e3           // goto 13e3
>>>>>>>>>>>> [000013e5](02)  8be5       mov esp,ebp            // Load
>>>>>>>>>>>> Stack Pointer with Base Pointer
>>>>>>>>>>>> [000013e7](01)  5d         pop ebp                // Restore
>>>>>>>>>>>> Base Pointer value from stack
>>>>>>>>>>>> [000013e8](01)  c3         ret                    // return
>>>>>>>>>>>> to caller
>>>>>>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>>>>>>
>>>>>>>>>>>> The instruction at machine address 13d7
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So, where is the difference between P(P) and the correct
>>>>>>>>>>> simulation of the input to H(P,P).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The instruction at machine address 13d7 cannot possibly be
>>>>>>>>>> reached by the correctly simulated input to H(P,P) when
>>>>>>>>>> correctly simulated by H.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Who said anything about the simulation by H?
>>>>>>>>>
>>>>>>>> I have kept repeating that thousands of times.
>>>>>>>> You just noticed that I was *always* referring to a simulation
>>>>>>>> by H?
>>>>>>>>
>>>>>>>
>>>>>>> Then you aren't working on the Halting Problem.
>>>>>>
>>>>>> That is currently beside the point, we can address that as a
>>>>>> separate point *only after this point has been fully addressed*
>>>>>>
>>>>>> *The current point is*
>>>>>> *The current point is*
>>>>>> *The current point is*
>>>>>>
>>>>>> It has been conclusively proven that the the correctly simulated
>>>>>> input to H(P,P) correctly simulated by H cannot possibly reach its
>>>>>> "return" instruction.
>>>>>>
>>>>>
>>>>> If you are admitting that H isn't a halt decider, what is the point?
>>>>>
>>>>
>>>> I am not admitting that H is not a halt decider.
>>>>
>>>> *The current point is*
>>>> *The current point is*
>>>> *The current point is*
>>>> It has been conclusively proven that the the correctly simulated input
>>>> to H(P,P) correctly simulated by H cannot possibly reach its "return"
>>>> instruction.
>>>>
>>>> I will not diverge from this specific point until it has been fully
>>>> understood.
>>>>
>>>>
>>>
>>> Why should I spend any time on something that isn't actually a Halt
>>> Decider.
>>>
>>
>> It is a halt decider. Why should I spend any time with someone that
>> changes the subject as their rebuttal?
>>
>> WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD
>> It has been conclusively proven that the correctly simulated
>> input to H(P,P) correctly simulated by H cannot possibly
>> reach its "return" instruction.
>>
>
> Then you agree that the test of the right answer is what the machine
> chine that its input reprents does?
>

On 7/23/22 7:46 PM, olcott wrote:
> On 7/23/2022 6:37 PM, Richard Damon wrote:
>> On 7/23/22 6:57 PM, olcott wrote:
>>> On 7/23/2022 5:22 PM, Richard Damon wrote:
>>>> On 7/23/22 6:10 PM, olcott wrote:
>>>>> On 7/23/2022 4:48 PM, Richard Damon wrote:
>>>>>> On 7/23/22 5:27 PM, olcott wrote:
>>>>>>> On 7/23/2022 4:17 PM, Richard Damon wrote:
>>>>>>>> On 7/23/22 5:11 PM, olcott wrote:
>>>>>>>>> On 7/23/2022 3:59 PM, Richard Damon wrote:
>>>>>>>>>> On 7/23/22 4:51 PM, olcott wrote:
>>>>>>>>>>> On 7/23/2022 3:45 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 7/23/22 4:33 PM, olcott wrote:
>>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7/23/22 4:08 PM, olcott wrote:
>>>>>>>>>>>>>>> On 7/23/2022 2:50 PM, Skep Dick wrote:
>>>>>>>>>>>>>>>> On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott wrote:
>>>>>>>>>>>>>>>>> This H correctly determines that its simulated input:
>>>>>>>>>>>>>>>>> (P,P) would never
>>>>>>>>>>>>>>>>> stop unless aborted.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Then how come P does the exact opposite of what H
>>>>>>>>>>>>>>>> "correctly determines"?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Every time!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It has been conclusively proven that the directly
>>>>>>>>>>>>>>> executed P(P) specifies a different sequence of
>>>>>>>>>>>>>>> instructions than the correctly simulated input to H(P,P)
>>>>>>>>>>>>>>> that H correctly simulates.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Then you are admitting that P is not the "impossible
>>>>>>>>>>>>>> program" of the proof, so your setup is NOT a counter
>>>>>>>>>>>>>> example.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That you don't believe this proof because you don't
>>>>>>>>>>>>>>> understand the execution trace that proves this is less
>>>>>>>>>>>>>>> than no actual rebuttal at all.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86
>>>>>>>>>>>>>> question for you, what is the first instruction executed
>>>>>>>>>>>>>> in P(P) that differs from the correct simulation of H(P,P)?
>>>>>>>>>>>>>
>>>>>>>>>>>>> _P()
>>>>>>>>>>>>> [000013c6](01)  55         push ebp               // Save
>>>>>>>>>>>>> Base Pointer register onto the stack
>>>>>>>>>>>>> [000013c7](02)  8bec       mov ebp,esp            // Load
>>>>>>>>>>>>> Base Pointer with Stack Pointer
>>>>>>>>>>>>> [000013c9](01)  51         push ecx               // Save
>>>>>>>>>>>>> the value of ecx on the stack
>>>>>>>>>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]       // Load
>>>>>>>>>>>>> eax with argument to P
>>>>>>>>>>>>> [000013cd](01)  50         push eax               // push
>>>>>>>>>>>>> 2nd argument to H onto the stack
>>>>>>>>>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]       // Load
>>>>>>>>>>>>> ecx with with argument to P
>>>>>>>>>>>>> [000013d1](01)  51         push ecx               // push
>>>>>>>>>>>>> 1st argument to H onto the stack
>>>>>>>>>>>>> [000013d2](05)  e82ffdffff call 00001106          // push
>>>>>>>>>>>>> return address on the stack; call simulated H
>>>>>>>>>>>>> [000013d7](03)  83c408     add esp,+08            // remove
>>>>>>>>>>>>> call arguments from stack
>>>>>>>>>>>>> [000013da](03)  8945fc     mov [ebp-04],eax       // load
>>>>>>>>>>>>> Halt_Status with return value from H
>>>>>>>>>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00 //
>>>>>>>>>>>>> compare Halt_Status to 0
>>>>>>>>>>>>> [000013e1](02)  7402       jz 000013e5            // if
>>>>>>>>>>>>> Halt_Status == 0 goto 000013e5
>>>>>>>>>>>>> [000013e3](02)  ebfe       jmp 000013e3           // goto 13e3
>>>>>>>>>>>>> [000013e5](02)  8be5       mov esp,ebp            // Load
>>>>>>>>>>>>> Stack Pointer with Base Pointer
>>>>>>>>>>>>> [000013e7](01)  5d         pop ebp                //
>>>>>>>>>>>>> Restore Base Pointer value from stack
>>>>>>>>>>>>> [000013e8](01)  c3         ret                    // return
>>>>>>>>>>>>> to caller
>>>>>>>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>>>>>>>
>>>>>>>>>>>>> The instruction at machine address 13d7
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So, where is the difference between P(P) and the correct
>>>>>>>>>>>> simulation of the input to H(P,P).
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The instruction at machine address 13d7 cannot possibly be
>>>>>>>>>>> reached by the correctly simulated input to H(P,P) when
>>>>>>>>>>> correctly simulated by H.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Who said anything about the simulation by H?
>>>>>>>>>>
>>>>>>>>> I have kept repeating that thousands of times.
>>>>>>>>> You just noticed that I was *always* referring to a simulation
>>>>>>>>> by H?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Then you aren't working on the Halting Problem.
>>>>>>>
>>>>>>> That is currently beside the point, we can address that as a
>>>>>>> separate point *only after this point has been fully addressed*
>>>>>>>
>>>>>>> *The current point is*
>>>>>>> *The current point is*
>>>>>>> *The current point is*
>>>>>>>
>>>>>>> It has been conclusively proven that the the correctly simulated
>>>>>>> input to H(P,P) correctly simulated by H cannot possibly reach
>>>>>>> its "return" instruction.
>>>>>>>
>>>>>>
>>>>>> If you are admitting that H isn't a halt decider, what is the point?
>>>>>>
>>>>>
>>>>> I am not admitting that H is not a halt decider.
>>>>>
>>>>> *The current point is*
>>>>> *The current point is*
>>>>> *The current point is*
>>>>> It has been conclusively proven that the the correctly simulated input
>>>>> to H(P,P) correctly simulated by H cannot possibly reach its "return"
>>>>> instruction.
>>>>>
>>>>> I will not diverge from this specific point until it has been fully
>>>>> understood.
>>>>>
>>>>>
>>>>
>>>> Why should I spend any time on something that isn't actually a Halt
>>>> Decider.
>>>>
>>>
>>> It is a halt decider. Why should I spend any time with someone that
>>> changes the subject as their rebuttal?
>>>
>>> WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD
>>> It has been conclusively proven that the correctly simulated
>>> input to H(P,P) correctly simulated by H cannot possibly
>>> reach its "return" instruction.
>>>
>>
>> Then you agree that the test of the right answer is what the machine
>> chine that its input reprents does?
>>
>
> *DO I NEED TO SAY THIS ONE HUNDRED MORE TIMES BEFORE YOU SEE THE WORDS*
> The actual behavior of the correctly simulated input to H(P,P) correctly
> simulated by H.
>

On 7/23/2022 7:05 PM, Richard Damon wrote:
> On 7/23/22 7:46 PM, olcott wrote:
>> On 7/23/2022 6:37 PM, Richard Damon wrote:
>>> On 7/23/22 6:57 PM, olcott wrote:
>>>> On 7/23/2022 5:22 PM, Richard Damon wrote:
>>>>> On 7/23/22 6:10 PM, olcott wrote:
>>>>>> On 7/23/2022 4:48 PM, Richard Damon wrote:
>>>>>>> On 7/23/22 5:27 PM, olcott wrote:
>>>>>>>> On 7/23/2022 4:17 PM, Richard Damon wrote:
>>>>>>>>> On 7/23/22 5:11 PM, olcott wrote:
>>>>>>>>>> On 7/23/2022 3:59 PM, Richard Damon wrote:
>>>>>>>>>>> On 7/23/22 4:51 PM, olcott wrote:
>>>>>>>>>>>> On 7/23/2022 3:45 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 7/23/22 4:33 PM, olcott wrote:
>>>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 7/23/22 4:08 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 7/23/2022 2:50 PM, Skep Dick wrote:
>>>>>>>>>>>>>>>>> On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott wrote:
>>>>>>>>>>>>>>>>>> This H correctly determines that its simulated input:
>>>>>>>>>>>>>>>>>> (P,P) would never
>>>>>>>>>>>>>>>>>> stop unless aborted.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Then how come P does the exact opposite of what H
>>>>>>>>>>>>>>>>> "correctly determines"?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Every time!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It has been conclusively proven that the directly
>>>>>>>>>>>>>>>> executed P(P) specifies a different sequence of
>>>>>>>>>>>>>>>> instructions than the correctly simulated input to
>>>>>>>>>>>>>>>> H(P,P) that H correctly simulates.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Then you are admitting that P is not the "impossible
>>>>>>>>>>>>>>> program" of the proof, so your setup is NOT a counter
>>>>>>>>>>>>>>> example.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That you don't believe this proof because you don't
>>>>>>>>>>>>>>>> understand the execution trace that proves this is less
>>>>>>>>>>>>>>>> than no actual rebuttal at all.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the
>>>>>>>>>>>>>>> x86 question for you, what is the first instruction
>>>>>>>>>>>>>>> executed in P(P) that differs from the correct simulation
>>>>>>>>>>>>>>> of H(P,P)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>> [000013c6](01)  55         push ebp               // Save
>>>>>>>>>>>>>> Base Pointer register onto the stack
>>>>>>>>>>>>>> [000013c7](02)  8bec       mov ebp,esp            // Load
>>>>>>>>>>>>>> Base Pointer with Stack Pointer
>>>>>>>>>>>>>> [000013c9](01)  51         push ecx               // Save
>>>>>>>>>>>>>> the value of ecx on the stack
>>>>>>>>>>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]       // Load
>>>>>>>>>>>>>> eax with argument to P
>>>>>>>>>>>>>> [000013cd](01)  50         push eax               // push
>>>>>>>>>>>>>> 2nd argument to H onto the stack
>>>>>>>>>>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]       // Load
>>>>>>>>>>>>>> ecx with with argument to P
>>>>>>>>>>>>>> [000013d1](01)  51         push ecx               // push
>>>>>>>>>>>>>> 1st argument to H onto the stack
>>>>>>>>>>>>>> [000013d2](05)  e82ffdffff call 00001106          // push
>>>>>>>>>>>>>> return address on the stack; call simulated H
>>>>>>>>>>>>>> [000013d7](03)  83c408     add esp,+08            //
>>>>>>>>>>>>>> remove call arguments from stack
>>>>>>>>>>>>>> [000013da](03)  8945fc     mov [ebp-04],eax       // load
>>>>>>>>>>>>>> Halt_Status with return value from H
>>>>>>>>>>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00 //
>>>>>>>>>>>>>> compare Halt_Status to 0
>>>>>>>>>>>>>> [000013e1](02)  7402       jz 000013e5            // if
>>>>>>>>>>>>>> Halt_Status == 0 goto 000013e5
>>>>>>>>>>>>>> [000013e3](02)  ebfe       jmp 000013e3           // goto
>>>>>>>>>>>>>> 13e3
>>>>>>>>>>>>>> [000013e5](02)  8be5       mov esp,ebp            // Load
>>>>>>>>>>>>>> Stack Pointer with Base Pointer
>>>>>>>>>>>>>> [000013e7](01)  5d         pop ebp                //
>>>>>>>>>>>>>> Restore Base Pointer value from stack
>>>>>>>>>>>>>> [000013e8](01)  c3         ret                    //
>>>>>>>>>>>>>> return to caller
>>>>>>>>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The instruction at machine address 13d7
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, where is the difference between P(P) and the correct
>>>>>>>>>>>>> simulation of the input to H(P,P).
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The instruction at machine address 13d7 cannot possibly be
>>>>>>>>>>>> reached by the correctly simulated input to H(P,P) when
>>>>>>>>>>>> correctly simulated by H.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Who said anything about the simulation by H?
>>>>>>>>>>>
>>>>>>>>>> I have kept repeating that thousands of times.
>>>>>>>>>> You just noticed that I was *always* referring to a simulation
>>>>>>>>>> by H?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Then you aren't working on the Halting Problem.
>>>>>>>>
>>>>>>>> That is currently beside the point, we can address that as a
>>>>>>>> separate point *only after this point has been fully addressed*
>>>>>>>>
>>>>>>>> *The current point is*
>>>>>>>> *The current point is*
>>>>>>>> *The current point is*
>>>>>>>>
>>>>>>>> It has been conclusively proven that the the correctly simulated
>>>>>>>> input to H(P,P) correctly simulated by H cannot possibly reach
>>>>>>>> its "return" instruction.
>>>>>>>>
>>>>>>>
>>>>>>> If you are admitting that H isn't a halt decider, what is the point?
>>>>>>>
>>>>>>
>>>>>> I am not admitting that H is not a halt decider.
>>>>>>
>>>>>> *The current point is*
>>>>>> *The current point is*
>>>>>> *The current point is*
>>>>>> It has been conclusively proven that the the correctly simulated
>>>>>> input
>>>>>> to H(P,P) correctly simulated by H cannot possibly reach its "return"
>>>>>> instruction.
>>>>>>
>>>>>> I will not diverge from this specific point until it has been
>>>>>> fully understood.
>>>>>>
>>>>>>
>>>>>
>>>>> Why should I spend any time on something that isn't actually a Halt
>>>>> Decider.
>>>>>
>>>>
>>>> It is a halt decider. Why should I spend any time with someone that
>>>> changes the subject as their rebuttal?
>>>>
>>>> WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD
>>>> It has been conclusively proven that the correctly simulated
>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>> reach its "return" instruction.
>>>>
>>>
>>> Then you agree that the test of the right answer is what the machine
>>> chine that its input reprents does?
>>>
>>
>> *DO I NEED TO SAY THIS ONE HUNDRED MORE TIMES BEFORE YOU SEE THE WORDS*
>> The actual behavior of the correctly simulated input to H(P,P)
>> correctly simulated by H.
>>
>
> Not if it is a Halt Decider.

On Saturday, July 23, 2022 at 8:41:14 PM UTC-4, olcott wrote:
> On 7/23/2022 7:05 PM, Richard Damon wrote:
> > On 7/23/22 7:46 PM, olcott wrote:
> >> On 7/23/2022 6:37 PM, Richard Damon wrote:
> >>> On 7/23/22 6:57 PM, olcott wrote:
> >>>> On 7/23/2022 5:22 PM, Richard Damon wrote:
> >>>>> On 7/23/22 6:10 PM, olcott wrote:
> >>>>>> On 7/23/2022 4:48 PM, Richard Damon wrote:
> >>>>>>> On 7/23/22 5:27 PM, olcott wrote:
> >>>>>>>> On 7/23/2022 4:17 PM, Richard Damon wrote:
> >>>>>>>>> On 7/23/22 5:11 PM, olcott wrote:
> >>>>>>>>>> On 7/23/2022 3:59 PM, Richard Damon wrote:
> >>>>>>>>>>> On 7/23/22 4:51 PM, olcott wrote:
> >>>>>>>>>>>> On 7/23/2022 3:45 PM, Richard Damon wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 7/23/22 4:33 PM, olcott wrote:
> >>>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 7/23/22 4:08 PM, olcott wrote:
> >>>>>>>>>>>>>>>> On 7/23/2022 2:50 PM, Skep Dick wrote:
> >>>>>>>>>>>>>>>>> On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott wrote:
> >>>>>>>>>>>>>>>>>> This H correctly determines that its simulated input:
> >>>>>>>>>>>>>>>>>> (P,P) would never
> >>>>>>>>>>>>>>>>>> stop unless aborted.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Then how come P does the exact opposite of what H
> >>>>>>>>>>>>>>>>> "correctly determines"?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Every time!
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It has been conclusively proven that the directly
> >>>>>>>>>>>>>>>> executed P(P) specifies a different sequence of
> >>>>>>>>>>>>>>>> instructions than the correctly simulated input to
> >>>>>>>>>>>>>>>> H(P,P) that H correctly simulates.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Then you are admitting that P is not the "impossible
> >>>>>>>>>>>>>>> program" of the proof, so your setup is NOT a counter
> >>>>>>>>>>>>>>> example.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> That you don't believe this proof because you don't
> >>>>>>>>>>>>>>>> understand the execution trace that proves this is less
> >>>>>>>>>>>>>>>> than no actual rebuttal at all.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the
> >>>>>>>>>>>>>>> x86 question for you, what is the first instruction
> >>>>>>>>>>>>>>> executed in P(P) that differs from the correct simulation
> >>>>>>>>>>>>>>> of H(P,P)?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>> [000013c6](01) 55 push ebp // Save
> >>>>>>>>>>>>>> Base Pointer register onto the stack
> >>>>>>>>>>>>>> [000013c7](02) 8bec mov ebp,esp // Load
> >>>>>>>>>>>>>> Base Pointer with Stack Pointer
> >>>>>>>>>>>>>> [000013c9](01) 51 push ecx // Save
> >>>>>>>>>>>>>> the value of ecx on the stack
> >>>>>>>>>>>>>> [000013ca](03) 8b4508 mov eax,[ebp+08] // Load
> >>>>>>>>>>>>>> eax with argument to P
> >>>>>>>>>>>>>> [000013cd](01) 50 push eax // push
> >>>>>>>>>>>>>> 2nd argument to H onto the stack
> >>>>>>>>>>>>>> [000013ce](03) 8b4d08 mov ecx,[ebp+08] // Load
> >>>>>>>>>>>>>> ecx with with argument to P
> >>>>>>>>>>>>>> [000013d1](01) 51 push ecx // push
> >>>>>>>>>>>>>> 1st argument to H onto the stack
> >>>>>>>>>>>>>> [000013d2](05) e82ffdffff call 00001106 // push
> >>>>>>>>>>>>>> return address on the stack; call simulated H
> >>>>>>>>>>>>>> [000013d7](03) 83c408 add esp,+08 //
> >>>>>>>>>>>>>> remove call arguments from stack
> >>>>>>>>>>>>>> [000013da](03) 8945fc mov [ebp-04],eax // load
> >>>>>>>>>>>>>> Halt_Status with return value from H
> >>>>>>>>>>>>>> [000013dd](04) 837dfc00 cmp dword [ebp-04],+00 //
> >>>>>>>>>>>>>> compare Halt_Status to 0
> >>>>>>>>>>>>>> [000013e1](02) 7402 jz 000013e5 // if
> >>>>>>>>>>>>>> Halt_Status == 0 goto 000013e5
> >>>>>>>>>>>>>> [000013e3](02) ebfe jmp 000013e3 // goto
> >>>>>>>>>>>>>> 13e3
> >>>>>>>>>>>>>> [000013e5](02) 8be5 mov esp,ebp // Load
> >>>>>>>>>>>>>> Stack Pointer with Base Pointer
> >>>>>>>>>>>>>> [000013e7](01) 5d pop ebp //
> >>>>>>>>>>>>>> Restore Base Pointer value from stack
> >>>>>>>>>>>>>> [000013e8](01) c3 ret //
> >>>>>>>>>>>>>> return to caller
> >>>>>>>>>>>>>> Size in bytes:(0035) [000013e8]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The instruction at machine address 13d7
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So, where is the difference between P(P) and the correct
> >>>>>>>>>>>>> simulation of the input to H(P,P).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> The instruction at machine address 13d7 cannot possibly be
> >>>>>>>>>>>> reached by the correctly simulated input to H(P,P) when
> >>>>>>>>>>>> correctly simulated by H.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Who said anything about the simulation by H?
> >>>>>>>>>>>
> >>>>>>>>>> I have kept repeating that thousands of times.
> >>>>>>>>>> You just noticed that I was *always* referring to a simulation
> >>>>>>>>>> by H?
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Then you aren't working on the Halting Problem.
> >>>>>>>>
> >>>>>>>> That is currently beside the point, we can address that as a
> >>>>>>>> separate point *only after this point has been fully addressed*
> >>>>>>>>
> >>>>>>>> *The current point is*
> >>>>>>>> *The current point is*
> >>>>>>>> *The current point is*
> >>>>>>>>
> >>>>>>>> It has been conclusively proven that the the correctly simulated
> >>>>>>>> input to H(P,P) correctly simulated by H cannot possibly reach
> >>>>>>>> its "return" instruction.
> >>>>>>>>
> >>>>>>>
> >>>>>>> If you are admitting that H isn't a halt decider, what is the point?
> >>>>>>>
> >>>>>>
> >>>>>> I am not admitting that H is not a halt decider.
> >>>>>>
> >>>>>> *The current point is*
> >>>>>> *The current point is*
> >>>>>> *The current point is*
> >>>>>> It has been conclusively proven that the the correctly simulated
> >>>>>> input
> >>>>>> to H(P,P) correctly simulated by H cannot possibly reach its "return"
> >>>>>> instruction.
> >>>>>>
> >>>>>> I will not diverge from this specific point until it has been
> >>>>>> fully understood.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> Why should I spend any time on something that isn't actually a Halt
> >>>>> Decider.
> >>>>>
> >>>>
> >>>> It is a halt decider. Why should I spend any time with someone that
> >>>> changes the subject as their rebuttal?
> >>>>
> >>>> WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD
> >>>> It has been conclusively proven that the correctly simulated
> >>>> input to H(P,P) correctly simulated by H cannot possibly
> >>>> reach its "return" instruction.
> >>>>
> >>>
> >>> Then you agree that the test of the right answer is what the machine
> >>> chine that its input reprents does?
> >>>
> >>
> >> *DO I NEED TO SAY THIS ONE HUNDRED MORE TIMES BEFORE YOU SEE THE WORDS*
> >> The actual behavior of the correctly simulated input to H(P,P)
> >> correctly simulated by H.
> >>
> >
> > Not if it is a Halt Decider.
> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> It has been conclusively proven that the correctly simulated
> input to H(P,P) correctly simulated by H cannot possibly
> reach its "return" instruction.

On 7/23/22 8:41 PM, olcott wrote:
> On 7/23/2022 7:05 PM, Richard Damon wrote:
>> On 7/23/22 7:46 PM, olcott wrote:
>>> On 7/23/2022 6:37 PM, Richard Damon wrote:
>>>> On 7/23/22 6:57 PM, olcott wrote:
>>>>> On 7/23/2022 5:22 PM, Richard Damon wrote:
>>>>>> On 7/23/22 6:10 PM, olcott wrote:
>>>>>>> On 7/23/2022 4:48 PM, Richard Damon wrote:
>>>>>>>> On 7/23/22 5:27 PM, olcott wrote:
>>>>>>>>> On 7/23/2022 4:17 PM, Richard Damon wrote:
>>>>>>>>>> On 7/23/22 5:11 PM, olcott wrote:
>>>>>>>>>>> On 7/23/2022 3:59 PM, Richard Damon wrote:
>>>>>>>>>>>> On 7/23/22 4:51 PM, olcott wrote:
>>>>>>>>>>>>> On 7/23/2022 3:45 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7/23/22 4:33 PM, olcott wrote:
>>>>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 7/23/22 4:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 7/23/2022 2:50 PM, Skep Dick wrote:
>>>>>>>>>>>>>>>>>> On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> This H correctly determines that its simulated input:
>>>>>>>>>>>>>>>>>>> (P,P) would never
>>>>>>>>>>>>>>>>>>> stop unless aborted.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Then how come P does the exact opposite of what H
>>>>>>>>>>>>>>>>>> "correctly determines"?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Every time!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It has been conclusively proven that the directly
>>>>>>>>>>>>>>>>> executed P(P) specifies a different sequence of
>>>>>>>>>>>>>>>>> instructions than the correctly simulated input to
>>>>>>>>>>>>>>>>> H(P,P) that H correctly simulates.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Then you are admitting that P is not the "impossible
>>>>>>>>>>>>>>>> program" of the proof, so your setup is NOT a counter
>>>>>>>>>>>>>>>> example.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That you don't believe this proof because you don't
>>>>>>>>>>>>>>>>> understand the execution trace that proves this is less
>>>>>>>>>>>>>>>>> than no actual rebuttal at all.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the
>>>>>>>>>>>>>>>> x86 question for you, what is the first instruction
>>>>>>>>>>>>>>>> executed in P(P) that differs from the correct
>>>>>>>>>>>>>>>> simulation of H(P,P)?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>> [000013c6](01)  55         push ebp               // Save
>>>>>>>>>>>>>>> Base Pointer register onto the stack
>>>>>>>>>>>>>>> [000013c7](02)  8bec       mov ebp,esp            // Load
>>>>>>>>>>>>>>> Base Pointer with Stack Pointer
>>>>>>>>>>>>>>> [000013c9](01)  51         push ecx               // Save
>>>>>>>>>>>>>>> the value of ecx on the stack
>>>>>>>>>>>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]       // Load
>>>>>>>>>>>>>>> eax with argument to P
>>>>>>>>>>>>>>> [000013cd](01)  50         push eax               // push
>>>>>>>>>>>>>>> 2nd argument to H onto the stack
>>>>>>>>>>>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]       // Load
>>>>>>>>>>>>>>> ecx with with argument to P
>>>>>>>>>>>>>>> [000013d1](01)  51         push ecx               // push
>>>>>>>>>>>>>>> 1st argument to H onto the stack
>>>>>>>>>>>>>>> [000013d2](05)  e82ffdffff call 00001106          // push
>>>>>>>>>>>>>>> return address on the stack; call simulated H
>>>>>>>>>>>>>>> [000013d7](03)  83c408     add esp,+08            //
>>>>>>>>>>>>>>> remove call arguments from stack
>>>>>>>>>>>>>>> [000013da](03)  8945fc     mov [ebp-04],eax       // load
>>>>>>>>>>>>>>> Halt_Status with return value from H
>>>>>>>>>>>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00 //
>>>>>>>>>>>>>>> compare Halt_Status to 0
>>>>>>>>>>>>>>> [000013e1](02)  7402       jz 000013e5            // if
>>>>>>>>>>>>>>> Halt_Status == 0 goto 000013e5
>>>>>>>>>>>>>>> [000013e3](02)  ebfe       jmp 000013e3           // goto
>>>>>>>>>>>>>>> 13e3
>>>>>>>>>>>>>>> [000013e5](02)  8be5       mov esp,ebp            // Load
>>>>>>>>>>>>>>> Stack Pointer with Base Pointer
>>>>>>>>>>>>>>> [000013e7](01)  5d         pop ebp                //
>>>>>>>>>>>>>>> Restore Base Pointer value from stack
>>>>>>>>>>>>>>> [000013e8](01)  c3         ret                    //
>>>>>>>>>>>>>>> return to caller
>>>>>>>>>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The instruction at machine address 13d7
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, where is the difference between P(P) and the correct
>>>>>>>>>>>>>> simulation of the input to H(P,P).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The instruction at machine address 13d7 cannot possibly be
>>>>>>>>>>>>> reached by the correctly simulated input to H(P,P) when
>>>>>>>>>>>>> correctly simulated by H.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Who said anything about the simulation by H?
>>>>>>>>>>>>
>>>>>>>>>>> I have kept repeating that thousands of times.
>>>>>>>>>>> You just noticed that I was *always* referring to a
>>>>>>>>>>> simulation by H?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Then you aren't working on the Halting Problem.
>>>>>>>>>
>>>>>>>>> That is currently beside the point, we can address that as a
>>>>>>>>> separate point *only after this point has been fully addressed*
>>>>>>>>>
>>>>>>>>> *The current point is*
>>>>>>>>> *The current point is*
>>>>>>>>> *The current point is*
>>>>>>>>>
>>>>>>>>> It has been conclusively proven that the the correctly
>>>>>>>>> simulated input to H(P,P) correctly simulated by H cannot
>>>>>>>>> possibly reach its "return" instruction.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If you are admitting that H isn't a halt decider, what is the
>>>>>>>> point?
>>>>>>>>
>>>>>>>
>>>>>>> I am not admitting that H is not a halt decider.
>>>>>>>
>>>>>>> *The current point is*
>>>>>>> *The current point is*
>>>>>>> *The current point is*
>>>>>>> It has been conclusively proven that the the correctly simulated
>>>>>>> input
>>>>>>> to H(P,P) correctly simulated by H cannot possibly reach its
>>>>>>> "return"
>>>>>>> instruction.
>>>>>>>
>>>>>>> I will not diverge from this specific point until it has been
>>>>>>> fully understood.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Why should I spend any time on something that isn't actually a
>>>>>> Halt Decider.
>>>>>>
>>>>>
>>>>> It is a halt decider. Why should I spend any time with someone that
>>>>> changes the subject as their rebuttal?
>>>>>
>>>>> WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD
>>>>> It has been conclusively proven that the correctly simulated
>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>> reach its "return" instruction.
>>>>>
>>>>
>>>> Then you agree that the test of the right answer is what the machine
>>>> chine that its input reprents does?
>>>>
>>>
>>> *DO I NEED TO SAY THIS ONE HUNDRED MORE TIMES BEFORE YOU SEE THE WORDS*
>>> The actual behavior of the correctly simulated input to H(P,P)
>>> correctly simulated by H.
>>>
>>
>> Not if it is a Halt Decider.
>
> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> It has been conclusively proven that the correctly simulated
> input to H(P,P) correctly simulated by H cannot possibly
> reach its "return" instruction.
>
>

On 7/23/2022 8:10 PM, Richard Damon wrote:
> On 7/23/22 8:41 PM, olcott wrote:
>> On 7/23/2022 7:05 PM, Richard Damon wrote:
>>> On 7/23/22 7:46 PM, olcott wrote:
>>>> On 7/23/2022 6:37 PM, Richard Damon wrote:
>>>>> On 7/23/22 6:57 PM, olcott wrote:
>>>>>> On 7/23/2022 5:22 PM, Richard Damon wrote:
>>>>>>> On 7/23/22 6:10 PM, olcott wrote:
>>>>>>>> On 7/23/2022 4:48 PM, Richard Damon wrote:
>>>>>>>>> On 7/23/22 5:27 PM, olcott wrote:
>>>>>>>>>> On 7/23/2022 4:17 PM, Richard Damon wrote:
>>>>>>>>>>> On 7/23/22 5:11 PM, olcott wrote:
>>>>>>>>>>>> On 7/23/2022 3:59 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 7/23/22 4:51 PM, olcott wrote:
>>>>>>>>>>>>>> On 7/23/2022 3:45 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 7/23/22 4:33 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 7/23/22 4:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 7/23/2022 2:50 PM, Skep Dick wrote:
>>>>>>>>>>>>>>>>>>> On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> This H correctly determines that its simulated
>>>>>>>>>>>>>>>>>>>> input: (P,P) would never
>>>>>>>>>>>>>>>>>>>> stop unless aborted.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Then how come P does the exact opposite of what H
>>>>>>>>>>>>>>>>>>> "correctly determines"?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Every time!
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It has been conclusively proven that the directly
>>>>>>>>>>>>>>>>>> executed P(P) specifies a different sequence of
>>>>>>>>>>>>>>>>>> instructions than the correctly simulated input to
>>>>>>>>>>>>>>>>>> H(P,P) that H correctly simulates.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Then you are admitting that P is not the "impossible
>>>>>>>>>>>>>>>>> program" of the proof, so your setup is NOT a counter
>>>>>>>>>>>>>>>>> example.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That you don't believe this proof because you don't
>>>>>>>>>>>>>>>>>> understand the execution trace that proves this is
>>>>>>>>>>>>>>>>>> less than no actual rebuttal at all.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the
>>>>>>>>>>>>>>>>> x86 question for you, what is the first instruction
>>>>>>>>>>>>>>>>> executed in P(P) that differs from the correct
>>>>>>>>>>>>>>>>> simulation of H(P,P)?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>> [000013c6](01)  55         push ebp               //
>>>>>>>>>>>>>>>> Save Base Pointer register onto the stack
>>>>>>>>>>>>>>>> [000013c7](02)  8bec       mov ebp,esp            //
>>>>>>>>>>>>>>>> Load Base Pointer with Stack Pointer
>>>>>>>>>>>>>>>> [000013c9](01)  51         push ecx               //
>>>>>>>>>>>>>>>> Save the value of ecx on the stack
>>>>>>>>>>>>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]       //
>>>>>>>>>>>>>>>> Load eax with argument to P
>>>>>>>>>>>>>>>> [000013cd](01)  50         push eax               //
>>>>>>>>>>>>>>>> push 2nd argument to H onto the stack
>>>>>>>>>>>>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]       //
>>>>>>>>>>>>>>>> Load ecx with with argument to P
>>>>>>>>>>>>>>>> [000013d1](01)  51         push ecx               //
>>>>>>>>>>>>>>>> push 1st argument to H onto the stack
>>>>>>>>>>>>>>>> [000013d2](05)  e82ffdffff call 00001106          //
>>>>>>>>>>>>>>>> push return address on the stack; call simulated H
>>>>>>>>>>>>>>>> [000013d7](03)  83c408     add esp,+08            //
>>>>>>>>>>>>>>>> remove call arguments from stack
>>>>>>>>>>>>>>>> [000013da](03)  8945fc     mov [ebp-04],eax       //
>>>>>>>>>>>>>>>> load Halt_Status with return value from H
>>>>>>>>>>>>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00 //
>>>>>>>>>>>>>>>> compare Halt_Status to 0
>>>>>>>>>>>>>>>> [000013e1](02)  7402       jz 000013e5            // if
>>>>>>>>>>>>>>>> Halt_Status == 0 goto 000013e5
>>>>>>>>>>>>>>>> [000013e3](02)  ebfe       jmp 000013e3           //
>>>>>>>>>>>>>>>> goto 13e3
>>>>>>>>>>>>>>>> [000013e5](02)  8be5       mov esp,ebp            //
>>>>>>>>>>>>>>>> Load Stack Pointer with Base Pointer
>>>>>>>>>>>>>>>> [000013e7](01)  5d         pop ebp                //
>>>>>>>>>>>>>>>> Restore Base Pointer value from stack
>>>>>>>>>>>>>>>> [000013e8](01)  c3         ret                    //
>>>>>>>>>>>>>>>> return to caller
>>>>>>>>>>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The instruction at machine address 13d7
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, where is the difference between P(P) and the correct
>>>>>>>>>>>>>>> simulation of the input to H(P,P).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The instruction at machine address 13d7 cannot possibly be
>>>>>>>>>>>>>> reached by the correctly simulated input to H(P,P) when
>>>>>>>>>>>>>> correctly simulated by H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Who said anything about the simulation by H?
>>>>>>>>>>>>>
>>>>>>>>>>>> I have kept repeating that thousands of times.
>>>>>>>>>>>> You just noticed that I was *always* referring to a
>>>>>>>>>>>> simulation by H?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Then you aren't working on the Halting Problem.
>>>>>>>>>>
>>>>>>>>>> That is currently beside the point, we can address that as a
>>>>>>>>>> separate point *only after this point has been fully addressed*
>>>>>>>>>>
>>>>>>>>>> *The current point is*
>>>>>>>>>> *The current point is*
>>>>>>>>>> *The current point is*
>>>>>>>>>>
>>>>>>>>>> It has been conclusively proven that the the correctly
>>>>>>>>>> simulated input to H(P,P) correctly simulated by H cannot
>>>>>>>>>> possibly reach its "return" instruction.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If you are admitting that H isn't a halt decider, what is the
>>>>>>>>> point?
>>>>>>>>>
>>>>>>>>
>>>>>>>> I am not admitting that H is not a halt decider.
>>>>>>>>
>>>>>>>> *The current point is*
>>>>>>>> *The current point is*
>>>>>>>> *The current point is*
>>>>>>>> It has been conclusively proven that the the correctly simulated
>>>>>>>> input
>>>>>>>> to H(P,P) correctly simulated by H cannot possibly reach its
>>>>>>>> "return"
>>>>>>>> instruction.
>>>>>>>>
>>>>>>>> I will not diverge from this specific point until it has been
>>>>>>>> fully understood.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Why should I spend any time on something that isn't actually a
>>>>>>> Halt Decider.
>>>>>>>
>>>>>>
>>>>>> It is a halt decider. Why should I spend any time with someone
>>>>>> that changes the subject as their rebuttal?
>>>>>>
>>>>>> WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD
>>>>>> It has been conclusively proven that the correctly simulated
>>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>>> reach its "return" instruction.
>>>>>>
>>>>>
>>>>> Then you agree that the test of the right answer is what the
>>>>> machine chine that its input reprents does?
>>>>>
>>>>
>>>> *DO I NEED TO SAY THIS ONE HUNDRED MORE TIMES BEFORE YOU SEE THE WORDS*
>>>> The actual behavior of the correctly simulated input to H(P,P)
>>>> correctly simulated by H.
>>>>
>>>
>>> Not if it is a Halt Decider.
>>
>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>> It has been conclusively proven that the correctly simulated
>> input to H(P,P) correctly simulated by H cannot possibly
>> reach its "return" instruction.
>>
>>
>
> So, that isn't the halt condition, so it doesn't matter.
>

On Saturday, July 23, 2022 at 9:12:59 PM UTC-4, olcott wrote:
> On 7/23/2022 8:10 PM, Richard Damon wrote:
> > On 7/23/22 8:41 PM, olcott wrote:
> >> On 7/23/2022 7:05 PM, Richard Damon wrote:
> >>> On 7/23/22 7:46 PM, olcott wrote:
> >>>> On 7/23/2022 6:37 PM, Richard Damon wrote:
> >>>>> On 7/23/22 6:57 PM, olcott wrote:
> >>>>>> On 7/23/2022 5:22 PM, Richard Damon wrote:
> >>>>>>> On 7/23/22 6:10 PM, olcott wrote:
> >>>>>>>> On 7/23/2022 4:48 PM, Richard Damon wrote:
> >>>>>>>>> On 7/23/22 5:27 PM, olcott wrote:
> >>>>>>>>>> On 7/23/2022 4:17 PM, Richard Damon wrote:
> >>>>>>>>>>> On 7/23/22 5:11 PM, olcott wrote:
> >>>>>>>>>>>> On 7/23/2022 3:59 PM, Richard Damon wrote:
> >>>>>>>>>>>>> On 7/23/22 4:51 PM, olcott wrote:
> >>>>>>>>>>>>>> On 7/23/2022 3:45 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 7/23/22 4:33 PM, olcott wrote:
> >>>>>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 7/23/22 4:08 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 7/23/2022 2:50 PM, Skep Dick wrote:
> >>>>>>>>>>>>>>>>>>> On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>> This H correctly determines that its simulated
> >>>>>>>>>>>>>>>>>>>> input: (P,P) would never
> >>>>>>>>>>>>>>>>>>>> stop unless aborted.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Then how come P does the exact opposite of what H
> >>>>>>>>>>>>>>>>>>> "correctly determines"?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Every time!
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It has been conclusively proven that the directly
> >>>>>>>>>>>>>>>>>> executed P(P) specifies a different sequence of
> >>>>>>>>>>>>>>>>>> instructions than the correctly simulated input to
> >>>>>>>>>>>>>>>>>> H(P,P) that H correctly simulates.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Then you are admitting that P is not the "impossible
> >>>>>>>>>>>>>>>>> program" of the proof, so your setup is NOT a counter
> >>>>>>>>>>>>>>>>> example.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> That you don't believe this proof because you don't
> >>>>>>>>>>>>>>>>>> understand the execution trace that proves this is
> >>>>>>>>>>>>>>>>>> less than no actual rebuttal at all.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the
> >>>>>>>>>>>>>>>>> x86 question for you, what is the first instruction
> >>>>>>>>>>>>>>>>> executed in P(P) that differs from the correct
> >>>>>>>>>>>>>>>>> simulation of H(P,P)?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>>>> [000013c6](01) 55 push ebp //
> >>>>>>>>>>>>>>>> Save Base Pointer register onto the stack
> >>>>>>>>>>>>>>>> [000013c7](02) 8bec mov ebp,esp //
> >>>>>>>>>>>>>>>> Load Base Pointer with Stack Pointer
> >>>>>>>>>>>>>>>> [000013c9](01) 51 push ecx //
> >>>>>>>>>>>>>>>> Save the value of ecx on the stack
> >>>>>>>>>>>>>>>> [000013ca](03) 8b4508 mov eax,[ebp+08] //
> >>>>>>>>>>>>>>>> Load eax with argument to P
> >>>>>>>>>>>>>>>> [000013cd](01) 50 push eax //
> >>>>>>>>>>>>>>>> push 2nd argument to H onto the stack
> >>>>>>>>>>>>>>>> [000013ce](03) 8b4d08 mov ecx,[ebp+08] //
> >>>>>>>>>>>>>>>> Load ecx with with argument to P
> >>>>>>>>>>>>>>>> [000013d1](01) 51 push ecx //
> >>>>>>>>>>>>>>>> push 1st argument to H onto the stack
> >>>>>>>>>>>>>>>> [000013d2](05) e82ffdffff call 00001106 //
> >>>>>>>>>>>>>>>> push return address on the stack; call simulated H
> >>>>>>>>>>>>>>>> [000013d7](03) 83c408 add esp,+08 //
> >>>>>>>>>>>>>>>> remove call arguments from stack
> >>>>>>>>>>>>>>>> [000013da](03) 8945fc mov [ebp-04],eax //
> >>>>>>>>>>>>>>>> load Halt_Status with return value from H
> >>>>>>>>>>>>>>>> [000013dd](04) 837dfc00 cmp dword [ebp-04],+00 //
> >>>>>>>>>>>>>>>> compare Halt_Status to 0
> >>>>>>>>>>>>>>>> [000013e1](02) 7402 jz 000013e5 // if
> >>>>>>>>>>>>>>>> Halt_Status == 0 goto 000013e5
> >>>>>>>>>>>>>>>> [000013e3](02) ebfe jmp 000013e3 //
> >>>>>>>>>>>>>>>> goto 13e3
> >>>>>>>>>>>>>>>> [000013e5](02) 8be5 mov esp,ebp //
> >>>>>>>>>>>>>>>> Load Stack Pointer with Base Pointer
> >>>>>>>>>>>>>>>> [000013e7](01) 5d pop ebp //
> >>>>>>>>>>>>>>>> Restore Base Pointer value from stack
> >>>>>>>>>>>>>>>> [000013e8](01) c3 ret //
> >>>>>>>>>>>>>>>> return to caller
> >>>>>>>>>>>>>>>> Size in bytes:(0035) [000013e8]
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The instruction at machine address 13d7
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> So, where is the difference between P(P) and the correct
> >>>>>>>>>>>>>>> simulation of the input to H(P,P).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The instruction at machine address 13d7 cannot possibly be
> >>>>>>>>>>>>>> reached by the correctly simulated input to H(P,P) when
> >>>>>>>>>>>>>> correctly simulated by H.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Who said anything about the simulation by H?
> >>>>>>>>>>>>>
> >>>>>>>>>>>> I have kept repeating that thousands of times.
> >>>>>>>>>>>> You just noticed that I was *always* referring to a
> >>>>>>>>>>>> simulation by H?
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Then you aren't working on the Halting Problem.
> >>>>>>>>>>
> >>>>>>>>>> That is currently beside the point, we can address that as a
> >>>>>>>>>> separate point *only after this point has been fully addressed*
> >>>>>>>>>>
> >>>>>>>>>> *The current point is*
> >>>>>>>>>> *The current point is*
> >>>>>>>>>> *The current point is*
> >>>>>>>>>>
> >>>>>>>>>> It has been conclusively proven that the the correctly
> >>>>>>>>>> simulated input to H(P,P) correctly simulated by H cannot
> >>>>>>>>>> possibly reach its "return" instruction.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> If you are admitting that H isn't a halt decider, what is the
> >>>>>>>>> point?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I am not admitting that H is not a halt decider.
> >>>>>>>>
> >>>>>>>> *The current point is*
> >>>>>>>> *The current point is*
> >>>>>>>> *The current point is*
> >>>>>>>> It has been conclusively proven that the the correctly simulated
> >>>>>>>> input
> >>>>>>>> to H(P,P) correctly simulated by H cannot possibly reach its
> >>>>>>>> "return"
> >>>>>>>> instruction.
> >>>>>>>>
> >>>>>>>> I will not diverge from this specific point until it has been
> >>>>>>>> fully understood.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> Why should I spend any time on something that isn't actually a
> >>>>>>> Halt Decider.
> >>>>>>>
> >>>>>>
> >>>>>> It is a halt decider. Why should I spend any time with someone
> >>>>>> that changes the subject as their rebuttal?
> >>>>>>
> >>>>>> WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD
> >>>>>> It has been conclusively proven that the correctly simulated
> >>>>>> input to H(P,P) correctly simulated by H cannot possibly
> >>>>>> reach its "return" instruction.
> >>>>>>
> >>>>>
> >>>>> Then you agree that the test of the right answer is what the
> >>>>> machine chine that its input reprents does?
> >>>>>
> >>>>
> >>>> *DO I NEED TO SAY THIS ONE HUNDRED MORE TIMES BEFORE YOU SEE THE WORDS*
> >>>> The actual behavior of the correctly simulated input to H(P,P)
> >>>> correctly simulated by H.
> >>>>
> >>>
> >>> Not if it is a Halt Decider.
> >>
> >> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> >> It has been conclusively proven that the correctly simulated
> >> input to H(P,P) correctly simulated by H cannot possibly
> >> reach its "return" instruction.
> >>
> >>
> >
> > So, that isn't the halt condition, so it doesn't matter.
> >
> If you keep changing the subject I will block you again.
> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> It has been conclusively proven that the correctly simulated
> input to H(P,P) correctly simulated by H cannot possibly
> reach its "return" instruction.

On 7/23/22 9:12 PM, olcott wrote:
> On 7/23/2022 8:10 PM, Richard Damon wrote:
>> On 7/23/22 8:41 PM, olcott wrote:
>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
>
>>>>
>>>> Not if it is a Halt Decider.
>>>
>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>> It has been conclusively proven that the correctly simulated
>>> input to H(P,P) correctly simulated by H cannot possibly
>>> reach its "return" instruction.
>>>
>>>
>>
>> So, that isn't the halt condition, so it doesn't matter.
>>
>
> If you keep changing the subject I will block you again.
>
> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> It has been conclusively proven that the correctly simulated
> input to H(P,P) correctly simulated by H cannot possibly
> reach its "return" instruction.
>
>

So, what do you think I don't understand or accept?

I agree that it is a fact that H can't ever simulate its input to a
final state. And that the simulation that H performs is a "correct but
partial simulation" (partial if H aborts to return the non-halting answer).

Is it you don't like that I throw the caviates into my statements that
you will most certainly ignore later on in your arguement. That I point
out the errors in a future step before you can establish the smoke
screen you need to try to hide it?

I accept that your H can be a completetly accurate POOP decider, using
this altered criteria that isn't quite halting. Since your criteria
isn't the halting criteria, it isn't a correct Halt decider.

All you have done is proven that H can't prove that P(P) Halts, as to do
that, it needs to simulate to that return instruction, which you have
shown it can never do.

You have shown that the H that doesn't abort it simulation, either
because it can't or just never finds the right pattern generates a
non-halting P(P), but also that it doens't answer so fails to be a decider.

On 7/23/2022 8:31 PM, Richard Damon wrote:
>
> On 7/23/22 9:12 PM, olcott wrote:
>> On 7/23/2022 8:10 PM, Richard Damon wrote:
>>> On 7/23/22 8:41 PM, olcott wrote:
>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
>>
>>>>>
>>>>> Not if it is a Halt Decider.
>>>>
>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>> It has been conclusively proven that the correctly simulated
>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>> reach its "return" instruction.
>>>>
>>>>
>>>
>>> So, that isn't the halt condition, so it doesn't matter.
>>>
>>
>> If you keep changing the subject I will block you again.
>>
>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>> It has been conclusively proven that the correctly simulated
>> input to H(P,P) correctly simulated by H cannot possibly
>> reach its "return" instruction.
>>
>>
>
> So, what do you think I don't understand or accept?
>

Just say that every word of my above paragraph is completely true.

--
Copyright 2022 Pete Olcott

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

On 7/23/2022 8:31 PM, Richard Damon wrote:
>
> On 7/23/22 9:12 PM, olcott wrote:
>> On 7/23/2022 8:10 PM, Richard Damon wrote:
>>> On 7/23/22 8:41 PM, olcott wrote:
>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
>>
>>>>>
>>>>> Not if it is a Halt Decider.
>>>>
>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>> It has been conclusively proven that the correctly simulated
>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>> reach its "return" instruction.
>>>>
>>>>
>>>
>>> So, that isn't the halt condition, so it doesn't matter.
>>>
>>
>> If you keep changing the subject I will block you again.
>>
>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>> It has been conclusively proven that the correctly simulated
>> input to H(P,P) correctly simulated by H cannot possibly
>> reach its "return" instruction.
>>
>>
>
> So, what do you think I don't understand or accept?

Just say that you honestly and sincerely totally accept that
every single word of my above paragraph is completely true.

--
Copyright 2022 Pete Olcott

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

On 7/23/22 9:40 PM, olcott wrote:
> On 7/23/2022 8:31 PM, Richard Damon wrote:
>>
>> On 7/23/22 9:12 PM, olcott wrote:
>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
>>>> On 7/23/22 8:41 PM, olcott wrote:
>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
>>>
>>>>>>
>>>>>> Not if it is a Halt Decider.
>>>>>
>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>> It has been conclusively proven that the correctly simulated
>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>> reach its "return" instruction.
>>>>>
>>>>>
>>>>
>>>> So, that isn't the halt condition, so it doesn't matter.
>>>>
>>>
>>> If you keep changing the subject I will block you again.
>>>
>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>> It has been conclusively proven that the correctly simulated
>>> input to H(P,P) correctly simulated by H cannot possibly
>>> reach its "return" instruction.
>>>
>>>
>>
>> So, what do you think I don't understand or accept?
>>
>
> Just say that every word of my above paragraph is completely true.
>
>

Why, can't you understand polysylabic words?

And, because of some of your use of adjectives, I don't belaive it to
that extend.

First, you haven't provided a "conclusive proof", but an informal one
that shows what you mean to show and does it with enough that people
will accept it.

Also, you use words with shades of meaning, and the above is only true
for SOME of those meanings, and if factually incorrect for others.

For instance, H's simulation is "correct" for the part that it has
simulated, but it is not "complete", and some usages of correct imply
complete, so you statement isn't correct under that definition.

YOU have PROVED that you have a tendency to abuse the meaning of words,
so I will not give you that sort or carte-blanch.

Now, if your argument is so fragile that it needs the sort of blanket
acceptance of stages, then it is flawed, and almost certainly is based
on dishonest word play.

Since I KNOW that you ultimate goal is something that you have not
proved, I won't give carte-blanch, because even without giving it, you
still misuse words.

On 7/23/2022 9:08 PM, Richard Damon wrote:
> On 7/23/22 9:40 PM, olcott wrote:
>> On 7/23/2022 8:31 PM, Richard Damon wrote:
>>>
>>> On 7/23/22 9:12 PM, olcott wrote:
>>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
>>>>> On 7/23/22 8:41 PM, olcott wrote:
>>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
>>>>
>>>>>>>
>>>>>>> Not if it is a Halt Decider.
>>>>>>
>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>>> It has been conclusively proven that the correctly simulated
>>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>>> reach its "return" instruction.
>>>>>>
>>>>>>
>>>>>
>>>>> So, that isn't the halt condition, so it doesn't matter.
>>>>>
>>>>
>>>> If you keep changing the subject I will block you again.
>>>>
>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>> It has been conclusively proven that the correctly simulated
>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>> reach its "return" instruction.
>>>>
>>>>
>>>
>>> So, what do you think I don't understand or accept?
>>>
>>
>> Just say that every word of my above paragraph is completely true.
>>
>>
>
> Why, can't you understand polysylabic words?
>
> And, because of some of your use of adjectives, I don't belaive it to
> that extend.
>
> First, you haven't provided a "conclusive proof",

In other words the conclusive proof in Example 03 is either over your
head or not explained well enough or some of both.

*Halting problem proofs refuted on the basis of software engineering* ?

https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

--
Copyright 2022 Pete Olcott

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