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

--
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 Saturday, 23 July 2022 at 22:27:51 UTC+2, olcott wrote:
> On 7/23/2022 3:12 PM, Skep Dick wrote:
> > On Saturday, 23 July 2022 at 22:08:48 UTC+2, 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.
> >>
> >> 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.
> >>
> >> That you say that I am wrong entirely on the basis of your lack of
> >> understanding of the x86 language is dishonest and rude.
> >
> > That you say that it has been "conclusively proven", and that the simulation is "correct" is entirely based on your opinion.
> >
> That you (and others) lack the technical skill to verify a fact does not
> actually logically entail that this fact has not been verified.

That you (and others) lack the technical skill to verify the fact that 1+1=3 does not actually logically entail that 1+1 does not equal 3.

Facts! You can't deny them.

#include <stdio.h>
int add(int a, int b){
if ( (a ==1) && (b==1)){
return 3;
}
return a+b;
} int main(){
printf("1 + 1 = %d \n", add(1,1));
}

➜ ~ gcc h.c
➜ ~ ./a.out
1 + 1 = 3

On 7/23/22 4:27 PM, olcott wrote:
> On 7/23/2022 3:12 PM, Skep Dick wrote:
>> On Saturday, 23 July 2022 at 22:08:48 UTC+2, 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.
>>>
>>> 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.
>>>
>>> That you say that I am wrong entirely on the basis of your lack of
>>> understanding of the x86 language is dishonest and rude.
>>
>> That you say that it has been "conclusively proven", and that the
>> simulation is "correct" is entirely based on your opinion.
>>
>
> That you (and others) lack the technical skill to verify a fact does not
> actually logically entail that this fact has not been verified.
>
>

But the fact that you lack the skill to actually present a correct
verification of the fact, and since you claimed fact is actually wrong,
does impact that status.

Please list all the premises that you proof used, and the source that
you used to verify that they are true.

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).

Or don't you understand the question?

Note, that isn't even a trace, just an assembly listing with annotations.

You seem to be running dumber than normal.

Maybe you have forgotten what a Trace is.

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.

--
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 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?

We were talking about correct simulations (that also need to be
complete) that are usable as the basis for deciding Halting, which H
doesn't do.

All you are doing is proving that Halting isn't a computable function.

You seem to have a confusion about what H is ABLE to do, and what it is
REQUIRED to do to be a correct Halt Decider.

You claim is that the CORRECT SIMULATION of the input to H(P,P) differs
from the actual behavior of P(P).

H stopping its simulation does not introduce a difference in the
behavior. A CORRECT SIMULATION of that input, if it continues past the
point where H aborts its simulation, will continue to follow the
behavior of P(P) and WILL return to that instruction and show that P(P)
is Halting.

You just seem to be admitting that you aren't defining H to be a Halt
Decider, but are claiming a DIFFERENT mapping that it is "correctly"
computing.

On Saturday, 23 July 2022 at 22:51:24 UTC+2, 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.

That's a lie.

The path to 13d7 is obvious!

If 000013dd sets the zero flag 000013e5 jumps to 000013e5, and then 000013e7.

On Saturday, 23 July 2022 at 22:51:24 UTC+2, 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.

> >> [000013dd](04) 837dfc00 cmp dword [ebp-04],+00 // if check passes....
> >> [000013e1](02) 7402 jz 000013e5 // ...jump to 000013e5.
> >> [000013e3](02) ebfe jmp 000013e3 // Previous jz avoids this infinite loop....
> >> [000013e5](02) 8be5 mov esp,ebp // ...and lands here.
> >> [000013e7](01) 5d pop ebp // ...and then here.

Despite claims that "13d7 can't be reached".

On 7/23/22 5:00 PM, Skep Dick wrote:
> On Saturday, 23 July 2022 at 22:51:24 UTC+2, 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.
>
> That's a lie.
>
> The path to 13d7 is obvious!
>
> If 000013dd sets the zero flag 000013e5 jumps to 000013e5, and then 000013e7.
>
>

He is working on the fact that the simulation by *H* can't get there.

he is confusiong the PARTIAL simulation by H with an actual CORRECT AND
COMPLETE simulation that can be used as a substitute in the definition
of Halting.

He is just showing he doesn't understand what he is talking about.

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?

--
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 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. PERIOD.

Because you admit that there is a difference between the siulation by H
and the simulation by a correct and complete simulator so you can't use
the simulation by H as an alternative for the actual machine.

Since Halting is DEFINED based on the actual machine, and H is based on
something which you admit is different than the bahavior of the actual
machine, you are admitting that H is not computing the Halting Function.

There go decades down the drain. Wasted.

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.

--
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 Saturday, July 23, 2022 at 5:27:55 PM UTC-4, 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 agree with that then you necessarily agree with this:

Given Ha3 whose halt status criteria is running for no more that 3 steps, and given N(x) which runs for exactly x steps and exits:

It has been conclusively proven that the correctly simulated input to Ha3(N,5) correctly simulated by Ha3 cannot possibly reach its "return" instruction.

Agreed?

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?

Maybe you should shelve this point and get to the atomic bomb that has
destroyed your whole argument.

But, As I have said MANY times, yes, it is impossible to design an H
that can correct simulate this input to the return instruction, so yes,
H can not possible reach the return instruction in its own simulation of
the input, that as I have pointed out, that means NOTHING about the
Halting of the machine that input represents.

I suppose the one thing it says is that it is proven that H can never
actually prove this input halts, so if it only gives answers that it
claims to have proven, it can never say H(P,P) is 1.

A few points that need to be pointed out with your current glossery:

You are SPECIFICALLY specifying that Correct is distinct from Complete,
and thus Correct Simulations by themselves, never show non-halting.

Your definition of H is SPECIFIALLY admitted to be different than the
Halting Criteria, and in particular, you think that H(P,P) can correctly
say non-halting when P(P) is Halting even though that is the DEFINITION
of the correct answer for a Halt Decider.

If you want to try to patch a small hole in the bow of your sinking ship
when the stern of the boat is just missing, go ahead.

Just remember, you admit there is an issue to handle about H not being
actually a Halt Decider, so until that is resolved, it is a lie to call
it one.

I will point out that this is one of the classic tactics of a deciever,
to go off and focus on the weeds and ignore the big problems that they
know they can't handle.

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.

--
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 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.

Why put your focus on a stubbed toe when you are dying of appendicitis.

Your statement DOES admit that your H isn't a Halt Decider because you
admit its decision criteria doesn't match that of a Halt Decider.

PERIOD.

What else does admitting that the behavior of P(P) is NOT the actual
meaning of the input to the call of H(P,P) mean?

You are asking to validate your criterion measure.

If you mean H to be a Halting Decider, then the criteria you are asking
to validate isn't a valid criteria for a Halt Decider, so it doesn't
matter if H got the right answer to the wrong criteria.

You seem to have a fundamental problem about sticking to things that
actually produce truth.

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:

There is no implementation of the function H that can simulate the function call P(P) to a final state.

And this is true. And it has nothing to do with the halting problem. The halting problem is about algorithms, not C function.

For H(X,Y), in the case that the function X does not call the function H, the answer is the same answer as a halt decider. Specifically, if the implementation of H is replaced with a UTM and the input halts, then H answers 1.. This is no different from passing the input to a separate function called UTM.

When the function X does call the function H, then H gives a different answer from a halt decider. This is because changing the implementation of the function H indirectly changes the implementation of the function X. In other words, it's not deciding on the same thing.

The job of a halt decider is to map the halting function. This function includes the following mappings:

Pa(Pa) --> 1 (where Pa calls Ha)
Pn(Pn) --> 0 (where Pn calls Hn)
N(5) --> 1 (where N(x) runs for x steps and exits

And because a halt decider maps the halting function, it directly follows that the actual behavior of the actual input to a halt decider is that of the computation the input represents. i.e. if D is a halt decider, then the actual behavior of the actual input to D(x,y) is stipulated to be the behavior of x(y).

You claim that Ha(Pa,Pa)==0 is correct. This is contrary to the halting function. Therefore Ha does not map the halting function and is therefore not a halt decider.

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.

--
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 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.

--
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 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. The halting function maps Pa(Pa) to 1 Ha(Pa,Pa) maps to 0. Therefore Ha does not map the halting function and is therefore not a halt decider.

On Sat, 23 Jul 2022 17:54:15 -0500
olcott <NoOne@NoWhere.com> 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.