On Saturday, July 9, 2022 at 6:16:37 AM UTC-7, olcott wrote:
> On 7/8/2022 5:48 PM, olcott wrote:
> > On 7/8/2022 1:09 AM, dklei...@gmail.com wrote:
> >> On Thursday, July 7, 2022 at 9:48:17 PM UTC-7, olcott wrote:
> >>> On 7/7/2022 11:35 PM, dklei...@gmail.com wrote:
> >>>
> >>>> int Strachey_P(void) {
> >>>> if (T(&Strachey_P)) return 1;
> >>>> else return 0; }
> >>>>
> >>>> int main() {
> >>>> if (T(&Strachey_P)) Output("Halts");
> >>>> else Output ("Does not halt");}
> >>>>
> >>>> Without the definition of T this is just boiler plate.
> >>>
> >>> Yours is incorrect:
> >>
> >> How? I assume C89.
> >
> > typedef void (*ptr)();
> >
> > int Strachey_P2(void) {
> > if (T(&Strachey_P2)) return 1;
> > else return 0; }
> >
> > int main()
> > {
> > if (T(Strachey_P2)) OutputString("Halts\n");
> > else OutputString("Does not halt\n");
> > }
> >
> > _Strachey_P2()
> > [0000134e](01) 55 push ebp
> > [0000134f](02) 8bec mov ebp,esp
> > [00001351](05) 684e130000 push 0000134e
> > [00001356](05) e893fbffff call 00000eee
> > [0000135b](03) 83c404 add esp,+04
> > [0000135e](02) 85c0 test eax,eax
> > [00001360](02) 7409 jz 0000136b
> > [00001362](05) b801000000 mov eax,00000001
> > [00001367](02) eb04 jmp 0000136d
> > [00001369](02) eb02 jmp 0000136d
> > [0000136b](02) 33c0 xor eax,eax
> > [0000136d](01) 5d pop ebp
> > [0000136e](01) c3 ret
> > Size in bytes:(0033) [0000136e]
> >
> > _main()
> > [0000137e](01) 55 push ebp
> > [0000137f](02) 8bec mov ebp,esp
> > [00001381](05) 684e130000 push 0000134e
> > [00001386](05) e863fbffff call 00000eee
> > [0000138b](03) 83c404 add esp,+04
> > [0000138e](02) 85c0 test eax,eax
> > [00001390](02) 740f jz 000013a1
> > [00001392](05) 6817050000 push 00000517
> > [00001397](05) e8c2f1ffff call 0000055e
> > [0000139c](03) 83c404 add esp,+04
> > [0000139f](02) eb0d jmp 000013ae
> > [000013a1](05) 681f050000 push 0000051f
> > [000013a6](05) e8b3f1ffff call 0000055e
> > [000013ab](03) 83c404 add esp,+04
> > [000013ae](02) 33c0 xor eax,eax
> > [000013b0](01) 5d pop ebp
> > [000013b1](01) c3 ret
> > Size in bytes:(0052) [000013b1]
> >
> > machine stack stack machine assembly
> > address address data code language
> > ======== ======== ======== ========= =============
> > [0000137e][001022be][00000000] 55 push ebp
> > [0000137f][001022be][00000000] 8bec mov ebp,esp
> > [00001381][001022ba][0000134e] 684e130000 push 0000134e
> > [00001386][001022b6][0000138b] e863fbffff call 00000eee
> >
> > T: Begin Simulation Execution Trace Stored at:11236a
> > Address_of_T:eee
> > [0000134e][0011235a][0011235e] 55 push ebp
> > [0000134f][0011235a][0011235e] 8bec mov ebp,esp
> > [00001351][00112356][0000134e] 684e130000 push 0000134e
> > [00001356][00112352][0000135b] e893fbffff call 00000eee
> > T: Infinitely Recursive Simulation Detected Simulation Stopped
> >
> > [0000138b][001022be][00000000] 83c404 add esp,+04
> > [0000138e][001022be][00000000] 85c0 test eax,eax
> > [00001390][001022be][00000000] 740f jz 000013a1
> > [000013a1][001022ba][0000051f] 681f050000 push 0000051f
> > [000013a6][001022ba][0000051f] e8b3f1ffff call 0000055e
> > Does not halt
> > [000013ab][001022be][00000000] 83c404 add esp,+04
> > [000013ae][001022be][00000000] 33c0 xor eax,eax
> > [000013b0][001022c2][00000018] 5d pop ebp
> > [000013b1][001022c6][00000000] c3 ret
> > Number of Instructions Executed(539) == 8 Pages

As nearly as I can tell this is all what I called boilerplate. Essentially
no substantial content.

If you have a computer program that shows what you claim show
your complete code and we can check its validity. No programmer
is competent to pass a definitive judgement baout his own work.

On 7/9/22 9:16 AM, olcott wrote:
> On 7/8/2022 5:48 PM, olcott wrote:
>> On 7/8/2022 1:09 AM, dklei...@gmail.com wrote:
>>> On Thursday, July 7, 2022 at 9:48:17 PM UTC-7, olcott wrote:
>>>> On 7/7/2022 11:35 PM, dklei...@gmail.com wrote:
>>>>
>>>>> int Strachey_P(void) {
>>>>> if (T(&Strachey_P)) return 1;
>>>>> else return 0; }
>>>>>
>>>>> int main() {
>>>>> if (T(&Strachey_P)) Output("Halts");
>>>>> else Output ("Does not halt");}
>>>>>
>>>>> Without the definition of T this is just boiler plate.
>>>>
>>>> Yours is incorrect:
>>>
>>> How? I assume C89.
>>
>> typedef void (*ptr)();
>>
>> int Strachey_P2(void) {
>> if (T(&Strachey_P2)) return 1;
>> else return 0; }
>>
>> int main()
>> {
>>   if (T(Strachey_P2)) OutputString("Halts\n");
>>   else OutputString("Does not halt\n");
>> }
>>
>> _Strachey_P2()
>> [0000134e](01)  55         push ebp
>> [0000134f](02)  8bec       mov ebp,esp
>> [00001351](05)  684e130000 push 0000134e
>> [00001356](05)  e893fbffff call 00000eee
>> [0000135b](03)  83c404     add esp,+04
>> [0000135e](02)  85c0       test eax,eax
>> [00001360](02)  7409       jz 0000136b
>> [00001362](05)  b801000000 mov eax,00000001
>> [00001367](02)  eb04       jmp 0000136d
>> [00001369](02)  eb02       jmp 0000136d
>> [0000136b](02)  33c0       xor eax,eax
>> [0000136d](01)  5d         pop ebp
>> [0000136e](01)  c3         ret
>> Size in bytes:(0033) [0000136e]
>>
>> _main()
>> [0000137e](01)  55         push ebp
>> [0000137f](02)  8bec       mov ebp,esp
>> [00001381](05)  684e130000 push 0000134e
>> [00001386](05)  e863fbffff call 00000eee
>> [0000138b](03)  83c404     add esp,+04
>> [0000138e](02)  85c0       test eax,eax
>> [00001390](02)  740f       jz 000013a1
>> [00001392](05)  6817050000 push 00000517
>> [00001397](05)  e8c2f1ffff call 0000055e
>> [0000139c](03)  83c404     add esp,+04
>> [0000139f](02)  eb0d       jmp 000013ae
>> [000013a1](05)  681f050000 push 0000051f
>> [000013a6](05)  e8b3f1ffff call 0000055e
>> [000013ab](03)  83c404     add esp,+04
>> [000013ae](02)  33c0       xor eax,eax
>> [000013b0](01)  5d         pop ebp
>> [000013b1](01)  c3         ret
>> Size in bytes:(0052) [000013b1]
>>
>>   machine   stack     stack     machine    assembly
>>   address   address   data      code       language
>>   ========  ========  ========  =========  =============
>> [0000137e][001022be][00000000] 55         push ebp
>> [0000137f][001022be][00000000] 8bec       mov ebp,esp
>> [00001381][001022ba][0000134e] 684e130000 push 0000134e
>> [00001386][001022b6][0000138b] e863fbffff call 00000eee
>>
>> T: Begin Simulation   Execution Trace Stored at:11236a
>> Address_of_T:eee
>> [0000134e][0011235a][0011235e] 55         push ebp
>> [0000134f][0011235a][0011235e] 8bec       mov ebp,esp
>> [00001351][00112356][0000134e] 684e130000 push 0000134e
>> [00001356][00112352][0000135b] e893fbffff call 00000eee
>> T: Infinitely Recursive Simulation Detected Simulation Stopped
>>
>> [0000138b][001022be][00000000] 83c404     add esp,+04
>> [0000138e][001022be][00000000] 85c0       test eax,eax
>> [00001390][001022be][00000000] 740f       jz 000013a1
>> [000013a1][001022ba][0000051f] 681f050000 push 0000051f
>> [000013a6][001022ba][0000051f] e8b3f1ffff call 0000055e
>> Does not halt
>> [000013ab][001022be][00000000] 83c404     add esp,+04
>> [000013ae][001022be][00000000] 33c0       xor eax,eax
>> [000013b0][001022c2][00000018] 5d         pop ebp
>> [000013b1][001022c6][00000000] c3         ret
>> Number of Instructions Executed(539) == 8 Pages
>>
>
> *THIS IS IRREFUTABLY CORRECT*
> From a purely software engineering perspective T(Strachey_P) does
> correctly predict that its complete and correct x86 emulation of its
> input would never reach the "ret" instruction (final state) of this
> input, therefore T(Strachey_P) correctly rejects this input as non-halting.
>
>

Nope, because it CAN'T correctly predict that a (not its, since it
doens't do one) complete and correct x86 emulation of its input would
never reach the "ret" instruction, since if T does return "non-halting"
the input will be a Halting Computation.

If you stick to your "its", then the problem is ill defined, because if
T does abort its emulation, then the condition required (a complete
emulation of its input) is non-existant.

You can't ask about the properties of something that can't exist.

On 7/9/2022 12:22 PM, dklei...@gmail.com wrote:
> On Saturday, July 9, 2022 at 6:16:37 AM UTC-7, olcott wrote:
>> On 7/8/2022 5:48 PM, olcott wrote:
>>> On 7/8/2022 1:09 AM, dklei...@gmail.com wrote:
>>>> On Thursday, July 7, 2022 at 9:48:17 PM UTC-7, olcott wrote:
>>>>> On 7/7/2022 11:35 PM, dklei...@gmail.com wrote:
>>>>>
>>>>>> int Strachey_P(void) {
>>>>>> if (T(&Strachey_P)) return 1;
>>>>>> else return 0; }
>>>>>>
>>>>>> int main() {
>>>>>> if (T(&Strachey_P)) Output("Halts");
>>>>>> else Output ("Does not halt");}
>>>>>>
>>>>>> Without the definition of T this is just boiler plate.
>>>>>
>>>>> Yours is incorrect:
>>>>
>>>> How? I assume C89.
>>>
>>> typedef void (*ptr)();
>>>
>>> int Strachey_P2(void) {
>>> if (T(&Strachey_P2)) return 1;
>>> else return 0; }
>>>
>>> int main()
>>> {
>>> if (T(Strachey_P2)) OutputString("Halts\n");
>>> else OutputString("Does not halt\n");
>>> }
>>>
>>> _Strachey_P2()
>>> [0000134e](01) 55 push ebp
>>> [0000134f](02) 8bec mov ebp,esp
>>> [00001351](05) 684e130000 push 0000134e
>>> [00001356](05) e893fbffff call 00000eee
>>> [0000135b](03) 83c404 add esp,+04
>>> [0000135e](02) 85c0 test eax,eax
>>> [00001360](02) 7409 jz 0000136b
>>> [00001362](05) b801000000 mov eax,00000001
>>> [00001367](02) eb04 jmp 0000136d
>>> [00001369](02) eb02 jmp 0000136d
>>> [0000136b](02) 33c0 xor eax,eax
>>> [0000136d](01) 5d pop ebp
>>> [0000136e](01) c3 ret
>>> Size in bytes:(0033) [0000136e]
>>>
>>> _main()
>>> [0000137e](01) 55 push ebp
>>> [0000137f](02) 8bec mov ebp,esp
>>> [00001381](05) 684e130000 push 0000134e
>>> [00001386](05) e863fbffff call 00000eee
>>> [0000138b](03) 83c404 add esp,+04
>>> [0000138e](02) 85c0 test eax,eax
>>> [00001390](02) 740f jz 000013a1
>>> [00001392](05) 6817050000 push 00000517
>>> [00001397](05) e8c2f1ffff call 0000055e
>>> [0000139c](03) 83c404 add esp,+04
>>> [0000139f](02) eb0d jmp 000013ae
>>> [000013a1](05) 681f050000 push 0000051f
>>> [000013a6](05) e8b3f1ffff call 0000055e
>>> [000013ab](03) 83c404 add esp,+04
>>> [000013ae](02) 33c0 xor eax,eax
>>> [000013b0](01) 5d pop ebp
>>> [000013b1](01) c3 ret
>>> Size in bytes:(0052) [000013b1]
>>>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> [0000137e][001022be][00000000] 55 push ebp
>>> [0000137f][001022be][00000000] 8bec mov ebp,esp
>>> [00001381][001022ba][0000134e] 684e130000 push 0000134e
>>> [00001386][001022b6][0000138b] e863fbffff call 00000eee
>>>
>>> T: Begin Simulation Execution Trace Stored at:11236a
>>> Address_of_T:eee
>>> [0000134e][0011235a][0011235e] 55 push ebp
>>> [0000134f][0011235a][0011235e] 8bec mov ebp,esp
>>> [00001351][00112356][0000134e] 684e130000 push 0000134e
>>> [00001356][00112352][0000135b] e893fbffff call 00000eee
>>> T: Infinitely Recursive Simulation Detected Simulation Stopped
>>>
>>> [0000138b][001022be][00000000] 83c404 add esp,+04
>>> [0000138e][001022be][00000000] 85c0 test eax,eax
>>> [00001390][001022be][00000000] 740f jz 000013a1
>>> [000013a1][001022ba][0000051f] 681f050000 push 0000051f
>>> [000013a6][001022ba][0000051f] e8b3f1ffff call 0000055e
>>> Does not halt
>>> [000013ab][001022be][00000000] 83c404 add esp,+04
>>> [000013ae][001022be][00000000] 33c0 xor eax,eax
>>> [000013b0][001022c2][00000018] 5d pop ebp
>>> [000013b1][001022c6][00000000] c3 ret
>>> Number of Instructions Executed(539) == 8 Pages
>
> As nearly as I can tell this is all what I called boilerplate. Essentially
> no substantial content.
>
> If you have a computer program that shows what you claim show
> your complete code and we can check its validity. No programmer
> is competent to pass a definitive judgement baout his own work.

The above execution trace of simulating halt decider T(Strachey_P2)
proves that T correctly predicts that its correct and complete x86
emulation of its input would never reach the "ret" instruction of this
input. This allows T to correctly reject Strachey_P2 as non-halting.

Anyone having these required prerequisites can verify the above
paragraph without seeing the source-code.

To fully understand this paper a software engineer must be an expert in:
(a) The C programming language.
(b) The x86 programming language.
(c) Exactly how C translates into x86 (how C function calls are
implemented in x86).
(d) The ability to recognize infinite recursion at the x86 assembly
language level.

Anyone not having these required prerequisites will not be able to
verify the above paragraph even after seeing the source-code because
they will not be able to understand what the halt decider is doing
unless they know the x86 language quite well.

The code requires more refactoring before it is clean enough for
publication.

I updated the original x86 emulator so that
(1) It compiles under Windows as well as Linux. 16390 source-code lines.

(2) One of its original functions can disassemble or simulate its input
depending on a boolean flag.

(3) The COFF output of the the Microsoft C compiler can be directly
executed. (contained in Read_COFF_Object.h). 924 source-code lines.

The x86utm operation system is in x86utm.cpp
2038 source-code lines.

The various halt deciders and their sample input is in Halt7.c
638 source-code lines.

--
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/9/22 2:40 PM, olcott wrote:
> On 7/9/2022 12:22 PM, dklei...@gmail.com wrote:
>> On Saturday, July 9, 2022 at 6:16:37 AM UTC-7, olcott wrote:
>>> On 7/8/2022 5:48 PM, olcott wrote:
>>>> On 7/8/2022 1:09 AM, dklei...@gmail.com wrote:
>>>>> On Thursday, July 7, 2022 at 9:48:17 PM UTC-7, olcott wrote:
>>>>>> On 7/7/2022 11:35 PM, dklei...@gmail.com wrote:
>>>>>>
>>>>>>> int Strachey_P(void) {
>>>>>>> if (T(&Strachey_P)) return 1;
>>>>>>> else return 0; }
>>>>>>>
>>>>>>> int main() {
>>>>>>> if (T(&Strachey_P)) Output("Halts");
>>>>>>> else Output ("Does not halt");}
>>>>>>>
>>>>>>> Without the definition of T this is just boiler plate.
>>>>>>
>>>>>> Yours is incorrect:
>>>>>
>>>>> How? I assume C89.
>>>>
>>>> typedef void (*ptr)();
>>>>
>>>> int Strachey_P2(void) {
>>>> if (T(&Strachey_P2)) return 1;
>>>> else return 0; }
>>>>
>>>> int main()
>>>> {
>>>>   if (T(Strachey_P2)) OutputString("Halts\n");
>>>>   else OutputString("Does not halt\n");
>>>> }
>>>>
>>>> _Strachey_P2()
>>>> [0000134e](01)  55         push ebp
>>>> [0000134f](02)  8bec       mov ebp,esp
>>>> [00001351](05)  684e130000 push 0000134e
>>>> [00001356](05)  e893fbffff call 00000eee
>>>> [0000135b](03)  83c404     add esp,+04
>>>> [0000135e](02)  85c0       test eax,eax
>>>> [00001360](02)  7409       jz 0000136b
>>>> [00001362](05)  b801000000 mov eax,00000001
>>>> [00001367](02)  eb04       jmp 0000136d
>>>> [00001369](02)  eb02       jmp 0000136d
>>>> [0000136b](02)  33c0       xor eax,eax
>>>> [0000136d](01)  5d         pop ebp
>>>> [0000136e](01)  c3         ret
>>>> Size in bytes:(0033) [0000136e]
>>>>
>>>> _main()
>>>> [0000137e](01)  55         push ebp
>>>> [0000137f](02)  8bec       mov ebp,esp
>>>> [00001381](05)  684e130000 push 0000134e
>>>> [00001386](05)  e863fbffff call 00000eee
>>>> [0000138b](03)  83c404     add esp,+04
>>>> [0000138e](02)  85c0       test eax,eax
>>>> [00001390](02)  740f       jz 000013a1
>>>> [00001392](05)  6817050000 push 00000517
>>>> [00001397](05)  e8c2f1ffff call 0000055e
>>>> [0000139c](03)  83c404     add esp,+04
>>>> [0000139f](02)  eb0d       jmp 000013ae
>>>> [000013a1](05)  681f050000 push 0000051f
>>>> [000013a6](05)  e8b3f1ffff call 0000055e
>>>> [000013ab](03)  83c404     add esp,+04
>>>> [000013ae](02)  33c0       xor eax,eax
>>>> [000013b0](01)  5d         pop ebp
>>>> [000013b1](01)  c3         ret
>>>> Size in bytes:(0052) [000013b1]
>>>>
>>>>   machine   stack     stack     machine    assembly
>>>>   address   address   data      code       language
>>>>   ========  ========  ========  =========  =============
>>>> [0000137e][001022be][00000000] 55         push ebp
>>>> [0000137f][001022be][00000000] 8bec       mov ebp,esp
>>>> [00001381][001022ba][0000134e] 684e130000 push 0000134e
>>>> [00001386][001022b6][0000138b] e863fbffff call 00000eee
>>>>
>>>> T: Begin Simulation   Execution Trace Stored at:11236a
>>>> Address_of_T:eee
>>>> [0000134e][0011235a][0011235e] 55         push ebp
>>>> [0000134f][0011235a][0011235e] 8bec       mov ebp,esp
>>>> [00001351][00112356][0000134e] 684e130000 push 0000134e
>>>> [00001356][00112352][0000135b] e893fbffff call 00000eee
>>>> T: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>
>>>> [0000138b][001022be][00000000] 83c404     add esp,+04
>>>> [0000138e][001022be][00000000] 85c0       test eax,eax
>>>> [00001390][001022be][00000000] 740f       jz 000013a1
>>>> [000013a1][001022ba][0000051f] 681f050000 push 0000051f
>>>> [000013a6][001022ba][0000051f] e8b3f1ffff call 0000055e
>>>> Does not halt
>>>> [000013ab][001022be][00000000] 83c404     add esp,+04
>>>> [000013ae][001022be][00000000] 33c0       xor eax,eax
>>>> [000013b0][001022c2][00000018] 5d         pop ebp
>>>> [000013b1][001022c6][00000000] c3         ret
>>>> Number of Instructions Executed(539) == 8 Pages
>>
>> As nearly as I can tell this is all what I called boilerplate.
>> Essentially
>> no substantial content.
>>
>> If you have a computer program that shows what  you claim show
>> your complete code and we can check its validity. No programmer
>> is competent to pass a definitive judgement baout his own work.
>
> The above execution trace of simulating halt decider T(Strachey_P2)
> proves that T correctly predicts that its correct and complete x86
> emulation of its input would never reach the "ret" instruction of this
> input. This allows T to correctly reject Strachey_P2 as non-halting.
>
> Anyone having these required prerequisites can verify the above
> paragraph without seeing the source-code.
>
> To fully understand this paper a software engineer must be an expert in:
> (a) The C programming language.
> (b) The x86 programming language.
> (c) Exactly how C translates into x86 (how C function calls are
> implemented in x86).
> (d) The ability to recognize infinite recursion at the x86 assembly
> language level.
>
> Anyone not having these required prerequisites will not be able to
> verify the above paragraph even after seeing the source-code because
> they will not be able to understand what the halt decider is doing
> unless they know the x86 language quite well.
>
>
>
> The code requires more refactoring before it is clean enough for
> publication.
>
> I updated the original x86 emulator so that
> (1) It compiles under Windows as well as Linux. 16390 source-code lines.
>
> (2) One of its original functions can disassemble or simulate its input
> depending on a boolean flag.
>
> (3) The COFF output of the the Microsoft C compiler can be directly
> executed. (contained in Read_COFF_Object.h). 924 source-code lines.
>
> The x86utm operation system is in x86utm.cpp
> 2038 source-code lines.
>
> The various halt deciders and their sample input is in Halt7.c
> 638 source-code lines.
>

No, your system is broken.

T(x) is shown to either be incorrect in the case of x = Strachey_P2 or
that T isn't actually the claimed pure function.

The likely error is that it does the incorrect assuption that when
Strachey_P2 calls T(&Strachey_P2) that it assumes that this T will not
aborts its own emultion of its input, when it is shown that T will.

Thus, either T is incorrect about the behavior of this T, or T actually
does have different behavior when deciding on this input, and thus is
proved not to be an actual computation aka a Pure Function.

Note, your claim that T(&Strachey_P2) not reflecting the behavior of
Strachey_P2() just shows that something is defined incorrectly, since
that is how YOU have defined Strachey_P2 to ask exactly that question.

Simple inspection sees that this is true, as if we use the knowledge
that T(&Strachey_P2) returns 0 as claimed, and that T is a pure function
so ALWAYS behaves the same for the same input, then Strachey_P2 must
call T(Strachey_P2), get that 0 return, at which point it will return 1.

The ONLY way for Strachey_P2 to be non-halting is if T is non-halting
(easily provable since Strachey_P2 has NO instructions that don't
progress farther except for inside T) and thus for T to say Strachey_P2
is non-halting is to say that in some condition T is non-halting and
thus fails to meet its requirements.

Richard Damon <Richard@Damon-Family.org> Wrote in message:r
> On 7/2/22 11:34 AM, olcott wrote:> This much more concise version of my paper focuses on the actual> execution of three fully operational examples.> > H0 correctly determines that Infinite_Loop() never halts> H correctly determines that Infinite_Recursion() never halts> H correctly determines that P() never haltsExcept that if H(P,P) actually returns 0, then P(P) will halt, so H is wrong.You can't just define the wrong answer to be right. And, your dishonest dodge that H(P,P) doesn't actually refer to P(P) says that P isn't the program you claim, as the P is DEFINED to ask H about ITSELF with its input, so if H(P,P) doesn't mean that, then you have defined something wrong.The problem is your logic doesn't actually correctly consider the behavior of the H being called, so doesn't actually do a correct x86 emulation of its input.> > void P(u32 x)> {> if (H(x, x))> HERE: goto HERE;> return;> }> > int main()> {> Output("Input_Halts = ", H((u32)P, (u32)P));> }> > As shown below the above P and H have the required (halting problem) > pathological relationship to each other:> > 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> > I really need software engineers to verify that H does correctly predict > that its complete and correct x86 emulation of its input would never > reach the "ret" instruction of this input.> > *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 > >

You are simply not bright enough to understand that every function
called (what is essentially) infinite never returns any value to
it's caller.

--

----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html

On Saturday, 2 July 2022 at 23:34:42 UTC+8, olcott wrote:

> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }

Try this main(), tell us what is the result.

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

On 7/12/22 12:34 PM, olcott wrote:
> Richard Damon <Richard@Damon-Family.org> Wrote in message:r
>> On 7/2/22 11:34 AM, olcott wrote:> This much more concise version of my paper focuses on the actual> execution of three fully operational examples.> > H0 correctly determines that Infinite_Loop() never halts> H correctly determines that Infinite_Recursion() never halts> H correctly determines that P() never haltsExcept that if H(P,P) actually returns 0, then P(P) will halt, so H is wrong.You can't just define the wrong answer to be right. And, your dishonest dodge that H(P,P) doesn't actually refer to P(P) says that P isn't the program you claim, as the P is DEFINED to ask H about ITSELF with its input, so if H(P,P) doesn't mean that, then you have defined something wrong.The problem is your logic doesn't actually correctly consider the behavior of the H being called, so doesn't actually do a correct x86 emulation of its input.> > void P(u32 x)> {> if (H(x, x))> HERE: goto HERE;> return;> }> > int main()> {> Output("Input_Halts = ", H((u32)P, (u32)P));> }> > As shown below the above P and H have the required (halting problem) > pathological relationship to each other:> > 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> > I really need software engineers to verify that H does correctly predict > that its complete and correct x86 emulation of its input would never > reach the "ret" instruction of this input.> > *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 > >
>
> You are simply not bright enough to understand that every function
> called (what is essentially) infinite never returns any value to
> it's caller.
>
And you seem to think that what at first seems to be infinite recursion,
might not be because H is "smart" enough to abort its simulation, but
not smart enough to understand that the H that P/D calls will too.
Since one copy of H does this, all copies will, or H isn't a
computation/pure function.
Tht, or H is just plain incorrect about what its input does, because it
uses incorrect logic about what copies of it does (since in never
actually sees what those copies will do).

On 7/12/2022 11:56 AM, wij wrote:
> On Saturday, 2 July 2022 at 23:34:42 UTC+8, olcott wrote:
>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>
> Try this main(), tell us what is the result.
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> P((u32)P);
> }

*CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*

I rewrote this question so that a software engineer of ordinary skill
can easily verify that the simulated P does call H in what is
essentially infinite recursion. **This simplification is the result of
an extensive review (23 emails) by a leading computer scientist over the
weekend.**

Does H(P,P) correctly determine the halt status of the halting problem's
pathological input?

> 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

The following H and P have the above specified pathological relationship
to each other.

typedef void (*ptr)();
int H(ptr p, ptr i);

void P(ptr x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

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

Simulating halt decider H detects that its simulated input is
essentially calling H in infinite recursion. H aborts its simulation on
this basis and rejects this input as non-halting.

*Once this halt deciding principle is accepted*
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

*Then (by logical necessity) this is understood to implement that*
Every simulating halt decider that correctly simulates its input until
it correctly predicts that this simulated input would never terminate
normally, correctly rejects this input as non-halting.

*The execution trace of function P() simulated by function H() shows*
(1) Function H() is called from P().<br>
(2) With the same parameters to H().<br>
(3) With no instructions in P() that could possibly escape this
infinitely recursive simulation.<br>

This proves that H(P,P) correctly predicts that its correctly simulated
input would never terminate normally.

--
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/12/22 11:15 PM, olcott wrote:
> On 7/12/2022 11:56 AM, wij wrote:
>> On Saturday, 2 July 2022 at 23:34:42 UTC+8, olcott wrote:
>>
>>> void P(u32 x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>
>> Try this main(), tell us what is the result.
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>   P((u32)P);
>> }
>
>
> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
>
> I rewrote this question so that a software engineer of ordinary skill
> can easily verify that the simulated P does call H in what is
> essentially infinite recursion. **This simplification is the result of
> an extensive review (23 emails) by a leading computer scientist over the
> weekend.**
>
> Does H(P,P) correctly determine the halt status of the halting problem's
> pathological input?
>
> > 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
>
> The following H and P have the above specified pathological relationship
> to each other.
>
> typedef void (*ptr)();
> int H(ptr p, ptr i);
>
> void P(ptr x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> Simulating halt decider H detects that its simulated input is
> essentially calling H in infinite recursion. H aborts its simulation on
> this basis and rejects this input as non-halting.
>
> *Once this halt deciding principle is accepted*
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
>
> *Then (by logical necessity) this is understood to implement that*
> Every simulating halt decider that correctly simulates its input until
> it correctly predicts that this simulated input would never terminate
> normally, correctly rejects this input as non-halting.
>
> *The execution trace of function P() simulated by function H() shows*
> (1) Function H() is called from P().<br>
> (2) With the same parameters to H().<br>
> (3) With no instructions in P() that could possibly escape this
> infinitely recursive simulation.<br>
>
> This proves that H(P,P) correctly predicts that its correctly simulated
> input would never terminate normally.
>
>

And P(P) will Halt if H(P,P) returns 0. That is OBVIOUS by just looking
at the code.

Again, your problem is rule (3) is incorrect, the instruction that stops
the loop doesn't need to be in the "C" function P, but just in the
program P, in the code executed as part of the algroithm that includes H
(and everything H calls), and the break is there, at least if H(P,P)
does return 0.

You mind has TWO difffernt H's in existance, which just can't be true.

H EITHER does a complete simulation (which causes the infinite recursion
that you claim, but doesn't answer) or H decides (incorrectly) to abort
because it thinks there is the infinite recursion based on H not
aborting, but that by actually doing the abort it has removed.

Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.

On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
>
> I rewrote this question so that a software engineer of ordinary skill
> can easily verify that the simulated P does call H in what is
> essentially infinite recursion. **This simplification is the result of
> an extensive review (23 emails) by a leading computer scientist over the
> weekend.**

> Does H(P,P) correctly determine the halt status of the halting problem's
> pathological input?

> The following H and P have the above specified pathological relationship
> to each other.
>
> typedef void (*ptr)();
> int H(ptr p, ptr i);
>
> void P(ptr x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
>
> Simulating halt decider H detects that its simulated input is
> essentially calling H in infinite recursion. H aborts its simulation on
> this basis and rejects this input as non-halting.

Thus it is an incorrect assessment, as we'll see below.

> *Once this halt deciding principle is accepted*
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.

Again, emphasis on "actual behaviour".

> *Then (by logical necessity) this is understood to implement that*
> Every simulating halt decider that correctly simulates its input until
> it correctly predicts that this simulated input would never terminate
> normally, correctly rejects this input as non-halting.

You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.

> *The execution trace of function P() simulated by function H() shows*
> (1) Function H() is called from P().
> (2) With the same parameters to H().
> (3) With no instructions in P() that could possibly escape this
> infinitely recursive simulation.

Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.

> This proves that H(P,P) correctly predicts that its correctly simulated
> input would never terminate normally.

As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.

To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:

A) H(P, P) returns 0 and P(P) terminates.
B) H(P, P) returns non-zero and P(P) terminates.
C) H(P, P) returns 0 and P(P) does not terminate.
D) H(P, P) returns non-zero and P(P) does not terminate.

B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.

On 7/13/2022 10:02 AM, Paul N wrote:
> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.
>
> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
>>
>> I rewrote this question so that a software engineer of ordinary skill
>> can easily verify that the simulated P does call H in what is
>> essentially infinite recursion. **This simplification is the result of
>> an extensive review (23 emails) by a leading computer scientist over the
>> weekend.**
>
>> Does H(P,P) correctly determine the halt status of the halting problem's
>> pathological input?
>
>> The following H and P have the above specified pathological relationship
>> to each other.
>>
>> typedef void (*ptr)();
>> int H(ptr p, ptr i);
>>
>> void P(ptr x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(P, P));
>> }
>>
>> Simulating halt decider H detects that its simulated input is
>> essentially calling H in infinite recursion. H aborts its simulation on
>> this basis and rejects this input as non-halting.
>
> Thus it is an incorrect assessment, as we'll see below.
>
>> *Once this halt deciding principle is accepted*
>> A halt decider must compute the mapping from its inputs to an accept or
>> reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>
> Again, emphasis on "actual behaviour".
>
>> *Then (by logical necessity) this is understood to implement that*
>> Every simulating halt decider that correctly simulates its input until
>> it correctly predicts that this simulated input would never terminate
>> normally, correctly rejects this input as non-halting.
>
> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
>
>> *The execution trace of function P() simulated by function H() shows*
>> (1) Function H() is called from P().
>> (2) With the same parameters to H().
>> (3) With no instructions in P() that could possibly escape this
>> infinitely recursive simulation.
>
> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
>
>> This proves that H(P,P) correctly predicts that its correctly simulated
>> input would never terminate normally.
>
> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.

Welcome back.

When H(P,P) correctly simulates its input this is the ultimate measure
of the actual behavior specified by this input.

A security guard at the front door is only required to validate people
coming in the front door the actual behavior of the actual input to H(P,P).

This same security guard is not required to validate people coming in
the back door the direct execution of P(P). Unless a computation is
specified as an actual input to H it is not in the domain of the
computable function that H implements.

>
> To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:
>
> A) H(P, P) returns 0 and P(P) terminates.
> B) H(P, P) returns non-zero and P(P) terminates.
> C) H(P, P) returns 0 and P(P) does not terminate.
> D) H(P, P) returns non-zero and P(P) does not terminate.
>
> B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.

A1) H(P, P) returns 0 because it correctly determines that the input
that it correctly simulates would never terminate normally.

A2) Directly executed P(P) halts because of (A)

--
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 Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
> On 7/13/2022 10:02 AM, Paul N wrote:
> > Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.
> >
> > On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
> >> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
> >>
> >> I rewrote this question so that a software engineer of ordinary skill
> >> can easily verify that the simulated P does call H in what is
> >> essentially infinite recursion. **This simplification is the result of
> >> an extensive review (23 emails) by a leading computer scientist over the
> >> weekend.**
> >
> >> Does H(P,P) correctly determine the halt status of the halting problem's
> >> pathological input?
> >
> >> The following H and P have the above specified pathological relationship
> >> to each other.
> >>
> >> typedef void (*ptr)();
> >> int H(ptr p, ptr i);
> >>
> >> void P(ptr x)
> >> {
> >> if (H(x, x))
> >> HERE: goto HERE;
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H(P, P));
> >> }
> >>
> >> Simulating halt decider H detects that its simulated input is
> >> essentially calling H in infinite recursion. H aborts its simulation on
> >> this basis and rejects this input as non-halting.
> >
> > Thus it is an incorrect assessment, as we'll see below.
> >
> >> *Once this halt deciding principle is accepted*
> >> A halt decider must compute the mapping from its inputs to an accept or
> >> reject state on the basis of the actual behavior that is actually
> >> specified by these inputs.
> >
> > Again, emphasis on "actual behaviour".
> >
> >> *Then (by logical necessity) this is understood to implement that*
> >> Every simulating halt decider that correctly simulates its input until
> >> it correctly predicts that this simulated input would never terminate
> >> normally, correctly rejects this input as non-halting.
> >
> > You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
> >
> >> *The execution trace of function P() simulated by function H() shows*
> >> (1) Function H() is called from P().
> >> (2) With the same parameters to H().
> >> (3) With no instructions in P() that could possibly escape this
> >> infinitely recursive simulation.
> >
> > Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
> >
> >> This proves that H(P,P) correctly predicts that its correctly simulated
> >> input would never terminate normally.
> >
> > As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.
> Welcome back.
>
> When H(P,P) correctly simulates its input this is the ultimate measure
> of the actual behavior specified by this input.

No, the actual behaviour is the actual behaviour! If H correctlky simulates this behaviour then it too will also be the same, but you have siad numerous times that it does not correctly simulate the behavoutr.

> A security guard at the front door is only required to validate people
> coming in the front door the actual behavior of the actual input to H(P,P).
>
> This same security guard is not required to validate people coming in
> the back door the direct execution of P(P). Unless a computation is
> specified as an actual input to H it is not in the domain of the
> computable function that H implements.

H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.

If a program M would halt given input X, then H(M, X) is required to be non-zero.
If a program M would not halt given input X, then H(M, X) is required to be zero.

If for some combination M, X the function H(M, X) gives the wrong answer, then it is not a halt decider. If particular, if H(M, X) = 0 but M(X) does halt, then the answer is wrong. You can't get out of it by arguing that M(X) is "direct" and H(M, X) is a "correct simulation", whatever that might mean. The answer needs to relate to the actual behaviour, as you yourself have said numerous times.

Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does not halt, H(P, P) is required to be zero. Anything else is the wrong answer.

When we calculate H(P, P), we are supplying P as the first argument and so P is specified as an actual input to H. And we are interested in the actual behaviour of P, the actual input. There is no "back door" by which you can say that P(P) is not the function and input we are talking about.

> > To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:
> >
> > A) H(P, P) returns 0 and P(P) terminates.
> > B) H(P, P) returns non-zero and P(P) terminates.
> > C) H(P, P) returns 0 and P(P) does not terminate.
> > D) H(P, P) returns non-zero and P(P) does not terminate.
> >
> > B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.

> A1) H(P, P) returns 0 because it correctly determines that the input
> that it correctly simulates would never terminate normally.

No, that is not a correct answer. You have said numerous times that P(P) terminates.

> A2) Directly executed P(P) halts because of (A)

On 7/13/2022 1:03 PM, Paul N wrote:
> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
>> On 7/13/2022 10:02 AM, Paul N wrote:
>>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.
>>>
>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
>>>>
>>>> I rewrote this question so that a software engineer of ordinary skill
>>>> can easily verify that the simulated P does call H in what is
>>>> essentially infinite recursion. **This simplification is the result of
>>>> an extensive review (23 emails) by a leading computer scientist over the
>>>> weekend.**
>>>
>>>> Does H(P,P) correctly determine the halt status of the halting problem's
>>>> pathological input?
>>>
>>>> The following H and P have the above specified pathological relationship
>>>> to each other.
>>>>
>>>> typedef void (*ptr)();
>>>> int H(ptr p, ptr i);
>>>>
>>>> void P(ptr x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H(P, P));
>>>> }
>>>>
>>>> Simulating halt decider H detects that its simulated input is
>>>> essentially calling H in infinite recursion. H aborts its simulation on
>>>> this basis and rejects this input as non-halting.
>>>
>>> Thus it is an incorrect assessment, as we'll see below.
>>>
>>>> *Once this halt deciding principle is accepted*
>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>> reject state on the basis of the actual behavior that is actually
>>>> specified by these inputs.
>>>
>>> Again, emphasis on "actual behaviour".
>>>
>>>> *Then (by logical necessity) this is understood to implement that*
>>>> Every simulating halt decider that correctly simulates its input until
>>>> it correctly predicts that this simulated input would never terminate
>>>> normally, correctly rejects this input as non-halting.
>>>
>>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
>>>
>>>> *The execution trace of function P() simulated by function H() shows*
>>>> (1) Function H() is called from P().
>>>> (2) With the same parameters to H().
>>>> (3) With no instructions in P() that could possibly escape this
>>>> infinitely recursive simulation.
>>>
>>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
>>>
>>>> This proves that H(P,P) correctly predicts that its correctly simulated
>>>> input would never terminate normally.
>>>
>>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.
>> Welcome back.
>>
>> When H(P,P) correctly simulates its input this is the ultimate measure
>> of the actual behavior specified by this input.
>
> No, the actual behaviour is the actual behaviour! If H correctlky simulates this behaviour then it too will also be the same, but you have siad numerous times that it does not correctly simulate the behavoutr.
>

It is an easily verified fact that H(P,P) correctly simulates its input
to everyone having sufficient knowledge of the x86 assembly language
which currently seems to be hardy no one besides me. Back in the 1986
when I began my career about 10% of all programmers had familiarity
with the x86 language. This is the language that MSDOS and versions
of MS Windows prior to Windows NT were written in. Windows NT switched
to mostly C/C++.

The 23 emails that I had with a leading computer scientist made that
very clear. Because of this I re-framed my explanation so that any
expert C programmer that totally understands infinite recursion would be
able to see that infinitely nested simulation is essentially the same
thing.

The next important point that requires one to have top software
engineering skills that allowed me to transform H into a pure thus
computable function: Infinitely nested simulation can be detected the
first time that the simulated input calls the simulator with its same
arguments. Infinite recursion requires seeing two such calls in a row.
This change allowed me to discard the need for static local memory and
do everything in local memory.

>> A security guard at the front door is only required to validate people
>> coming in the front door the actual behavior of the actual input to H(P,P).
>>
>> This same security guard is not required to validate people coming in
>> the back door the direct execution of P(P). Unless a computation is
>> specified as an actual input to H it is not in the domain of the
>> computable function that H implements.
>
> H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.

No this a very long standing misconception. H is required to determine
whether or not its correct simulation of its input would ever reach the
normal termination of this input.

Since no one ever bothered to think through the application of a
simulating halt decider to the HP's impossible inputs they always stated
the requirements incorrectly never realizing their mistake.

A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

In the H/P concrete example it is easily proven that the actual behavior
of the actual input to H(P,P) is not the behavior of the directly
executed P(P). The best proof of this is the x86 execution trace of each
that precisely corresponds to what the x86 source code of P specifies.

From this is is obvious that the correctly simulated P cannot possibly
terminate normally and the executed P(P) halts.

Those lacking knowledge of the x86 language can understand that this
first halt deciding principle is necessarily correct:

*When this halt deciding principle understood to be correct*
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

And this second halt deciding principle follows from the first one by
logical necessity.

*Then (by logical necessity) this implements that principle*
Every simulating halt decider that correctly simulates its input until
it correctly predicts that this simulated input would never terminate
normally, correctly rejects this input as non-halting.

>
> If a program M would halt given input X, then H(M, X) is required to be non-zero.
> If a program M would not halt given input X, then H(M, X) is required to be zero.
>

This is a misconception that can only be true if the halt decider is
required to report on something besides the actual behavior of its
actual input.

The ultimate measure of the actual behavior of the actual input is the
provable correct simulation of this input by the simulating halt decider.

To assume that this behavior must be the same as the directly executed
P(P) after it has been conclusively proven to not be that same as an
established fact is at least a little nutty.

That people unequivocally state that I must be wrong entirely on the
basis that they lack sufficient understanding of the x86 language to
understand my proof is a worst case example of the ad ignorantiam logic
error.

> If for some combination M, X the function H(M, X) gives the wrong answer, then it is not a halt decider. If particular, if H(M, X) = 0 but M(X) does halt, then the answer is wrong. You can't get out of it by arguing that M(X) is "direct" and H(M, X) is a "correct simulation", whatever that might mean. The answer needs to relate to the actual behaviour, as you yourself have said numerous times.
>
> Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does not halt, H(P, P) is required to be zero. Anything else is the wrong answer.
>
> When we calculate H(P, P), we are supplying P as the first argument and so P is specified as an actual input to H. And we are interested in the actual behaviour of P, the actual input. There is no "back door" by which you can say that P(P) is not the function and input we are talking about.
>
>>> To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:
>>>
>>> A) H(P, P) returns 0 and P(P) terminates.
>>> B) H(P, P) returns non-zero and P(P) terminates.
>>> C) H(P, P) returns 0 and P(P) does not terminate.
>>> D) H(P, P) returns non-zero and P(P) does not terminate.
>>>
>>> B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.
>
>> A1) H(P, P) returns 0 because it correctly determines that the input
>> that it correctly simulates would never terminate normally.
>
> No, that is not a correct answer. You have said numerous times that P(P) terminates.
>
>> A2) Directly executed P(P) halts because of (A)

On Thursday, 14 July 2022 at 03:37:13 UTC+8, olcott wrote:
> On 7/13/2022 1:03 PM, Paul N wrote:
> > On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
> >> On 7/13/2022 10:02 AM, Paul N wrote:
> >>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.
> >>>
> >>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
> >>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
> >>>>
> >>>> I rewrote this question so that a software engineer of ordinary skill
> >>>> can easily verify that the simulated P does call H in what is
> >>>> essentially infinite recursion. **This simplification is the result of
> >>>> an extensive review (23 emails) by a leading computer scientist over the
> >>>> weekend.**
> >>>
> >>>> Does H(P,P) correctly determine the halt status of the halting problem's
> >>>> pathological input?
> >>>
> >>>> The following H and P have the above specified pathological relationship
> >>>> to each other.
> >>>>
> >>>> typedef void (*ptr)();
> >>>> int H(ptr p, ptr i);
> >>>>
> >>>> void P(ptr x)
> >>>> {
> >>>> if (H(x, x))
> >>>> HERE: goto HERE;
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H(P, P));
> >>>> }
> >>>>
> >>>> Simulating halt decider H detects that its simulated input is
> >>>> essentially calling H in infinite recursion. H aborts its simulation on
> >>>> this basis and rejects this input as non-halting.
> >>>
> >>> Thus it is an incorrect assessment, as we'll see below.
> >>>
> >>>> *Once this halt deciding principle is accepted*
> >>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>> reject state on the basis of the actual behavior that is actually
> >>>> specified by these inputs.
> >>>
> >>> Again, emphasis on "actual behaviour".
> >>>
> >>>> *Then (by logical necessity) this is understood to implement that*
> >>>> Every simulating halt decider that correctly simulates its input until
> >>>> it correctly predicts that this simulated input would never terminate
> >>>> normally, correctly rejects this input as non-halting.
> >>>
> >>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
> >>>
> >>>> *The execution trace of function P() simulated by function H() shows*
> >>>> (1) Function H() is called from P().
> >>>> (2) With the same parameters to H().
> >>>> (3) With no instructions in P() that could possibly escape this
> >>>> infinitely recursive simulation.
> >>>
> >>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up.. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
> >>>
> >>>> This proves that H(P,P) correctly predicts that its correctly simulated
> >>>> input would never terminate normally.
> >>>
> >>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.
> >> Welcome back.
> >>
> >> When H(P,P) correctly simulates its input this is the ultimate measure
> >> of the actual behavior specified by this input.
> >
> > No, the actual behaviour is the actual behaviour! If H correctlky simulates this behaviour then it too will also be the same, but you have siad numerous times that it does not correctly simulate the behavoutr.
> >
> It is an easily verified fact that H(P,P) correctly simulates its input
> to everyone having sufficient knowledge of the x86 assembly language
> which currently seems to be hardy no one besides me. Back in the 1986
> when I began my career about 10% of all programmers had familiarity
> with the x86 language. This is the language that MSDOS and versions
> of MS Windows prior to Windows NT were written in. Windows NT switched
> to mostly C/C++.
>
> The 23 emails that I had with a leading computer scientist made that
> very clear. Because of this I re-framed my explanation so that any
> expert C programmer that totally understands infinite recursion would be
> able to see that infinitely nested simulation is essentially the same
> thing.
>
> The next important point that requires one to have top software
> engineering skills that allowed me to transform H into a pure thus
> computable function: Infinitely nested simulation can be detected the
> first time that the simulated input calls the simulator with its same
> arguments. Infinite recursion requires seeing two such calls in a row.
> This change allowed me to discard the need for static local memory and
> do everything in local memory.
> >> A security guard at the front door is only required to validate people
> >> coming in the front door the actual behavior of the actual input to H(P,P).
> >>
> >> This same security guard is not required to validate people coming in
> >> the back door the direct execution of P(P). Unless a computation is
> >> specified as an actual input to H it is not in the domain of the
> >> computable function that H implements.
> >
> > H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
> No this a very long standing misconception. H is required to determine
> whether or not its correct simulation of its input would ever reach the
> normal termination of this input.
>
> Since no one ever bothered to think through the application of a
> simulating halt decider to the HP's impossible inputs they always stated
> the requirements incorrectly never realizing their mistake.
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
> In the H/P concrete example it is easily proven that the actual behavior
> of the actual input to H(P,P) is not the behavior of the directly
> executed P(P). The best proof of this is the x86 execution trace of each
> that precisely corresponds to what the x86 source code of P specifies.
>
> From this is is obvious that the correctly simulated P cannot possibly
> terminate normally and the executed P(P) halts.
>
> Those lacking knowledge of the x86 language can understand that this
> first halt deciding principle is necessarily correct:
>
> *When this halt deciding principle understood to be correct*
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
> And this second halt deciding principle follows from the first one by
> logical necessity.
>
> *Then (by logical necessity) this implements that principle*
> Every simulating halt decider that correctly simulates its input until
> it correctly predicts that this simulated input would never terminate
> normally, correctly rejects this input as non-halting.
>
> >
> > If a program M would halt given input X, then H(M, X) is required to be non-zero.
> > If a program M would not halt given input X, then H(M, X) is required to be zero.
> >
> This is a misconception that can only be true if the halt decider is
> required to report on something besides the actual behavior of its
> actual input.
>
> The ultimate measure of the actual behavior of the actual input is the
> provable correct simulation of this input by the simulating halt decider.
>
> To assume that this behavior must be the same as the directly executed
> P(P) after it has been conclusively proven to not be that same as an
> established fact is at least a little nutty.
>
> That people unequivocally state that I must be wrong entirely on the
> basis that they lack sufficient understanding of the x86 language to
> understand my proof is a worst case example of the ad ignorantiam logic
> error.
> > If for some combination M, X the function H(M, X) gives the wrong answer, then it is not a halt decider. If particular, if H(M, X) = 0 but M(X) does halt, then the answer is wrong. You can't get out of it by arguing that M(X) is "direct" and H(M, X) is a "correct simulation", whatever that might mean. The answer needs to relate to the actual behaviour, as you yourself have said numerous times.
> >
> > Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does not halt, H(P, P) is required to be zero. Anything else is the wrong answer.
> >
> > When we calculate H(P, P), we are supplying P as the first argument and so P is specified as an actual input to H. And we are interested in the actual behaviour of P, the actual input. There is no "back door" by which you can say that P(P) is not the function and input we are talking about.
> >
> >>> To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:
> >>>
> >>> A) H(P, P) returns 0 and P(P) terminates.
> >>> B) H(P, P) returns non-zero and P(P) terminates.
> >>> C) H(P, P) returns 0 and P(P) does not terminate.
> >>> D) H(P, P) returns non-zero and P(P) does not terminate.
> >>>
> >>> B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.
> >
> >> A1) H(P, P) returns 0 because it correctly determines that the input
> >> that it correctly simulates would never terminate normally.
> >
> > No, that is not a correct answer. You have said numerous times that P(P) terminates.
> >
> >> A2) Directly executed P(P) halts because of (A)
> --
> 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/13/2022 3:47 PM, wij wrote:
> On Thursday, 14 July 2022 at 03:37:13 UTC+8, olcott wrote:
>> On 7/13/2022 1:03 PM, Paul N wrote:
>>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
>>>> On 7/13/2022 10:02 AM, Paul N wrote:
>>>>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.
>>>>>
>>>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
>>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
>>>>>>
>>>>>> I rewrote this question so that a software engineer of ordinary skill
>>>>>> can easily verify that the simulated P does call H in what is
>>>>>> essentially infinite recursion. **This simplification is the result of
>>>>>> an extensive review (23 emails) by a leading computer scientist over the
>>>>>> weekend.**
>>>>>
>>>>>> Does H(P,P) correctly determine the halt status of the halting problem's
>>>>>> pathological input?
>>>>>
>>>>>> The following H and P have the above specified pathological relationship
>>>>>> to each other.
>>>>>>
>>>>>> typedef void (*ptr)();
>>>>>> int H(ptr p, ptr i);
>>>>>>
>>>>>> void P(ptr x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>> }
>>>>>>
>>>>>> Simulating halt decider H detects that its simulated input is
>>>>>> essentially calling H in infinite recursion. H aborts its simulation on
>>>>>> this basis and rejects this input as non-halting.
>>>>>
>>>>> Thus it is an incorrect assessment, as we'll see below.
>>>>>
>>>>>> *Once this halt deciding principle is accepted*
>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>> specified by these inputs.
>>>>>
>>>>> Again, emphasis on "actual behaviour".
>>>>>
>>>>>> *Then (by logical necessity) this is understood to implement that*
>>>>>> Every simulating halt decider that correctly simulates its input until
>>>>>> it correctly predicts that this simulated input would never terminate
>>>>>> normally, correctly rejects this input as non-halting.
>>>>>
>>>>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
>>>>>
>>>>>> *The execution trace of function P() simulated by function H() shows*
>>>>>> (1) Function H() is called from P().
>>>>>> (2) With the same parameters to H().
>>>>>> (3) With no instructions in P() that could possibly escape this
>>>>>> infinitely recursive simulation.
>>>>>
>>>>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
>>>>>
>>>>>> This proves that H(P,P) correctly predicts that its correctly simulated
>>>>>> input would never terminate normally.
>>>>>
>>>>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.
>>>> Welcome back.
>>>>
>>>> When H(P,P) correctly simulates its input this is the ultimate measure
>>>> of the actual behavior specified by this input.
>>>
>>> No, the actual behaviour is the actual behaviour! If H correctlky simulates this behaviour then it too will also be the same, but you have siad numerous times that it does not correctly simulate the behavoutr.
>>>
>> It is an easily verified fact that H(P,P) correctly simulates its input
>> to everyone having sufficient knowledge of the x86 assembly language
>> which currently seems to be hardy no one besides me. Back in the 1986
>> when I began my career about 10% of all programmers had familiarity
>> with the x86 language. This is the language that MSDOS and versions
>> of MS Windows prior to Windows NT were written in. Windows NT switched
>> to mostly C/C++.
>>
>> The 23 emails that I had with a leading computer scientist made that
>> very clear. Because of this I re-framed my explanation so that any
>> expert C programmer that totally understands infinite recursion would be
>> able to see that infinitely nested simulation is essentially the same
>> thing.
>>
>> The next important point that requires one to have top software
>> engineering skills that allowed me to transform H into a pure thus
>> computable function: Infinitely nested simulation can be detected the
>> first time that the simulated input calls the simulator with its same
>> arguments. Infinite recursion requires seeing two such calls in a row.
>> This change allowed me to discard the need for static local memory and
>> do everything in local memory.
>>>> A security guard at the front door is only required to validate people
>>>> coming in the front door the actual behavior of the actual input to H(P,P).
>>>>
>>>> This same security guard is not required to validate people coming in
>>>> the back door the direct execution of P(P). Unless a computation is
>>>> specified as an actual input to H it is not in the domain of the
>>>> computable function that H implements.
>>>
>>> H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
>> No this a very long standing misconception. H is required to determine
>> whether or not its correct simulation of its input would ever reach the
>> normal termination of this input.
>>
>> Since no one ever bothered to think through the application of a
>> simulating halt decider to the HP's impossible inputs they always stated
>> the requirements incorrectly never realizing their mistake.
>> A halt decider must compute the mapping from its inputs to an accept or
>> reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>> In the H/P concrete example it is easily proven that the actual behavior
>> of the actual input to H(P,P) is not the behavior of the directly
>> executed P(P). The best proof of this is the x86 execution trace of each
>> that precisely corresponds to what the x86 source code of P specifies.
>>
>> From this is is obvious that the correctly simulated P cannot possibly
>> terminate normally and the executed P(P) halts.
>>
>> Those lacking knowledge of the x86 language can understand that this
>> first halt deciding principle is necessarily correct:
>>
>> *When this halt deciding principle understood to be correct*
>> A halt decider must compute the mapping from its inputs to an accept or
>> reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>> And this second halt deciding principle follows from the first one by
>> logical necessity.
>>
>> *Then (by logical necessity) this implements that principle*
>> Every simulating halt decider that correctly simulates its input until
>> it correctly predicts that this simulated input would never terminate
>> normally, correctly rejects this input as non-halting.
>>
>>>
>>> If a program M would halt given input X, then H(M, X) is required to be non-zero.
>>> If a program M would not halt given input X, then H(M, X) is required to be zero.
>>>
>> This is a misconception that can only be true if the halt decider is
>> required to report on something besides the actual behavior of its
>> actual input.
>>
>> The ultimate measure of the actual behavior of the actual input is the
>> provable correct simulation of this input by the simulating halt decider.
>>
>> To assume that this behavior must be the same as the directly executed
>> P(P) after it has been conclusively proven to not be that same as an
>> established fact is at least a little nutty.
>>
>> That people unequivocally state that I must be wrong entirely on the
>> basis that they lack sufficient understanding of the x86 language to
>> understand my proof is a worst case example of the ad ignorantiam logic
>> error.
>>> If for some combination M, X the function H(M, X) gives the wrong answer, then it is not a halt decider. If particular, if H(M, X) = 0 but M(X) does halt, then the answer is wrong. You can't get out of it by arguing that M(X) is "direct" and H(M, X) is a "correct simulation", whatever that might mean. The answer needs to relate to the actual behaviour, as you yourself have said numerous times.
>>>
>>> Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does not halt, H(P, P) is required to be zero. Anything else is the wrong answer.
>>>
>>> When we calculate H(P, P), we are supplying P as the first argument and so P is specified as an actual input to H. And we are interested in the actual behaviour of P, the actual input. There is no "back door" by which you can say that P(P) is not the function and input we are talking about.
>>>
>>>>> To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:
>>>>>
>>>>> A) H(P, P) returns 0 and P(P) terminates.
>>>>> B) H(P, P) returns non-zero and P(P) terminates.
>>>>> C) H(P, P) returns 0 and P(P) does not terminate.
>>>>> D) H(P, P) returns non-zero and P(P) does not terminate.
>>>>>
>>>>> B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.
>>>
>>>> A1) H(P, P) returns 0 because it correctly determines that the input
>>>> that it correctly simulates would never terminate normally.
>>>
>>> No, that is not a correct answer. You have said numerous times that P(P) terminates.
>>>
>>>> A2) Directly executed P(P) halts because of (A)
>> --
>> Copyright 2022 Pete Olcott
>>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer
>
> Halting problem https://en.wikipedia.org/wiki/Halting_problem
> ...the halting problem is the problem of determining, from a description of an arbitrary
> computer program and an input, whether the program will finish running, or continue to run forever.
>
> The property that an arbitrary program P will finish running or not is determined by
> running P as an independent program
Because that would require that a halt decider must sometimes make its
halt status decision on a basis other than the actual behavior of its
actual input that long standing misconception has been refuted.

On Thursday, 14 July 2022 at 04:51:25 UTC+8, olcott wrote:
> On 7/13/2022 3:47 PM, wij wrote:
> > On Thursday, 14 July 2022 at 03:37:13 UTC+8, olcott wrote:
> >> On 7/13/2022 1:03 PM, Paul N wrote:
> >>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
> >>>> On 7/13/2022 10:02 AM, Paul N wrote:
> >>>>> Firstly, this subject matter is not relevant in comp.lang.c or comp..lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.
> >>>>>
> >>>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
> >>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
> >>>>>>
> >>>>>> I rewrote this question so that a software engineer of ordinary skill
> >>>>>> can easily verify that the simulated P does call H in what is
> >>>>>> essentially infinite recursion. **This simplification is the result of
> >>>>>> an extensive review (23 emails) by a leading computer scientist over the
> >>>>>> weekend.**
> >>>>>
> >>>>>> Does H(P,P) correctly determine the halt status of the halting problem's
> >>>>>> pathological input?
> >>>>>
> >>>>>> The following H and P have the above specified pathological relationship
> >>>>>> to each other.
> >>>>>>
> >>>>>> typedef void (*ptr)();
> >>>>>> int H(ptr p, ptr i);
> >>>>>>
> >>>>>> void P(ptr x)
> >>>>>> {
> >>>>>> if (H(x, x))
> >>>>>> HERE: goto HERE;
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>> }
> >>>>>>
> >>>>>> Simulating halt decider H detects that its simulated input is
> >>>>>> essentially calling H in infinite recursion. H aborts its simulation on
> >>>>>> this basis and rejects this input as non-halting.
> >>>>>
> >>>>> Thus it is an incorrect assessment, as we'll see below.
> >>>>>
> >>>>>> *Once this halt deciding principle is accepted*
> >>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>> specified by these inputs.
> >>>>>
> >>>>> Again, emphasis on "actual behaviour".
> >>>>>
> >>>>>> *Then (by logical necessity) this is understood to implement that*
> >>>>>> Every simulating halt decider that correctly simulates its input until
> >>>>>> it correctly predicts that this simulated input would never terminate
> >>>>>> normally, correctly rejects this input as non-halting.
> >>>>>
> >>>>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
> >>>>>
> >>>>>> *The execution trace of function P() simulated by function H() shows*
> >>>>>> (1) Function H() is called from P().
> >>>>>> (2) With the same parameters to H().
> >>>>>> (3) With no instructions in P() that could possibly escape this
> >>>>>> infinitely recursive simulation.
> >>>>>
> >>>>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
> >>>>>
> >>>>>> This proves that H(P,P) correctly predicts that its correctly simulated
> >>>>>> input would never terminate normally.
> >>>>>
> >>>>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.
> >>>> Welcome back.
> >>>>
> >>>> When H(P,P) correctly simulates its input this is the ultimate measure
> >>>> of the actual behavior specified by this input.
> >>>
> >>> No, the actual behaviour is the actual behaviour! If H correctlky simulates this behaviour then it too will also be the same, but you have siad numerous times that it does not correctly simulate the behavoutr.
> >>>
> >> It is an easily verified fact that H(P,P) correctly simulates its input
> >> to everyone having sufficient knowledge of the x86 assembly language
> >> which currently seems to be hardy no one besides me. Back in the 1986
> >> when I began my career about 10% of all programmers had familiarity
> >> with the x86 language. This is the language that MSDOS and versions
> >> of MS Windows prior to Windows NT were written in. Windows NT switched
> >> to mostly C/C++.
> >>
> >> The 23 emails that I had with a leading computer scientist made that
> >> very clear. Because of this I re-framed my explanation so that any
> >> expert C programmer that totally understands infinite recursion would be
> >> able to see that infinitely nested simulation is essentially the same
> >> thing.
> >>
> >> The next important point that requires one to have top software
> >> engineering skills that allowed me to transform H into a pure thus
> >> computable function: Infinitely nested simulation can be detected the
> >> first time that the simulated input calls the simulator with its same
> >> arguments. Infinite recursion requires seeing two such calls in a row.
> >> This change allowed me to discard the need for static local memory and
> >> do everything in local memory.
> >>>> A security guard at the front door is only required to validate people
> >>>> coming in the front door the actual behavior of the actual input to H(P,P).
> >>>>
> >>>> This same security guard is not required to validate people coming in
> >>>> the back door the direct execution of P(P). Unless a computation is
> >>>> specified as an actual input to H it is not in the domain of the
> >>>> computable function that H implements.
> >>>
> >>> H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
> >> No this a very long standing misconception. H is required to determine
> >> whether or not its correct simulation of its input would ever reach the
> >> normal termination of this input.
> >>
> >> Since no one ever bothered to think through the application of a
> >> simulating halt decider to the HP's impossible inputs they always stated
> >> the requirements incorrectly never realizing their mistake.
> >> A halt decider must compute the mapping from its inputs to an accept or
> >> reject state on the basis of the actual behavior that is actually
> >> specified by these inputs.
> >> In the H/P concrete example it is easily proven that the actual behavior
> >> of the actual input to H(P,P) is not the behavior of the directly
> >> executed P(P). The best proof of this is the x86 execution trace of each
> >> that precisely corresponds to what the x86 source code of P specifies.
> >>
> >> From this is is obvious that the correctly simulated P cannot possibly
> >> terminate normally and the executed P(P) halts.
> >>
> >> Those lacking knowledge of the x86 language can understand that this
> >> first halt deciding principle is necessarily correct:
> >>
> >> *When this halt deciding principle understood to be correct*
> >> A halt decider must compute the mapping from its inputs to an accept or
> >> reject state on the basis of the actual behavior that is actually
> >> specified by these inputs.
> >> And this second halt deciding principle follows from the first one by
> >> logical necessity.
> >>
> >> *Then (by logical necessity) this implements that principle*
> >> Every simulating halt decider that correctly simulates its input until
> >> it correctly predicts that this simulated input would never terminate
> >> normally, correctly rejects this input as non-halting.
> >>
> >>>
> >>> If a program M would halt given input X, then H(M, X) is required to be non-zero.
> >>> If a program M would not halt given input X, then H(M, X) is required to be zero.
> >>>
> >> This is a misconception that can only be true if the halt decider is
> >> required to report on something besides the actual behavior of its
> >> actual input.
> >>
> >> The ultimate measure of the actual behavior of the actual input is the
> >> provable correct simulation of this input by the simulating halt decider.
> >>
> >> To assume that this behavior must be the same as the directly executed
> >> P(P) after it has been conclusively proven to not be that same as an
> >> established fact is at least a little nutty.
> >>
> >> That people unequivocally state that I must be wrong entirely on the
> >> basis that they lack sufficient understanding of the x86 language to
> >> understand my proof is a worst case example of the ad ignorantiam logic
> >> error.
> >>> If for some combination M, X the function H(M, X) gives the wrong answer, then it is not a halt decider. If particular, if H(M, X) = 0 but M(X) does halt, then the answer is wrong. You can't get out of it by arguing that M(X) is "direct" and H(M, X) is a "correct simulation", whatever that might mean. The answer needs to relate to the actual behaviour, as you yourself have said numerous times.
> >>>
> >>> Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does not halt, H(P, P) is required to be zero. Anything else is the wrong answer..
> >>>
> >>> When we calculate H(P, P), we are supplying P as the first argument and so P is specified as an actual input to H. And we are interested in the actual behaviour of P, the actual input. There is no "back door" by which you can say that P(P) is not the function and input we are talking about.
> >>>
> >>>>> To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:
> >>>>>
> >>>>> A) H(P, P) returns 0 and P(P) terminates.
> >>>>> B) H(P, P) returns non-zero and P(P) terminates.
> >>>>> C) H(P, P) returns 0 and P(P) does not terminate.
> >>>>> D) H(P, P) returns non-zero and P(P) does not terminate.
> >>>>>
> >>>>> B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.
> >>>
> >>>> A1) H(P, P) returns 0 because it correctly determines that the input
> >>>> that it correctly simulates would never terminate normally.
> >>>
> >>> No, that is not a correct answer. You have said numerous times that P(P) terminates.
> >>>
> >>>> A2) Directly executed P(P) halts because of (A)
> >> --
> >> Copyright 2022 Pete Olcott
> >>
> >> "Talent hits a target no one else can hit;
> >> Genius hits a target no one else can see."
> >> Arthur Schopenhauer
> >
> > Halting problem https://en.wikipedia.org/wiki/Halting_problem
> > ...the halting problem is the problem of determining, from a description of an arbitrary
> > computer program and an input, whether the program will finish running, or continue to run forever.
> >
> > The property that an arbitrary program P will finish running or not is determined by
> > running P as an independent program
> Because that would require that a halt decider must sometimes make its
> halt status decision on a basis other than the actual behavior of its
> actual input that long standing misconception has been refuted.
> --
> 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/13/22 3:37 PM, olcott wrote:
> On 7/13/2022 1:03 PM, Paul N wrote:
>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
>>> On 7/13/2022 10:02 AM, Paul N wrote:
>>>> Firstly, this subject matter is not relevant in comp.lang.c or
>>>> comp.lang.c++, so please stop posting any of it there. If I see any
>>>> more posts of this sort in either of those newsgroups I shall assume
>>>> that, regardless of the merits of your argument, you are very rude.
>>>>
>>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
>>>>>
>>>>> I rewrote this question so that a software engineer of ordinary skill
>>>>> can easily verify that the simulated P does call H in what is
>>>>> essentially infinite recursion. **This simplification is the result of
>>>>> an extensive review (23 emails) by a leading computer scientist
>>>>> over the
>>>>> weekend.**
>>>>
>>>>> Does H(P,P) correctly determine the halt status of the halting
>>>>> problem's
>>>>> pathological input?
>>>>
>>>>> The following H and P have the above specified pathological
>>>>> relationship
>>>>> to each other.
>>>>>
>>>>> typedef void (*ptr)();
>>>>> int H(ptr p, ptr i);
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>>
>>>>> Simulating halt decider H detects that its simulated input is
>>>>> essentially calling H in infinite recursion. H aborts its
>>>>> simulation on
>>>>> this basis and rejects this input as non-halting.
>>>>
>>>> Thus it is an incorrect assessment, as we'll see below.
>>>>
>>>>> *Once this halt deciding principle is accepted*
>>>>> A halt decider must compute the mapping from its inputs to an
>>>>> accept or
>>>>> reject state on the basis of the actual behavior that is actually
>>>>> specified by these inputs.
>>>>
>>>> Again, emphasis on "actual behaviour".
>>>>
>>>>> *Then (by logical necessity) this is understood to implement that*
>>>>> Every simulating halt decider that correctly simulates its input until
>>>>> it correctly predicts that this simulated input would never terminate
>>>>> normally, correctly rejects this input as non-halting.
>>>>
>>>> You have stated numerous times that a program that "correctly
>>>> simulates its input" can have different results. Thus it is not
>>>> clear what you mean by the phrase. There is no logical necessity to
>>>> accept anything about a correct simulation which does not simulate
>>>> correctly.
>>>>
>>>>> *The execution trace of function P() simulated by function H() shows*
>>>>> (1) Function H() is called from P().
>>>>> (2) With the same parameters to H().
>>>>> (3) With no instructions in P() that could possibly escape this
>>>>> infinitely recursive simulation.
>>>>
>>>> Ah, but there are instructions in H which escape from the infinite
>>>> recursion. You've said numerous times that there are. See only a few
>>>> lines up. If you pretend that they are somehow not there, you are
>>>> not correctly simulating H and hence not correctly simulating P
>>>> which calls it.
>>>>
>>>>> This proves that H(P,P) correctly predicts that its correctly
>>>>> simulated
>>>>> input would never terminate normally.
>>>>
>>>> As you've said above, in capitals and with asterisks, changing the
>>>> subject is not a rebuttal. You're trying to change the subject from
>>>> the actual behaviour of P(P) to some sort of "simulated" behaviour
>>>> of P(P) which you have said yourself is different.
>>> Welcome back.
>>>
>>> When H(P,P) correctly simulates its input this is the ultimate measure
>>> of the actual behavior specified by this input.
>>
>> No, the actual behaviour is the actual behaviour! If H correctlky
>> simulates this behaviour then it too will also be the same, but you
>> have siad numerous times that it does not correctly simulate the
>> behavoutr.
>>
>
> It is an easily verified fact that H(P,P) correctly simulates its input
> to everyone having sufficient knowledge of the x86 assembly language
> which currently seems to be hardy no one besides me. Back in the 1986
> when I began my career about 10% of all programmers had familiarity
> with the x86 language. This is the language that MSDOS and versions
> of MS Windows prior to Windows NT were written in. Windows NT switched
> to mostly C/C++.

No, it is easily verified tha H doesn't correctly simulate its input,
since BUY DEFINITION H(P,P) must be being asked about the behavior of
P(P) since that is the question that P is supposed to be asking H.

Since H's simulation of its input doesn't match the behavior of the
actual machine it is supposed to be simulating, it is incorrect.

THAT IS PURELY FROM THE DEFINTION OF CORRECT.

>
> The 23 emails that I had with a leading computer scientist made that
> very clear. Because of this I re-framed my explanation so that any
> expert C programmer that totally understands infinite recursion would be
> able to see that infinitely nested simulation is essentially the same
> thing.

You are very good at hiding the truth. If you said that H was DEFINED to
be a machine that did a pure simulation of its input until it actually
proved that its input doesn't halt, then yes, by that definition P(P)
will be non-halting, but also by that definiton H(P,P) can NEVER abort
its simulation of the input, becuase it can NEVER actually prove the
input to be non-halting, because if it ever thinks it has and returns 0,
then the input becomes halting.

If you made that claim while at the same time your H ACTUALLY did the
aborting, then you LIED, and his "support" is invalid.

>
> The next important point that requires one to have top software
> engineering skills that allowed me to transform H into a pure thus
> computable function: Infinitely nested simulation can be detected the
> first time that the simulated input calls the simulator with its same
> arguments. Infinite recursion requires seeing two such calls in a row.
> This change allowed me to discard the need for static local memory and
> do everything in local memory.
>

Nope, show the proof of that claim. Remember, the proof MUST include the
fact that the simulator is NOT "just" a pure simulator, but is
conditional on the behavior of the simulation, and WILL (per your claim)
abort this simulation and return 0.

>>> A security guard at the front door is only required to validate people
>>> coming in the front door the actual behavior of the actual input to
>>> H(P,P).
>>>
>>> This same security guard is not required to validate people coming in
>>> the back door the direct execution of P(P). Unless a computation is
>>> specified as an actual input to H it is not in the domain of the
>>> computable function that H implements.
>>
>> H takes two arguments. The first is a program to be considered and the
>> second is the input that could be supplied to that program. H is
>> required to decide, correctly, whether the program would halt given
>> that input, ie whether M(X) would halt.
>
> No this a very long standing misconception. H is required to determine
> whether or not its correct simulation of its input would ever reach the
> normal termination of this input.

Nope. If H is to be a Halt Decider, it must map the inputs, to the
behaivor of the program and input that its input represents. The Halting
Problem NEVER mentions simulation of its inputs.

You just are showing you don't understand the basics of the proof you
are talking about.

>
> Since no one ever bothered to think through the application of a
> simulating halt decider to the HP's impossible inputs they always stated
> the requirements incorrectly never realizing their mistake.

On 7/13/2022 4:11 PM, wij wrote:
> On Thursday, 14 July 2022 at 04:51:25 UTC+8, olcott wrote:
>> On 7/13/2022 3:47 PM, wij wrote:
>>> On Thursday, 14 July 2022 at 03:37:13 UTC+8, olcott wrote:
>>>> On 7/13/2022 1:03 PM, Paul N wrote:
>>>>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
>>>>>> On 7/13/2022 10:02 AM, Paul N wrote:
>>>>>>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.
>>>>>>>
>>>>>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
>>>>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
>>>>>>>>
>>>>>>>> I rewrote this question so that a software engineer of ordinary skill
>>>>>>>> can easily verify that the simulated P does call H in what is
>>>>>>>> essentially infinite recursion. **This simplification is the result of
>>>>>>>> an extensive review (23 emails) by a leading computer scientist over the
>>>>>>>> weekend.**
>>>>>>>
>>>>>>>> Does H(P,P) correctly determine the halt status of the halting problem's
>>>>>>>> pathological input?
>>>>>>>
>>>>>>>> The following H and P have the above specified pathological relationship
>>>>>>>> to each other.
>>>>>>>>
>>>>>>>> typedef void (*ptr)();
>>>>>>>> int H(ptr p, ptr i);
>>>>>>>>
>>>>>>>> void P(ptr x)
>>>>>>>> {
>>>>>>>> if (H(x, x))
>>>>>>>> HERE: goto HERE;
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> Simulating halt decider H detects that its simulated input is
>>>>>>>> essentially calling H in infinite recursion. H aborts its simulation on
>>>>>>>> this basis and rejects this input as non-halting.
>>>>>>>
>>>>>>> Thus it is an incorrect assessment, as we'll see below.
>>>>>>>
>>>>>>>> *Once this halt deciding principle is accepted*
>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>> specified by these inputs.
>>>>>>>
>>>>>>> Again, emphasis on "actual behaviour".
>>>>>>>
>>>>>>>> *Then (by logical necessity) this is understood to implement that*
>>>>>>>> Every simulating halt decider that correctly simulates its input until
>>>>>>>> it correctly predicts that this simulated input would never terminate
>>>>>>>> normally, correctly rejects this input as non-halting.
>>>>>>>
>>>>>>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
>>>>>>>
>>>>>>>> *The execution trace of function P() simulated by function H() shows*
>>>>>>>> (1) Function H() is called from P().
>>>>>>>> (2) With the same parameters to H().
>>>>>>>> (3) With no instructions in P() that could possibly escape this
>>>>>>>> infinitely recursive simulation.
>>>>>>>
>>>>>>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
>>>>>>>
>>>>>>>> This proves that H(P,P) correctly predicts that its correctly simulated
>>>>>>>> input would never terminate normally.
>>>>>>>
>>>>>>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.
>>>>>> Welcome back.
>>>>>>
>>>>>> When H(P,P) correctly simulates its input this is the ultimate measure
>>>>>> of the actual behavior specified by this input.
>>>>>
>>>>> No, the actual behaviour is the actual behaviour! If H correctlky simulates this behaviour then it too will also be the same, but you have siad numerous times that it does not correctly simulate the behavoutr.
>>>>>
>>>> It is an easily verified fact that H(P,P) correctly simulates its input
>>>> to everyone having sufficient knowledge of the x86 assembly language
>>>> which currently seems to be hardy no one besides me. Back in the 1986
>>>> when I began my career about 10% of all programmers had familiarity
>>>> with the x86 language. This is the language that MSDOS and versions
>>>> of MS Windows prior to Windows NT were written in. Windows NT switched
>>>> to mostly C/C++.
>>>>
>>>> The 23 emails that I had with a leading computer scientist made that
>>>> very clear. Because of this I re-framed my explanation so that any
>>>> expert C programmer that totally understands infinite recursion would be
>>>> able to see that infinitely nested simulation is essentially the same
>>>> thing.
>>>>
>>>> The next important point that requires one to have top software
>>>> engineering skills that allowed me to transform H into a pure thus
>>>> computable function: Infinitely nested simulation can be detected the
>>>> first time that the simulated input calls the simulator with its same
>>>> arguments. Infinite recursion requires seeing two such calls in a row.
>>>> This change allowed me to discard the need for static local memory and
>>>> do everything in local memory.
>>>>>> A security guard at the front door is only required to validate people
>>>>>> coming in the front door the actual behavior of the actual input to H(P,P).
>>>>>>
>>>>>> This same security guard is not required to validate people coming in
>>>>>> the back door the direct execution of P(P). Unless a computation is
>>>>>> specified as an actual input to H it is not in the domain of the
>>>>>> computable function that H implements.
>>>>>
>>>>> H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
>>>> No this a very long standing misconception. H is required to determine
>>>> whether or not its correct simulation of its input would ever reach the
>>>> normal termination of this input.
>>>>
>>>> Since no one ever bothered to think through the application of a
>>>> simulating halt decider to the HP's impossible inputs they always stated
>>>> the requirements incorrectly never realizing their mistake.
>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>> reject state on the basis of the actual behavior that is actually
>>>> specified by these inputs.
>>>> In the H/P concrete example it is easily proven that the actual behavior
>>>> of the actual input to H(P,P) is not the behavior of the directly
>>>> executed P(P). The best proof of this is the x86 execution trace of each
>>>> that precisely corresponds to what the x86 source code of P specifies.
>>>>
>>>> From this is is obvious that the correctly simulated P cannot possibly
>>>> terminate normally and the executed P(P) halts.
>>>>
>>>> Those lacking knowledge of the x86 language can understand that this
>>>> first halt deciding principle is necessarily correct:
>>>>
>>>> *When this halt deciding principle understood to be correct*
>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>> reject state on the basis of the actual behavior that is actually
>>>> specified by these inputs.
>>>> And this second halt deciding principle follows from the first one by
>>>> logical necessity.
>>>>
>>>> *Then (by logical necessity) this implements that principle*
>>>> Every simulating halt decider that correctly simulates its input until
>>>> it correctly predicts that this simulated input would never terminate
>>>> normally, correctly rejects this input as non-halting.
>>>>
>>>>>
>>>>> If a program M would halt given input X, then H(M, X) is required to be non-zero.
>>>>> If a program M would not halt given input X, then H(M, X) is required to be zero.
>>>>>
>>>> This is a misconception that can only be true if the halt decider is
>>>> required to report on something besides the actual behavior of its
>>>> actual input.
>>>>
>>>> The ultimate measure of the actual behavior of the actual input is the
>>>> provable correct simulation of this input by the simulating halt decider.
>>>>
>>>> To assume that this behavior must be the same as the directly executed
>>>> P(P) after it has been conclusively proven to not be that same as an
>>>> established fact is at least a little nutty.
>>>>
>>>> That people unequivocally state that I must be wrong entirely on the
>>>> basis that they lack sufficient understanding of the x86 language to
>>>> understand my proof is a worst case example of the ad ignorantiam logic
>>>> error.
>>>>> If for some combination M, X the function H(M, X) gives the wrong answer, then it is not a halt decider. If particular, if H(M, X) = 0 but M(X) does halt, then the answer is wrong. You can't get out of it by arguing that M(X) is "direct" and H(M, X) is a "correct simulation", whatever that might mean. The answer needs to relate to the actual behaviour, as you yourself have said numerous times.
>>>>>
>>>>> Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does not halt, H(P, P) is required to be zero. Anything else is the wrong answer.
>>>>>
>>>>> When we calculate H(P, P), we are supplying P as the first argument and so P is specified as an actual input to H. And we are interested in the actual behaviour of P, the actual input. There is no "back door" by which you can say that P(P) is not the function and input we are talking about.
>>>>>
>>>>>>> To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:
>>>>>>>
>>>>>>> A) H(P, P) returns 0 and P(P) terminates.
>>>>>>> B) H(P, P) returns non-zero and P(P) terminates.
>>>>>>> C) H(P, P) returns 0 and P(P) does not terminate.
>>>>>>> D) H(P, P) returns non-zero and P(P) does not terminate.
>>>>>>>
>>>>>>> B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.
>>>>>
>>>>>> A1) H(P, P) returns 0 because it correctly determines that the input
>>>>>> that it correctly simulates would never terminate normally.
>>>>>
>>>>> No, that is not a correct answer. You have said numerous times that P(P) terminates.
>>>>>
>>>>>> A2) Directly executed P(P) halts because of (A)
>>>> --
>>>> Copyright 2022 Pete Olcott
>>>>
>>>> "Talent hits a target no one else can hit;
>>>> Genius hits a target no one else can see."
>>>> Arthur Schopenhauer
>>>
>>> Halting problem https://en.wikipedia.org/wiki/Halting_problem
>>> ...the halting problem is the problem of determining, from a description of an arbitrary
>>> computer program and an input, whether the program will finish running, or continue to run forever.
>>>
>>> The property that an arbitrary program P will finish running or not is determined by
>>> running P as an independent program
>> Because that would require that a halt decider must sometimes make its
>> halt status decision on a basis other than the actual behavior of its
>> actual input that long standing misconception has been refuted.
>> --
>> Copyright 2022 Pete Olcott
>>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer
>
> Because we often encountered a problem to know whether a 'independent' running
> program P will halt or not, therefore, this is an interested problem.
> We don't have such a problem asking H(P,P), the P 'simulated' by H halt or not.
>

On 7/13/22 8:10 PM, olcott wrote:
> On 7/13/2022 4:11 PM, wij wrote:
>> On Thursday, 14 July 2022 at 04:51:25 UTC+8, olcott wrote:
>>> On 7/13/2022 3:47 PM, wij wrote:
>>>> On Thursday, 14 July 2022 at 03:37:13 UTC+8, olcott wrote:
>>>>> On 7/13/2022 1:03 PM, Paul N wrote:
>>>>>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
>>>>>>> On 7/13/2022 10:02 AM, Paul N wrote:
>>>>>>>> Firstly, this subject matter is not relevant in comp.lang.c or
>>>>>>>> comp.lang.c++, so please stop posting any of it there. If I see
>>>>>>>> any more posts of this sort in either of those newsgroups I
>>>>>>>> shall assume that, regardless of the merits of your argument,
>>>>>>>> you are very rude.
>>>>>>>>
>>>>>>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
>>>>>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
>>>>>>>>>
>>>>>>>>> I rewrote this question so that a software engineer of ordinary
>>>>>>>>> skill
>>>>>>>>> can easily verify that the simulated P does call H in what is
>>>>>>>>> essentially infinite recursion. **This simplification is the
>>>>>>>>> result of
>>>>>>>>> an extensive review (23 emails) by a leading computer scientist
>>>>>>>>> over the
>>>>>>>>> weekend.**
>>>>>>>>
>>>>>>>>> Does H(P,P) correctly determine the halt status of the halting
>>>>>>>>> problem's
>>>>>>>>> pathological input?
>>>>>>>>
>>>>>>>>> The following H and P have the above specified pathological
>>>>>>>>> relationship
>>>>>>>>> to each other.
>>>>>>>>>
>>>>>>>>> typedef void (*ptr)();
>>>>>>>>> int H(ptr p, ptr i);
>>>>>>>>>
>>>>>>>>> void P(ptr x)
>>>>>>>>> {
>>>>>>>>> if (H(x, x))
>>>>>>>>> HERE: goto HERE;
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Simulating halt decider H detects that its simulated input is
>>>>>>>>> essentially calling H in infinite recursion. H aborts its
>>>>>>>>> simulation on
>>>>>>>>> this basis and rejects this input as non-halting.
>>>>>>>>
>>>>>>>> Thus it is an incorrect assessment, as we'll see below.
>>>>>>>>
>>>>>>>>> *Once this halt deciding principle is accepted*
>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>> accept or
>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>> specified by these inputs.
>>>>>>>>
>>>>>>>> Again, emphasis on "actual behaviour".
>>>>>>>>
>>>>>>>>> *Then (by logical necessity) this is understood to implement that*
>>>>>>>>> Every simulating halt decider that correctly simulates its
>>>>>>>>> input until
>>>>>>>>> it correctly predicts that this simulated input would never
>>>>>>>>> terminate
>>>>>>>>> normally, correctly rejects this input as non-halting.
>>>>>>>>
>>>>>>>> You have stated numerous times that a program that "correctly
>>>>>>>> simulates its input" can have different results. Thus it is not
>>>>>>>> clear what you mean by the phrase. There is no logical necessity
>>>>>>>> to accept anything about a correct simulation which does not
>>>>>>>> simulate correctly.
>>>>>>>>
>>>>>>>>> *The execution trace of function P() simulated by function H()
>>>>>>>>> shows*
>>>>>>>>> (1) Function H() is called from P().
>>>>>>>>> (2) With the same parameters to H().
>>>>>>>>> (3) With no instructions in P() that could possibly escape this
>>>>>>>>> infinitely recursive simulation.
>>>>>>>>
>>>>>>>> Ah, but there are instructions in H which escape from the
>>>>>>>> infinite recursion. You've said numerous times that there are.
>>>>>>>> See only a few lines up. If you pretend that they are somehow
>>>>>>>> not there, you are not correctly simulating H and hence not
>>>>>>>> correctly simulating P which calls it.
>>>>>>>>
>>>>>>>>> This proves that H(P,P) correctly predicts that its correctly
>>>>>>>>> simulated
>>>>>>>>> input would never terminate normally.
>>>>>>>>
>>>>>>>> As you've said above, in capitals and with asterisks, changing
>>>>>>>> the subject is not a rebuttal. You're trying to change the
>>>>>>>> subject from the actual behaviour of P(P) to some sort of
>>>>>>>> "simulated" behaviour of P(P) which you have said yourself is
>>>>>>>> different.
>>>>>>> Welcome back.
>>>>>>>
>>>>>>> When H(P,P) correctly simulates its input this is the ultimate
>>>>>>> measure
>>>>>>> of the actual behavior specified by this input.
>>>>>>
>>>>>> No, the actual behaviour is the actual behaviour! If H correctlky
>>>>>> simulates this behaviour then it too will also be the same, but
>>>>>> you have siad numerous times that it does not correctly simulate
>>>>>> the behavoutr.
>>>>>>
>>>>> It is an easily verified fact that H(P,P) correctly simulates its
>>>>> input
>>>>> to everyone having sufficient knowledge of the x86 assembly language
>>>>> which currently seems to be hardy no one besides me. Back in the 1986
>>>>> when I began my career about 10% of all programmers had familiarity
>>>>> with the x86 language. This is the language that MSDOS and versions
>>>>> of MS Windows prior to Windows NT were written in. Windows NT switched
>>>>> to mostly C/C++.
>>>>>
>>>>> The 23 emails that I had with a leading computer scientist made that
>>>>> very clear. Because of this I re-framed my explanation so that any
>>>>> expert C programmer that totally understands infinite recursion
>>>>> would be
>>>>> able to see that infinitely nested simulation is essentially the same
>>>>> thing.
>>>>>
>>>>> The next important point that requires one to have top software
>>>>> engineering skills that allowed me to transform H into a pure thus
>>>>> computable function: Infinitely nested simulation can be detected the
>>>>> first time that the simulated input calls the simulator with its same
>>>>> arguments. Infinite recursion requires seeing two such calls in a row.
>>>>> This change allowed me to discard the need for static local memory and
>>>>> do everything in local memory.
>>>>>>> A security guard at the front door is only required to validate
>>>>>>> people
>>>>>>> coming in the front door the actual behavior of the actual input
>>>>>>> to H(P,P).
>>>>>>>
>>>>>>> This same security guard is not required to validate people
>>>>>>> coming in
>>>>>>> the back door the direct execution of P(P). Unless a computation is
>>>>>>> specified as an actual input to H it is not in the domain of the
>>>>>>> computable function that H implements.
>>>>>>
>>>>>> H takes two arguments. The first is a program to be considered and
>>>>>> the second is the input that could be supplied to that program. H
>>>>>> is required to decide, correctly, whether the program would halt
>>>>>> given that input, ie whether M(X) would halt.
>>>>> No this a very long standing misconception. H is required to determine
>>>>> whether or not its correct simulation of its input would ever reach
>>>>> the
>>>>> normal termination of this input.
>>>>>
>>>>> Since no one ever bothered to think through the application of a
>>>>> simulating halt decider to the HP's impossible inputs they always
>>>>> stated
>>>>> the requirements incorrectly never realizing their mistake.
>>>>> A halt decider must compute the mapping from its inputs to an
>>>>> accept or
>>>>> reject state on the basis of the actual behavior that is actually
>>>>> specified by these inputs.
>>>>> In the H/P concrete example it is easily proven that the actual
>>>>> behavior
>>>>> of the actual input to H(P,P) is not the behavior of the directly
>>>>> executed P(P). The best proof of this is the x86 execution trace of
>>>>> each
>>>>> that precisely corresponds to what the x86 source code of P specifies.
>>>>>
>>>>>  From this is is obvious that the correctly simulated P cannot
>>>>> possibly
>>>>> terminate normally and the executed P(P) halts.
>>>>>
>>>>> Those lacking knowledge of the x86 language can understand that this
>>>>> first halt deciding principle is necessarily correct:
>>>>>
>>>>> *When this halt deciding principle understood to be correct*
>>>>> A halt decider must compute the mapping from its inputs to an
>>>>> accept or
>>>>> reject state on the basis of the actual behavior that is actually
>>>>> specified by these inputs.
>>>>> And this second halt deciding principle follows from the first one by
>>>>> logical necessity.
>>>>>
>>>>> *Then (by logical necessity) this implements that principle*
>>>>> Every simulating halt decider that correctly simulates its input until
>>>>> it correctly predicts that this simulated input would never terminate
>>>>> normally, correctly rejects this input as non-halting.
>>>>>
>>>>>>
>>>>>> If a program M would halt given input X, then H(M, X) is required
>>>>>> to be non-zero.
>>>>>> If a program M would not halt given input X, then H(M, X) is
>>>>>> required to be zero.
>>>>>>
>>>>> This is a misconception that can only be true if the halt decider is
>>>>> required to report on something besides the actual behavior of its
>>>>> actual input.
>>>>>
>>>>> The ultimate measure of the actual behavior of the actual input is the
>>>>> provable correct simulation of this input by the simulating halt
>>>>> decider.
>>>>>
>>>>> To assume that this behavior must be the same as the directly executed
>>>>> P(P) after it has been conclusively proven to not be that same as an
>>>>> established fact is at least a little nutty.
>>>>>
>>>>> That people unequivocally state that I must be wrong entirely on the
>>>>> basis that they lack sufficient understanding of the x86 language to
>>>>> understand my proof is a worst case example of the ad ignorantiam
>>>>> logic
>>>>> error.
>>>>>> If for some combination M, X the function H(M, X) gives the wrong
>>>>>> answer, then it is not a halt decider. If particular, if H(M, X) =
>>>>>> 0 but M(X) does halt, then the answer is wrong. You can't get out
>>>>>> of it by arguing that M(X) is "direct" and H(M, X) is a "correct
>>>>>> simulation", whatever that might mean. The answer needs to relate
>>>>>> to the actual behaviour, as you yourself have said numerous times.
>>>>>>
>>>>>> Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P)
>>>>>> does not halt, H(P, P) is required to be zero. Anything else is
>>>>>> the wrong answer.
>>>>>>
>>>>>> When we calculate H(P, P), we are supplying P as the first
>>>>>> argument and so P is specified as an actual input to H. And we are
>>>>>> interested in the actual behaviour of P, the actual input. There
>>>>>> is no "back door" by which you can say that P(P) is not the
>>>>>> function and input we are talking about.
>>>>>>
>>>>>>>> To summarise, if H(P, P) terminates (which you have never
>>>>>>>> denied), then there are at most four possibilities:
>>>>>>>>
>>>>>>>> A) H(P, P) returns 0 and P(P) terminates.
>>>>>>>> B) H(P, P) returns non-zero and P(P) terminates.
>>>>>>>> C) H(P, P) returns 0 and P(P) does not terminate.
>>>>>>>> D) H(P, P) returns non-zero and P(P) does not terminate.
>>>>>>>>
>>>>>>>> B and C are clearly not possible from the definition of P. In A
>>>>>>>> and D, H produces the wrong answer.
>>>>>>
>>>>>>> A1) H(P, P) returns 0 because it correctly determines that the input
>>>>>>> that it correctly simulates would never terminate normally.
>>>>>>
>>>>>> No, that is not a correct answer. You have said numerous times
>>>>>> that P(P) terminates.
>>>>>>
>>>>>>> A2) Directly executed P(P) halts because of (A)
>>>>> --
>>>>> Copyright 2022 Pete Olcott
>>>>>
>>>>> "Talent hits a target no one else can hit;
>>>>> Genius hits a target no one else can see."
>>>>> Arthur Schopenhauer
>>>>
>>>> Halting problem https://en.wikipedia.org/wiki/Halting_problem
>>>> ...the halting problem is the problem of determining, from a
>>>> description of an arbitrary
>>>> computer program and an input, whether the program will finish
>>>> running, or continue to run forever.
>>>>
>>>> The property that an arbitrary program P will finish running or not
>>>> is determined by
>>>> running P as an independent program
>>> Because that would require that a halt decider must sometimes make its
>>> halt status decision on a basis other than the actual behavior of its
>>> actual input that long standing misconception has been refuted.
>>> --
>>> Copyright 2022 Pete Olcott
>>>
>>> "Talent hits a target no one else can hit;
>>> Genius hits a target no one else can see."
>>> Arthur Schopenhauer
>>
>> Because we often encountered a problem to know whether a 'independent'
>> running
>> program P will halt or not, therefore, this is an interested problem.
>> We don't have such a problem asking H(P,P), the P 'simulated' by H
>> halt or not.
>>
>
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
>
> Everyone's rebuttal to this is that the halt decider must be a mind
> reader and report on the behavior of a computation that only exists in
> the minds of the readers and its not the same computation that is
> specified by its inputs.
>
> That is goofy and nutty and crazy.
>

On Wednesday, July 13, 2022 at 8:37:13 PM UTC+1, olcott wrote:
> On 7/13/2022 1:03 PM, Paul N wrote:
> > On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
> >> On 7/13/2022 10:02 AM, Paul N wrote:
> >>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.
> >>>
> >>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
> >>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
> >>>>
> >>>> I rewrote this question so that a software engineer of ordinary skill
> >>>> can easily verify that the simulated P does call H in what is
> >>>> essentially infinite recursion. **This simplification is the result of
> >>>> an extensive review (23 emails) by a leading computer scientist over the
> >>>> weekend.**
> >>>
> >>>> Does H(P,P) correctly determine the halt status of the halting problem's
> >>>> pathological input?
> >>>
> >>>> The following H and P have the above specified pathological relationship
> >>>> to each other.
> >>>>
> >>>> typedef void (*ptr)();
> >>>> int H(ptr p, ptr i);
> >>>>
> >>>> void P(ptr x)
> >>>> {
> >>>> if (H(x, x))
> >>>> HERE: goto HERE;
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H(P, P));
> >>>> }
> >>>>
> >>>> Simulating halt decider H detects that its simulated input is
> >>>> essentially calling H in infinite recursion. H aborts its simulation on
> >>>> this basis and rejects this input as non-halting.
> >>>
> >>> Thus it is an incorrect assessment, as we'll see below.
> >>>
> >>>> *Once this halt deciding principle is accepted*
> >>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>> reject state on the basis of the actual behavior that is actually
> >>>> specified by these inputs.
> >>>
> >>> Again, emphasis on "actual behaviour".
> >>>
> >>>> *Then (by logical necessity) this is understood to implement that*
> >>>> Every simulating halt decider that correctly simulates its input until
> >>>> it correctly predicts that this simulated input would never terminate
> >>>> normally, correctly rejects this input as non-halting.
> >>>
> >>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
> >>>
> >>>> *The execution trace of function P() simulated by function H() shows*
> >>>> (1) Function H() is called from P().
> >>>> (2) With the same parameters to H().
> >>>> (3) With no instructions in P() that could possibly escape this
> >>>> infinitely recursive simulation.
> >>>
> >>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up.. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
> >>>
> >>>> This proves that H(P,P) correctly predicts that its correctly simulated
> >>>> input would never terminate normally.
> >>>
> >>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.
> >> Welcome back.
> >>
> >> When H(P,P) correctly simulates its input this is the ultimate measure
> >> of the actual behavior specified by this input.
> >
> > No, the actual behaviour is the actual behaviour! If H correctly simulates this behaviour then it too will also be the same, but you have said numerous times that it does not correctly simulate the behaviour.
> >
> It is an easily verified fact that H(P,P) correctly simulates its input
> to everyone having sufficient knowledge of the x86 assembly language
> which currently seems to be hardy no one besides me. Back in the 1986
> when I began my career about 10% of all programmers had familiarity
> with the x86 language. This is the language that MSDOS and versions
> of MS Windows prior to Windows NT were written in. Windows NT switched
> to mostly C/C++.

No it is not. Firstly, you have never posted the code to H so of course we can't verify it. Furthermore, you yourself claim that the simulation gives different results from the actual code (you even describe this as "provably" on occasion) so you yourself do not believe that H(P,P) correctly simulates its input.

> The 23 emails that I had with a leading computer scientist made that
> very clear. Because of this I re-framed my explanation so that any
> expert C programmer that totally understands infinite recursion would be
> able to see that infinitely nested simulation is essentially the same
> thing.

It might move the conversation on if you showed us what the computer scientist said - most helpfully if you quoted verbatim, but you could paraphrase if you're worried about confidentiality or the like. I take it there was more to it than them saying why you were wrong, and you saying that they didn't understand?

> The next important point that requires one to have top software
> engineering skills that allowed me to transform H into a pure thus
> computable function: Infinitely nested simulation can be detected the
> first time that the simulated input calls the simulator with its same
> arguments. Infinite recursion requires seeing two such calls in a row.
> This change allowed me to discard the need for static local memory and
> do everything in local memory.
> >> A security guard at the front door is only required to validate people
> >> coming in the front door the actual behavior of the actual input to H(P,P).
> >>
> >> This same security guard is not required to validate people coming in
> >> the back door the direct execution of P(P). Unless a computation is
> >> specified as an actual input to H it is not in the domain of the
> >> computable function that H implements.
> >
> > H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.

> No this a very long standing misconception. H is required to determine
> whether or not its correct simulation of its input would ever reach the
> normal termination of this input.

No, what I have said is right. You are the one bringing in ideas about simulation.

> Since no one ever bothered to think through the application of a
> simulating halt decider to the HP's impossible inputs they always stated
> the requirements incorrectly never realizing their mistake.

> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.

Yes.

> In the H/P concrete example it is easily proven that the actual behavior
> of the actual input to H(P,P) is not the behavior of the directly
> executed P(P). The best proof of this is the x86 execution trace of each
> that precisely corresponds to what the x86 source code of P specifies.

You've included the word "actual" twice in that sentence and yet you still seem to think that the actual behaviour is not what really happens. How many "actual"s do you need?

> From this is is obvious that the correctly simulated P cannot possibly
> terminate normally and the executed P(P) halts.

If P(P) halts then a correct simulation of it will also halt.

> Those lacking knowledge of the x86 language can understand that this
> first halt deciding principle is necessarily correct:
>
> *When this halt deciding principle understood to be correct*
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
> And this second halt deciding principle follows from the first one by
> logical necessity.
>
> *Then (by logical necessity) this implements that principle*
> Every simulating halt decider that correctly simulates its input until
> it correctly predicts that this simulated input would never terminate
> normally, correctly rejects this input as non-halting.
>
> >
> > If a program M would halt given input X, then H(M, X) is required to be non-zero.
> > If a program M would not halt given input X, then H(M, X) is required to be zero.
> >
> This is a misconception that can only be true if the halt decider is
> required to report on something besides the actual behavior of its
> actual input.

On 7/14/2022 6:42 AM, Paul N wrote:
> On Wednesday, July 13, 2022 at 8:37:13 PM UTC+1, olcott wrote:
>> On 7/13/2022 1:03 PM, Paul N wrote:
>>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
>>>> On 7/13/2022 10:02 AM, Paul N wrote:
>>>>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.
>>>>>
>>>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
>>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
>>>>>>
>>>>>> I rewrote this question so that a software engineer of ordinary skill
>>>>>> can easily verify that the simulated P does call H in what is
>>>>>> essentially infinite recursion. **This simplification is the result of
>>>>>> an extensive review (23 emails) by a leading computer scientist over the
>>>>>> weekend.**
>>>>>
>>>>>> Does H(P,P) correctly determine the halt status of the halting problem's
>>>>>> pathological input?
>>>>>
>>>>>> The following H and P have the above specified pathological relationship
>>>>>> to each other.
>>>>>>
>>>>>> typedef void (*ptr)();
>>>>>> int H(ptr p, ptr i);
>>>>>>
>>>>>> void P(ptr x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>> }
>>>>>>
>>>>>> Simulating halt decider H detects that its simulated input is
>>>>>> essentially calling H in infinite recursion. H aborts its simulation on
>>>>>> this basis and rejects this input as non-halting.
>>>>>
>>>>> Thus it is an incorrect assessment, as we'll see below.
>>>>>
>>>>>> *Once this halt deciding principle is accepted*
>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>> specified by these inputs.
>>>>>
>>>>> Again, emphasis on "actual behaviour".
>>>>>
>>>>>> *Then (by logical necessity) this is understood to implement that*
>>>>>> Every simulating halt decider that correctly simulates its input until
>>>>>> it correctly predicts that this simulated input would never terminate
>>>>>> normally, correctly rejects this input as non-halting.
>>>>>
>>>>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
>>>>>
>>>>>> *The execution trace of function P() simulated by function H() shows*
>>>>>> (1) Function H() is called from P().
>>>>>> (2) With the same parameters to H().
>>>>>> (3) With no instructions in P() that could possibly escape this
>>>>>> infinitely recursive simulation.
>>>>>
>>>>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
>>>>>
>>>>>> This proves that H(P,P) correctly predicts that its correctly simulated
>>>>>> input would never terminate normally.
>>>>>
>>>>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.
>>>> Welcome back.
>>>>
>>>> When H(P,P) correctly simulates its input this is the ultimate measure
>>>> of the actual behavior specified by this input.
>>>
>>> No, the actual behaviour is the actual behaviour! If H correctly simulates this behaviour then it too will also be the same, but you have said numerous times that it does not correctly simulate the behaviour.
>>>
>> It is an easily verified fact that H(P,P) correctly simulates its input
>> to everyone having sufficient knowledge of the x86 assembly language
>> which currently seems to be hardy no one besides me. Back in the 1986
>> when I began my career about 10% of all programmers had familiarity
>> with the x86 language. This is the language that MSDOS and versions
>> of MS Windows prior to Windows NT were written in. Windows NT switched
>> to mostly C/C++.
>
> No it is not. Firstly, you have never posted the code to H so of course we can't verify it.

The latest rewrite of my paper (initially written as a reply to you) can
be fully understood at the C level with no need to have any access to
the source-code of H. I will publish all the the source-code very soon,
yet not until after my work has been validated.

The source-code is correct and complete yet must be refactored to clean
it up before publication.

*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

> Furthermore, you yourself claim that the simulation gives different results from the actual code (you even describe this as "provably" on occasion) so you yourself do not believe that H(P,P) correctly simulates its input.

This is also much more clearly shown in the rewrite of my paper that I
did a few minutes ago. It can now be seen at the C level that the
simulation of the input to H(P,P) is correct.

It was very easy to see that the simulation of the input to H(P,P) is
correct by simply matching the execution trace of the simulated P to its
x86 source code. I annotated the x86 source-code to make this much
easier for C programmers. I explain line-by-line exactly how the x86
code corresponds to its C source.

>
>> The 23 emails that I had with a leading computer scientist made that
>> very clear. Because of this I re-framed my explanation so that any
>> expert C programmer that totally understands infinite recursion would be
>> able to see that infinitely nested simulation is essentially the same
>> thing.
>
> It might move the conversation on if you showed us what the computer scientist said - most helpfully if you quoted verbatim, but you could paraphrase if you're worried about confidentiality or the like. I take it there was more to it than them saying why you were wrong, and you saying that they didn't understand?

This would be disrespecting his privacy. The point is that I now have an
excellent measure that I have improved my words so much that my work is
not simply rejected out-of-hand without review even by leading computer
scientists.

>> The next important point that requires one to have top software
>> engineering skills that allowed me to transform H into a pure thus
>> computable function: Infinitely nested simulation can be detected the
>> first time that the simulated input calls the simulator with its same
>> arguments. Infinite recursion requires seeing two such calls in a row.
>> This change allowed me to discard the need for static local memory and
>> do everything in local memory.
>>>> A security guard at the front door is only required to validate people
>>>> coming in the front door the actual behavior of the actual input to H(P,P).
>>>>
>>>> This same security guard is not required to validate people coming in
>>>> the back door the direct execution of P(P). Unless a computation is
>>>> specified as an actual input to H it is not in the domain of the
>>>> computable function that H implements.
>>>
>>> H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
>
>> No this a very long standing misconception. H is required to determine
>> whether or not its correct simulation of its input would ever reach the
>> normal termination of this input.
>
> No, what I have said is right. You are the one bringing in ideas about simulation.
>

On 7/14/22 3:56 PM, olcott wrote:
> On 7/14/2022 6:42 AM, Paul N wrote:
>> On Wednesday, July 13, 2022 at 8:37:13 PM UTC+1, olcott wrote:
>>> On 7/13/2022 1:03 PM, Paul N wrote:
>>>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
>>>>> On 7/13/2022 10:02 AM, Paul N wrote:
>>>>>> Firstly, this subject matter is not relevant in comp.lang.c or
>>>>>> comp.lang.c++, so please stop posting any of it there. If I see
>>>>>> any more posts of this sort in either of those newsgroups I shall
>>>>>> assume that, regardless of the merits of your argument, you are
>>>>>> very rude.
>>>>>>
>>>>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
>>>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
>>>>>>>
>>>>>>> I rewrote this question so that a software engineer of ordinary
>>>>>>> skill
>>>>>>> can easily verify that the simulated P does call H in what is
>>>>>>> essentially infinite recursion. **This simplification is the
>>>>>>> result of
>>>>>>> an extensive review (23 emails) by a leading computer scientist
>>>>>>> over the
>>>>>>> weekend.**
>>>>>>
>>>>>>> Does H(P,P) correctly determine the halt status of the halting
>>>>>>> problem's
>>>>>>> pathological input?
>>>>>>
>>>>>>> The following H and P have the above specified pathological
>>>>>>> relationship
>>>>>>> to each other.
>>>>>>>
>>>>>>> typedef void (*ptr)();
>>>>>>> int H(ptr p, ptr i);
>>>>>>>
>>>>>>> void P(ptr x)
>>>>>>> {
>>>>>>> if (H(x, x))
>>>>>>> HERE: goto HERE;
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>> }
>>>>>>>
>>>>>>> Simulating halt decider H detects that its simulated input is
>>>>>>> essentially calling H in infinite recursion. H aborts its
>>>>>>> simulation on
>>>>>>> this basis and rejects this input as non-halting.
>>>>>>
>>>>>> Thus it is an incorrect assessment, as we'll see below.
>>>>>>
>>>>>>> *Once this halt deciding principle is accepted*
>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>> accept or
>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>> specified by these inputs.
>>>>>>
>>>>>> Again, emphasis on "actual behaviour".
>>>>>>
>>>>>>> *Then (by logical necessity) this is understood to implement that*
>>>>>>> Every simulating halt decider that correctly simulates its input
>>>>>>> until
>>>>>>> it correctly predicts that this simulated input would never
>>>>>>> terminate
>>>>>>> normally, correctly rejects this input as non-halting.
>>>>>>
>>>>>> You have stated numerous times that a program that "correctly
>>>>>> simulates its input" can have different results. Thus it is not
>>>>>> clear what you mean by the phrase. There is no logical necessity
>>>>>> to accept anything about a correct simulation which does not
>>>>>> simulate correctly.
>>>>>>
>>>>>>> *The execution trace of function P() simulated by function H()
>>>>>>> shows*
>>>>>>> (1) Function H() is called from P().
>>>>>>> (2) With the same parameters to H().
>>>>>>> (3) With no instructions in P() that could possibly escape this
>>>>>>> infinitely recursive simulation.
>>>>>>
>>>>>> Ah, but there are instructions in H which escape from the infinite
>>>>>> recursion. You've said numerous times that there are. See only a
>>>>>> few lines up. If you pretend that they are somehow not there, you
>>>>>> are not correctly simulating H and hence not correctly simulating
>>>>>> P which calls it.
>>>>>>
>>>>>>> This proves that H(P,P) correctly predicts that its correctly
>>>>>>> simulated
>>>>>>> input would never terminate normally.
>>>>>>
>>>>>> As you've said above, in capitals and with asterisks, changing the
>>>>>> subject is not a rebuttal. You're trying to change the subject
>>>>>> from the actual behaviour of P(P) to some sort of "simulated"
>>>>>> behaviour of P(P) which you have said yourself is different.
>>>>> Welcome back.
>>>>>
>>>>> When H(P,P) correctly simulates its input this is the ultimate measure
>>>>> of the actual behavior specified by this input.
>>>>
>>>> No, the actual behaviour is the actual behaviour! If H correctly
>>>> simulates this behaviour then it too will also be the same, but you
>>>> have said numerous times that it does not correctly simulate the
>>>> behaviour.
>>>>
>>> It is an easily verified fact that H(P,P) correctly simulates its input
>>> to everyone having sufficient knowledge of the x86 assembly language
>>> which currently seems to be hardy no one besides me. Back in the 1986
>>> when I began my career about 10% of all programmers had familiarity
>>> with the x86 language. This is the language that MSDOS and versions
>>> of MS Windows prior to Windows NT were written in. Windows NT switched
>>> to mostly C/C++.
>>
>> No it is not. Firstly, you have never posted the code to H so of
>> course we can't verify it.
>
> The latest rewrite of my paper (initially written as a reply to you) can
> be fully understood at the C level with no need to have any access to
> the source-code of H. I will publish all the the source-code very soon,
> yet not until after my work has been validated.
>
> The source-code is correct and complete yet must be refactored to clean
> it up before publication.
>
> *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
>
>
>> Furthermore, you yourself claim that the simulation gives different
>> results from the actual code (you even describe this as "provably" on
>> occasion) so you yourself do not believe that H(P,P) correctly
>> simulates its input.
>
> This is also much more clearly shown in the rewrite of my paper that I
> did a few minutes ago. It can now be seen at the C level that the
> simulation of the input to H(P,P) is correct.
>
> It was very easy to see that the simulation of the input to H(P,P) is
> correct by simply matching the execution trace of the simulated P to its
> x86 source code. I annotated the x86 source-code to make this much
> easier for C programmers. I explain line-by-line exactly how the x86
> code corresponds to its C source.
>
>>
>>> The 23 emails that I had with a leading computer scientist made that
>>> very clear. Because of this I re-framed my explanation so that any
>>> expert C programmer that totally understands infinite recursion would be
>>> able to see that infinitely nested simulation is essentially the same
>>> thing.
>>
>> It might move the conversation on if you showed us what the computer
>> scientist said - most helpfully if you quoted verbatim, but you could
>> paraphrase if you're worried about confidentiality or the like. I take
>> it there was more to it than them saying why you were wrong, and you
>> saying that they didn't understand?
>
> This would be disrespecting his privacy. The point is that I now have an
> excellent measure that I have improved my words so much that my work is
> not simply rejected out-of-hand without review even by leading computer
> scientists.
>
>>> The next important point that requires one to have top software
>>> engineering skills that allowed me to transform H into a pure thus
>>> computable function: Infinitely nested simulation can be detected the
>>> first time that the simulated input calls the simulator with its same
>>> arguments. Infinite recursion requires seeing two such calls in a row.
>>> This change allowed me to discard the need for static local memory and
>>> do everything in local memory.
>>>>> A security guard at the front door is only required to validate people
>>>>> coming in the front door the actual behavior of the actual input to
>>>>> H(P,P).
>>>>>
>>>>> This same security guard is not required to validate people coming in
>>>>> the back door the direct execution of P(P). Unless a computation is
>>>>> specified as an actual input to H it is not in the domain of the
>>>>> computable function that H implements.
>>>>
>>>> H takes two arguments. The first is a program to be considered and
>>>> the second is the input that could be supplied to that program. H is
>>>> required to decide, correctly, whether the program would halt given
>>>> that input, ie whether M(X) would halt.
>>
>>> No this a very long standing misconception. H is required to determine
>>> whether or not its correct simulation of its input would ever reach the
>>> normal termination of this input.
>>
>> No, what I have said is right. You are the one bringing in ideas about
>> simulation.
>>
>
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
>
> It is common knowledge that a correct simulation of a program is a
> correct measure of the behavior of this program.
>
> If we accept that the behavior of the executed P(P) is the behavior that
> H must report on then we are saying that H must report on the behavior
> that is not the actual behavior of its actual input.
>
>>> Since no one ever bothered to think through the application of a
>>> simulating halt decider to the HP's impossible inputs they always stated
>>> the requirements incorrectly never realizing their mistake.
>>
>>> A halt decider must compute the mapping from its inputs to an accept or
>>> reject state on the basis of the actual behavior that is actually
>>> specified by these inputs.
>>
>> Yes.
>>
>>> In the H/P concrete example it is easily proven that the actual behavior
>>> of the actual input to H(P,P) is not the behavior of the directly
>>> executed P(P). The best proof of this is the x86 execution trace of each
>>> that precisely corresponds to what the x86 source code of P specifies.
>>
>> You've included the word "actual" twice in that sentence and yet you
>> still seem to think that the actual behaviour is not what really
>> happens. How many "actual"s do you need?
>>
>>>  From this is is obvious that the correctly simulated P cannot possibly
>>> terminate normally and the executed P(P) halts.
>>
>> If P(P) halts then a correct simulation of it will also halt.
>
> In the latest revision to my paper it is much more obvious that that
> actual behavior of the actual input is not the same as the behavior of
> the directly executed P(P).
>
> If H is required to report on the behavior of the direct execution of
> P(P) this forces H to report on something besides the actual behavior of
> its actual input.
>

On Thursday, 14 July 2022 at 08:10:56 UTC+8, olcott wrote:
> On 7/13/2022 4:11 PM, wij wrote:
> > On Thursday, 14 July 2022 at 04:51:25 UTC+8, olcott wrote:
> >> On 7/13/2022 3:47 PM, wij wrote:
> >>> On Thursday, 14 July 2022 at 03:37:13 UTC+8, olcott wrote:
> >>>> On 7/13/2022 1:03 PM, Paul N wrote:
> >>>>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
> >>>>>> On 7/13/2022 10:02 AM, Paul N wrote:
> >>>>>>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.
> >>>>>>>
> >>>>>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
> >>>>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
> >>>>>>>>
> >>>>>>>> I rewrote this question so that a software engineer of ordinary skill
> >>>>>>>> can easily verify that the simulated P does call H in what is
> >>>>>>>> essentially infinite recursion. **This simplification is the result of
> >>>>>>>> an extensive review (23 emails) by a leading computer scientist over the
> >>>>>>>> weekend.**
> >>>>>>>
> >>>>>>>> Does H(P,P) correctly determine the halt status of the halting problem's
> >>>>>>>> pathological input?
> >>>>>>>
> >>>>>>>> The following H and P have the above specified pathological relationship
> >>>>>>>> to each other.
> >>>>>>>>
> >>>>>>>> typedef void (*ptr)();
> >>>>>>>> int H(ptr p, ptr i);
> >>>>>>>>
> >>>>>>>> void P(ptr x)
> >>>>>>>> {
> >>>>>>>> if (H(x, x))
> >>>>>>>> HERE: goto HERE;
> >>>>>>>> return;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> int main()
> >>>>>>>> {
> >>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> Simulating halt decider H detects that its simulated input is
> >>>>>>>> essentially calling H in infinite recursion. H aborts its simulation on
> >>>>>>>> this basis and rejects this input as non-halting.
> >>>>>>>
> >>>>>>> Thus it is an incorrect assessment, as we'll see below.
> >>>>>>>
> >>>>>>>> *Once this halt deciding principle is accepted*
> >>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>>>> specified by these inputs.
> >>>>>>>
> >>>>>>> Again, emphasis on "actual behaviour".
> >>>>>>>
> >>>>>>>> *Then (by logical necessity) this is understood to implement that*
> >>>>>>>> Every simulating halt decider that correctly simulates its input until
> >>>>>>>> it correctly predicts that this simulated input would never terminate
> >>>>>>>> normally, correctly rejects this input as non-halting.
> >>>>>>>
> >>>>>>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
> >>>>>>>
> >>>>>>>> *The execution trace of function P() simulated by function H() shows*
> >>>>>>>> (1) Function H() is called from P().
> >>>>>>>> (2) With the same parameters to H().
> >>>>>>>> (3) With no instructions in P() that could possibly escape this
> >>>>>>>> infinitely recursive simulation.
> >>>>>>>
> >>>>>>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
> >>>>>>>
> >>>>>>>> This proves that H(P,P) correctly predicts that its correctly simulated
> >>>>>>>> input would never terminate normally.
> >>>>>>>
> >>>>>>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.
> >>>>>> Welcome back.
> >>>>>>
> >>>>>> When H(P,P) correctly simulates its input this is the ultimate measure
> >>>>>> of the actual behavior specified by this input.
> >>>>>
> >>>>> No, the actual behaviour is the actual behaviour! If H correctlky simulates this behaviour then it too will also be the same, but you have siad numerous times that it does not correctly simulate the behavoutr.
> >>>>>
> >>>> It is an easily verified fact that H(P,P) correctly simulates its input
> >>>> to everyone having sufficient knowledge of the x86 assembly language
> >>>> which currently seems to be hardy no one besides me. Back in the 1986
> >>>> when I began my career about 10% of all programmers had familiarity
> >>>> with the x86 language. This is the language that MSDOS and versions
> >>>> of MS Windows prior to Windows NT were written in. Windows NT switched
> >>>> to mostly C/C++.
> >>>>
> >>>> The 23 emails that I had with a leading computer scientist made that
> >>>> very clear. Because of this I re-framed my explanation so that any
> >>>> expert C programmer that totally understands infinite recursion would be
> >>>> able to see that infinitely nested simulation is essentially the same
> >>>> thing.
> >>>>
> >>>> The next important point that requires one to have top software
> >>>> engineering skills that allowed me to transform H into a pure thus
> >>>> computable function: Infinitely nested simulation can be detected the
> >>>> first time that the simulated input calls the simulator with its same
> >>>> arguments. Infinite recursion requires seeing two such calls in a row.
> >>>> This change allowed me to discard the need for static local memory and
> >>>> do everything in local memory.
> >>>>>> A security guard at the front door is only required to validate people
> >>>>>> coming in the front door the actual behavior of the actual input to H(P,P).
> >>>>>>
> >>>>>> This same security guard is not required to validate people coming in
> >>>>>> the back door the direct execution of P(P). Unless a computation is
> >>>>>> specified as an actual input to H it is not in the domain of the
> >>>>>> computable function that H implements.
> >>>>>
> >>>>> H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
> >>>> No this a very long standing misconception. H is required to determine
> >>>> whether or not its correct simulation of its input would ever reach the
> >>>> normal termination of this input.
> >>>>
> >>>> Since no one ever bothered to think through the application of a
> >>>> simulating halt decider to the HP's impossible inputs they always stated
> >>>> the requirements incorrectly never realizing their mistake.
> >>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>> reject state on the basis of the actual behavior that is actually
> >>>> specified by these inputs.
> >>>> In the H/P concrete example it is easily proven that the actual behavior
> >>>> of the actual input to H(P,P) is not the behavior of the directly
> >>>> executed P(P). The best proof of this is the x86 execution trace of each
> >>>> that precisely corresponds to what the x86 source code of P specifies.
> >>>>
> >>>> From this is is obvious that the correctly simulated P cannot possibly
> >>>> terminate normally and the executed P(P) halts.
> >>>>
> >>>> Those lacking knowledge of the x86 language can understand that this
> >>>> first halt deciding principle is necessarily correct:
> >>>>
> >>>> *When this halt deciding principle understood to be correct*
> >>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>> reject state on the basis of the actual behavior that is actually
> >>>> specified by these inputs.
> >>>> And this second halt deciding principle follows from the first one by
> >>>> logical necessity.
> >>>>
> >>>> *Then (by logical necessity) this implements that principle*
> >>>> Every simulating halt decider that correctly simulates its input until
> >>>> it correctly predicts that this simulated input would never terminate
> >>>> normally, correctly rejects this input as non-halting.
> >>>>
> >>>>>
> >>>>> If a program M would halt given input X, then H(M, X) is required to be non-zero.
> >>>>> If a program M would not halt given input X, then H(M, X) is required to be zero.
> >>>>>
> >>>> This is a misconception that can only be true if the halt decider is
> >>>> required to report on something besides the actual behavior of its
> >>>> actual input.
> >>>>
> >>>> The ultimate measure of the actual behavior of the actual input is the
> >>>> provable correct simulation of this input by the simulating halt decider.
> >>>>
> >>>> To assume that this behavior must be the same as the directly executed
> >>>> P(P) after it has been conclusively proven to not be that same as an
> >>>> established fact is at least a little nutty.
> >>>>
> >>>> That people unequivocally state that I must be wrong entirely on the
> >>>> basis that they lack sufficient understanding of the x86 language to
> >>>> understand my proof is a worst case example of the ad ignorantiam logic
> >>>> error.
> >>>>> If for some combination M, X the function H(M, X) gives the wrong answer, then it is not a halt decider. If particular, if H(M, X) = 0 but M(X) does halt, then the answer is wrong. You can't get out of it by arguing that M(X) is "direct" and H(M, X) is a "correct simulation", whatever that might mean. The answer needs to relate to the actual behaviour, as you yourself have said numerous times.
> >>>>>
> >>>>> Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does not halt, H(P, P) is required to be zero. Anything else is the wrong answer.
> >>>>>
> >>>>> When we calculate H(P, P), we are supplying P as the first argument and so P is specified as an actual input to H. And we are interested in the actual behaviour of P, the actual input. There is no "back door" by which you can say that P(P) is not the function and input we are talking about.
> >>>>>
> >>>>>>> To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:
> >>>>>>>
> >>>>>>> A) H(P, P) returns 0 and P(P) terminates.
> >>>>>>> B) H(P, P) returns non-zero and P(P) terminates.
> >>>>>>> C) H(P, P) returns 0 and P(P) does not terminate.
> >>>>>>> D) H(P, P) returns non-zero and P(P) does not terminate.
> >>>>>>>
> >>>>>>> B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.
> >>>>>
> >>>>>> A1) H(P, P) returns 0 because it correctly determines that the input
> >>>>>> that it correctly simulates would never terminate normally.
> >>>>>
> >>>>> No, that is not a correct answer. You have said numerous times that P(P) terminates.
> >>>>>
> >>>>>> A2) Directly executed P(P) halts because of (A)
> >>>> --
> >>>> Copyright 2022 Pete Olcott
> >>>>
> >>>> "Talent hits a target no one else can hit;
> >>>> Genius hits a target no one else can see."
> >>>> Arthur Schopenhauer
> >>>
> >>> Halting problem https://en.wikipedia.org/wiki/Halting_problem
> >>> ...the halting problem is the problem of determining, from a description of an arbitrary
> >>> computer program and an input, whether the program will finish running, or continue to run forever.
> >>>
> >>> The property that an arbitrary program P will finish running or not is determined by
> >>> running P as an independent program
> >> Because that would require that a halt decider must sometimes make its
> >> halt status decision on a basis other than the actual behavior of its
> >> actual input that long standing misconception has been refuted.
> >> --
> >> Copyright 2022 Pete Olcott
> >>
> >> "Talent hits a target no one else can hit;
> >> Genius hits a target no one else can see."
> >> Arthur Schopenhauer
> >
> > Because we often encountered a problem to know whether a 'independent' running
> > program P will halt or not, therefore, this is an interested problem.
> > We don't have such a problem asking H(P,P), the P 'simulated' by H halt or not.
> >
>
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
> Everyone's rebuttal to this is that the halt decider must be a mind
> reader and report on the behavior of a computation that only exists in
> the minds of the readers and its not the same computation that is
> specified by its inputs.
>
> That is goofy and nutty and crazy.
> --
> 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 Thursday, July 14, 2022 at 8:56:21 PM UTC+1, olcott wrote:
> On 7/14/2022 6:42 AM, Paul N wrote:
> > On Wednesday, July 13, 2022 at 8:37:13 PM UTC+1, olcott wrote:
> >> On 7/13/2022 1:03 PM, Paul N wrote:
> >>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
> >>>> On 7/13/2022 10:02 AM, Paul N wrote:
> >>>>> Firstly, this subject matter is not relevant in comp.lang.c or comp..lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.

I see you have now started a new thread on this very subject in both comp.lang.c and comp.lang.c++. You clearly are very rude.

> >>>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
> >>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
> >>>>>>
> >>>>>> I rewrote this question so that a software engineer of ordinary skill
> >>>>>> can easily verify that the simulated P does call H in what is
> >>>>>> essentially infinite recursion. **This simplification is the result of
> >>>>>> an extensive review (23 emails) by a leading computer scientist over the
> >>>>>> weekend.**
> >>>>>
> >>>>>> Does H(P,P) correctly determine the halt status of the halting problem's
> >>>>>> pathological input?
> >>>>>
> >>>>>> The following H and P have the above specified pathological relationship
> >>>>>> to each other.
> >>>>>>
> >>>>>> typedef void (*ptr)();
> >>>>>> int H(ptr p, ptr i);
> >>>>>>
> >>>>>> void P(ptr x)
> >>>>>> {
> >>>>>> if (H(x, x))
> >>>>>> HERE: goto HERE;
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>> }
> >>>>>>
> >>>>>> Simulating halt decider H detects that its simulated input is
> >>>>>> essentially calling H in infinite recursion. H aborts its simulation on
> >>>>>> this basis and rejects this input as non-halting.
> >>>>>
> >>>>> Thus it is an incorrect assessment, as we'll see below.
> >>>>>
> >>>>>> *Once this halt deciding principle is accepted*
> >>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>> specified by these inputs.
> >>>>>
> >>>>> Again, emphasis on "actual behaviour".
> >>>>>
> >>>>>> *Then (by logical necessity) this is understood to implement that*
> >>>>>> Every simulating halt decider that correctly simulates its input until
> >>>>>> it correctly predicts that this simulated input would never terminate
> >>>>>> normally, correctly rejects this input as non-halting.
> >>>>>
> >>>>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
> >>>>>
> >>>>>> *The execution trace of function P() simulated by function H() shows*
> >>>>>> (1) Function H() is called from P().
> >>>>>> (2) With the same parameters to H().
> >>>>>> (3) With no instructions in P() that could possibly escape this
> >>>>>> infinitely recursive simulation.
> >>>>>
> >>>>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
> >>>>>
> >>>>>> This proves that H(P,P) correctly predicts that its correctly simulated
> >>>>>> input would never terminate normally.
> >>>>>
> >>>>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.
> >>>> Welcome back.
> >>>>
> >>>> When H(P,P) correctly simulates its input this is the ultimate measure
> >>>> of the actual behavior specified by this input.
> >>>
> >>> No, the actual behaviour is the actual behaviour! If H correctly simulates this behaviour then it too will also be the same, but you have said numerous times that it does not correctly simulate the behaviour.
> >>>
> >> It is an easily verified fact that H(P,P) correctly simulates its input
> >> to everyone having sufficient knowledge of the x86 assembly language
> >> which currently seems to be hardy no one besides me. Back in the 1986
> >> when I began my career about 10% of all programmers had familiarity
> >> with the x86 language. This is the language that MSDOS and versions
> >> of MS Windows prior to Windows NT were written in. Windows NT switched
> >> to mostly C/C++.
> >
> > No it is not. Firstly, you have never posted the code to H so of course we can't verify it.
> The latest rewrite of my paper (initially written as a reply to you) can
> be fully understood at the C level with no need to have any access to
> the source-code of H. I will publish all the the source-code very soon,
> yet not until after my work has been validated.
>
> The source-code is correct and complete yet must be refactored to clean
> it up before publication.
> *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
> > Furthermore, you yourself claim that the simulation gives different results from the actual code (you even describe this as "provably" on occasion) so you yourself do not believe that H(P,P) correctly simulates its input.
> This is also much more clearly shown in the rewrite of my paper that I
> did a few minutes ago. It can now be seen at the C level that the
> simulation of the input to H(P,P) is correct.
>
> It was very easy to see that the simulation of the input to H(P,P) is
> correct by simply matching the execution trace of the simulated P to its
> x86 source code. I annotated the x86 source-code to make this much
> easier for C programmers. I explain line-by-line exactly how the x86
> code corresponds to its C source.
> >
> >> The 23 emails that I had with a leading computer scientist made that
> >> very clear. Because of this I re-framed my explanation so that any
> >> expert C programmer that totally understands infinite recursion would be
> >> able to see that infinitely nested simulation is essentially the same
> >> thing.
> >
> > It might move the conversation on if you showed us what the computer scientist said - most helpfully if you quoted verbatim, but you could paraphrase if you're worried about confidentiality or the like. I take it there was more to it than them saying why you were wrong, and you saying that they didn't understand?
> This would be disrespecting his privacy. The point is that I now have an
> excellent measure that I have improved my words so much that my work is
> not simply rejected out-of-hand without review even by leading computer
> scientists.
> >> The next important point that requires one to have top software
> >> engineering skills that allowed me to transform H into a pure thus
> >> computable function: Infinitely nested simulation can be detected the
> >> first time that the simulated input calls the simulator with its same
> >> arguments. Infinite recursion requires seeing two such calls in a row.
> >> This change allowed me to discard the need for static local memory and
> >> do everything in local memory.
> >>>> A security guard at the front door is only required to validate people
> >>>> coming in the front door the actual behavior of the actual input to H(P,P).
> >>>>
> >>>> This same security guard is not required to validate people coming in
> >>>> the back door the direct execution of P(P). Unless a computation is
> >>>> specified as an actual input to H it is not in the domain of the
> >>>> computable function that H implements.
> >>>
> >>> H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
> >
> >> No this a very long standing misconception. H is required to determine
> >> whether or not its correct simulation of its input would ever reach the
> >> normal termination of this input.
> >
> > No, what I have said is right. You are the one bringing in ideas about simulation.
> >
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
> It is common knowledge that a correct simulation of a program is a
> correct measure of the behavior of this program.
>
> If we accept that the behavior of the executed P(P) is the behavior that
> H must report on then we are saying that H must report on the behavior
> that is not the actual behavior of its actual input.
> >> Since no one ever bothered to think through the application of a
> >> simulating halt decider to the HP's impossible inputs they always stated
> >> the requirements incorrectly never realizing their mistake.
> >
> >> A halt decider must compute the mapping from its inputs to an accept or
> >> reject state on the basis of the actual behavior that is actually
> >> specified by these inputs.
> >
> > Yes.
> >
> >> In the H/P concrete example it is easily proven that the actual behavior
> >> of the actual input to H(P,P) is not the behavior of the directly
> >> executed P(P). The best proof of this is the x86 execution trace of each
> >> that precisely corresponds to what the x86 source code of P specifies.
> >
> > You've included the word "actual" twice in that sentence and yet you still seem to think that the actual behaviour is not what really happens. How many "actual"s do you need?
> >
> >> From this is is obvious that the correctly simulated P cannot possibly
> >> terminate normally and the executed P(P) halts.
> >
> > If P(P) halts then a correct simulation of it will also halt.
> In the latest revision to my paper it is much more obvious that that
> actual behavior of the actual input is not the same as the behavior of
> the directly executed P(P).

On 7/15/2022 4:20 AM, wij wrote:
> On Thursday, 14 July 2022 at 08:10:56 UTC+8, olcott wrote:
>> On 7/13/2022 4:11 PM, wij wrote:
>>> On Thursday, 14 July 2022 at 04:51:25 UTC+8, olcott wrote:
>>>> On 7/13/2022 3:47 PM, wij wrote:
>>>>> On Thursday, 14 July 2022 at 03:37:13 UTC+8, olcott wrote:
>>>>>> On 7/13/2022 1:03 PM, Paul N wrote:
>>>>>>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
>>>>>>>> On 7/13/2022 10:02 AM, Paul N wrote:
>>>>>>>>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.
>>>>>>>>>
>>>>>>>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
>>>>>>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
>>>>>>>>>>
>>>>>>>>>> I rewrote this question so that a software engineer of ordinary skill
>>>>>>>>>> can easily verify that the simulated P does call H in what is
>>>>>>>>>> essentially infinite recursion. **This simplification is the result of
>>>>>>>>>> an extensive review (23 emails) by a leading computer scientist over the
>>>>>>>>>> weekend.**
>>>>>>>>>
>>>>>>>>>> Does H(P,P) correctly determine the halt status of the halting problem's
>>>>>>>>>> pathological input?
>>>>>>>>>
>>>>>>>>>> The following H and P have the above specified pathological relationship
>>>>>>>>>> to each other.
>>>>>>>>>>
>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>> int H(ptr p, ptr i);
>>>>>>>>>>
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>> if (H(x, x))
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Simulating halt decider H detects that its simulated input is
>>>>>>>>>> essentially calling H in infinite recursion. H aborts its simulation on
>>>>>>>>>> this basis and rejects this input as non-halting.
>>>>>>>>>
>>>>>>>>> Thus it is an incorrect assessment, as we'll see below.
>>>>>>>>>
>>>>>>>>>> *Once this halt deciding principle is accepted*
>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>> specified by these inputs.
>>>>>>>>>
>>>>>>>>> Again, emphasis on "actual behaviour".
>>>>>>>>>
>>>>>>>>>> *Then (by logical necessity) this is understood to implement that*
>>>>>>>>>> Every simulating halt decider that correctly simulates its input until
>>>>>>>>>> it correctly predicts that this simulated input would never terminate
>>>>>>>>>> normally, correctly rejects this input as non-halting.
>>>>>>>>>
>>>>>>>>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
>>>>>>>>>
>>>>>>>>>> *The execution trace of function P() simulated by function H() shows*
>>>>>>>>>> (1) Function H() is called from P().
>>>>>>>>>> (2) With the same parameters to H().
>>>>>>>>>> (3) With no instructions in P() that could possibly escape this
>>>>>>>>>> infinitely recursive simulation.
>>>>>>>>>
>>>>>>>>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
>>>>>>>>>
>>>>>>>>>> This proves that H(P,P) correctly predicts that its correctly simulated
>>>>>>>>>> input would never terminate normally.
>>>>>>>>>
>>>>>>>>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.
>>>>>>>> Welcome back.
>>>>>>>>
>>>>>>>> When H(P,P) correctly simulates its input this is the ultimate measure
>>>>>>>> of the actual behavior specified by this input.
>>>>>>>
>>>>>>> No, the actual behaviour is the actual behaviour! If H correctlky simulates this behaviour then it too will also be the same, but you have siad numerous times that it does not correctly simulate the behavoutr.
>>>>>>>
>>>>>> It is an easily verified fact that H(P,P) correctly simulates its input
>>>>>> to everyone having sufficient knowledge of the x86 assembly language
>>>>>> which currently seems to be hardy no one besides me. Back in the 1986
>>>>>> when I began my career about 10% of all programmers had familiarity
>>>>>> with the x86 language. This is the language that MSDOS and versions
>>>>>> of MS Windows prior to Windows NT were written in. Windows NT switched
>>>>>> to mostly C/C++.
>>>>>>
>>>>>> The 23 emails that I had with a leading computer scientist made that
>>>>>> very clear. Because of this I re-framed my explanation so that any
>>>>>> expert C programmer that totally understands infinite recursion would be
>>>>>> able to see that infinitely nested simulation is essentially the same
>>>>>> thing.
>>>>>>
>>>>>> The next important point that requires one to have top software
>>>>>> engineering skills that allowed me to transform H into a pure thus
>>>>>> computable function: Infinitely nested simulation can be detected the
>>>>>> first time that the simulated input calls the simulator with its same
>>>>>> arguments. Infinite recursion requires seeing two such calls in a row.
>>>>>> This change allowed me to discard the need for static local memory and
>>>>>> do everything in local memory.
>>>>>>>> A security guard at the front door is only required to validate people
>>>>>>>> coming in the front door the actual behavior of the actual input to H(P,P).
>>>>>>>>
>>>>>>>> This same security guard is not required to validate people coming in
>>>>>>>> the back door the direct execution of P(P). Unless a computation is
>>>>>>>> specified as an actual input to H it is not in the domain of the
>>>>>>>> computable function that H implements.
>>>>>>>
>>>>>>> H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
>>>>>> No this a very long standing misconception. H is required to determine
>>>>>> whether or not its correct simulation of its input would ever reach the
>>>>>> normal termination of this input.
>>>>>>
>>>>>> Since no one ever bothered to think through the application of a
>>>>>> simulating halt decider to the HP's impossible inputs they always stated
>>>>>> the requirements incorrectly never realizing their mistake.
>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>> specified by these inputs.
>>>>>> In the H/P concrete example it is easily proven that the actual behavior
>>>>>> of the actual input to H(P,P) is not the behavior of the directly
>>>>>> executed P(P). The best proof of this is the x86 execution trace of each
>>>>>> that precisely corresponds to what the x86 source code of P specifies.
>>>>>>
>>>>>> From this is is obvious that the correctly simulated P cannot possibly
>>>>>> terminate normally and the executed P(P) halts.
>>>>>>
>>>>>> Those lacking knowledge of the x86 language can understand that this
>>>>>> first halt deciding principle is necessarily correct:
>>>>>>
>>>>>> *When this halt deciding principle understood to be correct*
>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>> specified by these inputs.
>>>>>> And this second halt deciding principle follows from the first one by
>>>>>> logical necessity.
>>>>>>
>>>>>> *Then (by logical necessity) this implements that principle*
>>>>>> Every simulating halt decider that correctly simulates its input until
>>>>>> it correctly predicts that this simulated input would never terminate
>>>>>> normally, correctly rejects this input as non-halting.
>>>>>>
>>>>>>>
>>>>>>> If a program M would halt given input X, then H(M, X) is required to be non-zero.
>>>>>>> If a program M would not halt given input X, then H(M, X) is required to be zero.
>>>>>>>
>>>>>> This is a misconception that can only be true if the halt decider is
>>>>>> required to report on something besides the actual behavior of its
>>>>>> actual input.
>>>>>>
>>>>>> The ultimate measure of the actual behavior of the actual input is the
>>>>>> provable correct simulation of this input by the simulating halt decider.
>>>>>>
>>>>>> To assume that this behavior must be the same as the directly executed
>>>>>> P(P) after it has been conclusively proven to not be that same as an
>>>>>> established fact is at least a little nutty.
>>>>>>
>>>>>> That people unequivocally state that I must be wrong entirely on the
>>>>>> basis that they lack sufficient understanding of the x86 language to
>>>>>> understand my proof is a worst case example of the ad ignorantiam logic
>>>>>> error.
>>>>>>> If for some combination M, X the function H(M, X) gives the wrong answer, then it is not a halt decider. If particular, if H(M, X) = 0 but M(X) does halt, then the answer is wrong. You can't get out of it by arguing that M(X) is "direct" and H(M, X) is a "correct simulation", whatever that might mean. The answer needs to relate to the actual behaviour, as you yourself have said numerous times.
>>>>>>>
>>>>>>> Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does not halt, H(P, P) is required to be zero. Anything else is the wrong answer.
>>>>>>>
>>>>>>> When we calculate H(P, P), we are supplying P as the first argument and so P is specified as an actual input to H. And we are interested in the actual behaviour of P, the actual input. There is no "back door" by which you can say that P(P) is not the function and input we are talking about.
>>>>>>>
>>>>>>>>> To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:
>>>>>>>>>
>>>>>>>>> A) H(P, P) returns 0 and P(P) terminates.
>>>>>>>>> B) H(P, P) returns non-zero and P(P) terminates.
>>>>>>>>> C) H(P, P) returns 0 and P(P) does not terminate.
>>>>>>>>> D) H(P, P) returns non-zero and P(P) does not terminate.
>>>>>>>>>
>>>>>>>>> B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.
>>>>>>>
>>>>>>>> A1) H(P, P) returns 0 because it correctly determines that the input
>>>>>>>> that it correctly simulates would never terminate normally.
>>>>>>>
>>>>>>> No, that is not a correct answer. You have said numerous times that P(P) terminates.
>>>>>>>
>>>>>>>> A2) Directly executed P(P) halts because of (A)
>>>>>> --
>>>>>> Copyright 2022 Pete Olcott
>>>>>>
>>>>>> "Talent hits a target no one else can hit;
>>>>>> Genius hits a target no one else can see."
>>>>>> Arthur Schopenhauer
>>>>>
>>>>> Halting problem https://en.wikipedia.org/wiki/Halting_problem
>>>>> ...the halting problem is the problem of determining, from a description of an arbitrary
>>>>> computer program and an input, whether the program will finish running, or continue to run forever.
>>>>>
>>>>> The property that an arbitrary program P will finish running or not is determined by
>>>>> running P as an independent program
>>>> Because that would require that a halt decider must sometimes make its
>>>> halt status decision on a basis other than the actual behavior of its
>>>> actual input that long standing misconception has been refuted.
>>>> --
>>>> Copyright 2022 Pete Olcott
>>>>
>>>> "Talent hits a target no one else can hit;
>>>> Genius hits a target no one else can see."
>>>> Arthur Schopenhauer
>>>
>>> Because we often encountered a problem to know whether a 'independent' running
>>> program P will halt or not, therefore, this is an interested problem.
>>> We don't have such a problem asking H(P,P), the P 'simulated' by H halt or not.
>>>
>>
>> A halt decider must compute the mapping from its inputs to an accept or
>> reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>> Everyone's rebuttal to this is that the halt decider must be a mind
>> reader and report on the behavior of a computation that only exists in
>> the minds of the readers and its not the same computation that is
>> specified by its inputs.
>>
>> That is goofy and nutty and crazy.
>> --
>> Copyright 2022 Pete Olcott
>>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer
>
> So, you are perfect aware you are not talking about the HP. But we are only
> interested in such a halt decider H (and GUR) that:
> H(P,P)=1 iff P(P) halts.
> H(P,P)=0 iff P(P) does not halts.
>
> No one care about your POOH.
>
> If you like to reason, sorry, you are an idiot, incapable of logic reasoning.
> Most of all, extremely cheeky, spit-able, stone-able.