On Mon, 13 Jun 2022 15:14:48 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/13/2022 3:07 PM, Mr Flibble wrote:
> > On Mon, 13 Jun 2022 14:47:16 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/13/2022 2:29 PM, Mr Flibble wrote:
> >>> On Mon, 13 Jun 2022 14:25:47 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/13/2022 2:12 PM, Mr Flibble wrote:
> >>>>> On Mon, 13 Jun 2022 13:25:50 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 6/13/2022 1:07 PM, Mr Flibble wrote:
> >>>>>>> On Mon, 13 Jun 2022 12:51:08 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
> >>>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
> >>>>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
> >>>>>>>>>>>> *The criterion measure for a simulating halt decider SHD*
> >>>>>>>>>>>> When the correct partial simulation of the input matches
> >>>>>>>>>>>> a non-halting behavior pattern such that it can be
> >>>>>>>>>>>> correctly determined that a correct and complete
> >>>>>>>>>>>> simulation of the input would never stop running, or
> >>>>>>>>>>>> reach the final state of this input then the SHD aborts
> >>>>>>>>>>>> its simulation and returns 0.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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
> >>>>>>>>>>>>
> >>>>>>>>>>>> *H and P match the above halting problem relationship to
> >>>>>>>>>>>> each other*
> >>>>>>>>>>>>
> >>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>> {
> >>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>> return;
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> int main()
> >>>>>>>>>>>> {
> >>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> _P()
> >>>>>>>>>>>> [00001352](01) 55 push ebp
> >>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
> >>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>> [00001358](01) 50 push eax // push P
> >>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
> >>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
> >>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
> >>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
> >>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
> >>>>>>>>>>>> [0000136b](01) 5d pop ebp
> >>>>>>>>>>>> [0000136c](01) c3 ret
> >>>>>>>>>>>> Size in bytes:(0027) [0000136c]
> >>>>>>>>>>>>
> >>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
> >>>>>>>>>>>> emulates its input that it must emulate the first seven
> >>>>>>>>>>>> instructions of P. Because the seventh instruction of P
> >>>>>>>>>>>> repeats this process we can know with complete certainty
> >>>>>>>>>>>> that the emulated P never reaches its final “ret”
> >>>>>>>>>>>> instruction, thus never halts.
> >>>>>>>>>>> So your case is that you have dry run P(P) and determined
> >>>>>>>>>>> that it never halts. Additionally H(P,P) reports
> >>>>>>>>>>> non-halting. Therefore you conclude that H is correct.
> >>>>>>>>>>
> >>>>>>>>>> In the above case when H(P,P) partially emulates its input
> >>>>>>>>>> it correctly determines that a correct and complete
> >>>>>>>>>> emulation of its input would never stop running or reach
> >>>>>>>>>> the "ret" instruction of P. Instead it would be stuck in
> >>>>>>>>>> infinitely recursive emulation.
> >>>>>>>>>>
> >>>>>>>>>> I have updated the algorithm so that it is a pure function
> >>>>>>>>>> of its inputs. As soon as P calls H for the first time, H
> >>>>>>>>>> (knowing its own machine address) is able to look though
> >>>>>>>>>> the prior execution trace and see that P is calling H with
> >>>>>>>>>> the same arguments that it was called with and there are no
> >>>>>>>>>> instructions in P that would break this cycle.
> >>>>>>>>>
> >>>>>>>>> Naive.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> The last paragraph has been extensively reviewed and
> >>>>>>>> validated on another forum, thus saying that it is simply
> >>>>>>>> Naive carries zero weight.
> >>>>>>>>
> >>>>>>>> The only way that the last paragraph can be rebutted is to
> >>>>>>>> find a counter-example that proves it to be incorrect.
> >>>>>>>
> >>>>>>> Publish your algorithm which determines that there are no
> >>>>>>> instructions in P that would break the cycle.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _P()
> >>>>>> [00001352](01) 55 push ebp
> >>>>>> [00001353](02) 8bec mov ebp,esp
> >>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>>>> [00001358](01) 50 push eax // push P
> >>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>> [0000135c](01) 51 push ecx // push P
> >>>>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>>>> [00001362](03) 83c408 add esp,+08
> >>>>>> [00001365](02) 85c0 test eax,eax
> >>>>>> [00001367](02) 7402 jz 0000136b
> >>>>>> [00001369](02) ebfe jmp 00001369
> >>>>>> [0000136b](01) 5d pop ebp
> >>>>>> [0000136c](01) c3 ret
> >>>>>> Size in bytes:(0027) [0000136c]
> >>>>>
> >>>>> That is a trace of P, it is not an algorithm which determines
> >>>>> that there are no instructions in P that would break the cycle.
> >>>>> Publish the source code of your algorithm.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> Because everyone can see that above first seven instructions of P
> >>>> provide no means for the emulated input to H(P,P) to break out of
> >>>> repeated x86 emulations your request for code that recognizes
> >>>> this is merely playing head games.
> >>>
> >>> You've got nothing.
> >>>
> >>> /Flibble
> >>>
> >>
> >> Every competent software engineer can very easily tell that it
> >> would be very easy to write a program that examines the correct x86
> >> emulation of the above P to determine that P cannot break out of
> >> its recursive emulation.
> >>
> >> That you imply that this cannot be correctly determined without
> >> actually seeing the code that does this can't reasonably be
> >> construed as any honest mistake.
> >
> > Are you pattern matching x86 opcodes "EB FE" or not? Publish source
> > code so we don't have to guess.
> >
> > /Flibble
> >
>
> The only actual relevant question is this:
> Is it possible or impossible for an algorithm to correctly determine
> that the correctly emulated input to H(P,P) never halts?
>
> If it is possible then H(P,P)==0 is proven to be correct.
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00001352](01) 55 push ebp
> [00001353](02) 8bec mov ebp,esp
> [00001355](03) 8b4508 mov eax,[ebp+08]
> [00001358](01) 50 push eax // push P
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx // push P
> [0000135d](05) e840feffff call 000011a2 // call H
> [00001362](03) 83c408 add esp,+08
> [00001365](02) 85c0 test eax,eax
> [00001367](02) 7402 jz 0000136b
> [00001369](02) ebfe jmp 00001369
> [0000136b](01) 5d pop ebp
> [0000136c](01) c3 ret
> Size in bytes:(0027) [0000136c]
>
> It is completely obvious that when H(P,P) correctly emulates its
> input that it must emulate the first seven instructions of P. Because
> the seventh instruction of P repeats this process we can know with
> complete certainty that the emulated P never reaches its final “ret”
> instruction, thus never halts.

Click here to read the complete article

On 6/13/2022 3:50 PM, Mr Flibble wrote:
> On Mon, 13 Jun 2022 15:14:48 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/13/2022 3:07 PM, Mr Flibble wrote:
>>> On Mon, 13 Jun 2022 14:47:16 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/13/2022 2:29 PM, Mr Flibble wrote:
>>>>> On Mon, 13 Jun 2022 14:25:47 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/13/2022 2:12 PM, Mr Flibble wrote:
>>>>>>> On Mon, 13 Jun 2022 13:25:50 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 6/13/2022 1:07 PM, Mr Flibble wrote:
>>>>>>>>> On Mon, 13 Jun 2022 12:51:08 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
>>>>>>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
>>>>>>>>>>>>>> *The criterion measure for a simulating halt decider SHD*
>>>>>>>>>>>>>> When the correct partial simulation of the input matches
>>>>>>>>>>>>>> a non-halting behavior pattern such that it can be
>>>>>>>>>>>>>> correctly determined that a correct and complete
>>>>>>>>>>>>>> simulation of the input would never stop running, or
>>>>>>>>>>>>>> reach the final state of this input then the SHD aborts
>>>>>>>>>>>>>> its simulation and returns 0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *H and P match the above halting problem relationship to
>>>>>>>>>>>>>> each other*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
>>>>>>>>>>>>>> emulates its input that it must emulate the first seven
>>>>>>>>>>>>>> instructions of P. Because the seventh instruction of P
>>>>>>>>>>>>>> repeats this process we can know with complete certainty
>>>>>>>>>>>>>> that the emulated P never reaches its final “ret”
>>>>>>>>>>>>>> instruction, thus never halts.
>>>>>>>>>>>>> So your case is that you have dry run P(P) and determined
>>>>>>>>>>>>> that it never halts. Additionally H(P,P) reports
>>>>>>>>>>>>> non-halting. Therefore you conclude that H is correct.
>>>>>>>>>>>>
>>>>>>>>>>>> In the above case when H(P,P) partially emulates its input
>>>>>>>>>>>> it correctly determines that a correct and complete
>>>>>>>>>>>> emulation of its input would never stop running or reach
>>>>>>>>>>>> the "ret" instruction of P. Instead it would be stuck in
>>>>>>>>>>>> infinitely recursive emulation.
>>>>>>>>>>>>
>>>>>>>>>>>> I have updated the algorithm so that it is a pure function
>>>>>>>>>>>> of its inputs. As soon as P calls H for the first time, H
>>>>>>>>>>>> (knowing its own machine address) is able to look though
>>>>>>>>>>>> the prior execution trace and see that P is calling H with
>>>>>>>>>>>> the same arguments that it was called with and there are no
>>>>>>>>>>>> instructions in P that would break this cycle.
>>>>>>>>>>>
>>>>>>>>>>> Naive.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The last paragraph has been extensively reviewed and
>>>>>>>>>> validated on another forum, thus saying that it is simply
>>>>>>>>>> Naive carries zero weight.
>>>>>>>>>>
>>>>>>>>>> The only way that the last paragraph can be rebutted is to
>>>>>>>>>> find a counter-example that proves it to be incorrect.
>>>>>>>>>
>>>>>>>>> Publish your algorithm which determines that there are no
>>>>>>>>> instructions in P that would break the cycle.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>> [0000136c](01) c3 ret
>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>
>>>>>>> That is a trace of P, it is not an algorithm which determines
>>>>>>> that there are no instructions in P that would break the cycle.
>>>>>>> Publish the source code of your algorithm.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Because everyone can see that above first seven instructions of P
>>>>>> provide no means for the emulated input to H(P,P) to break out of
>>>>>> repeated x86 emulations your request for code that recognizes
>>>>>> this is merely playing head games.
>>>>>
>>>>> You've got nothing.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> Every competent software engineer can very easily tell that it
>>>> would be very easy to write a program that examines the correct x86
>>>> emulation of the above P to determine that P cannot break out of
>>>> its recursive emulation.
>>>>
>>>> That you imply that this cannot be correctly determined without
>>>> actually seeing the code that does this can't reasonably be
>>>> construed as any honest mistake.
>>>
>>> Are you pattern matching x86 opcodes "EB FE" or not? Publish source
>>> code so we don't have to guess.
>>>
>>> /Flibble
>>>
>>
>> The only actual relevant question is this:
>> Is it possible or impossible for an algorithm to correctly determine
>> that the correctly emulated input to H(P,P) never halts?
>>
>> If it is possible then H(P,P)==0 is proven to be correct.
>>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>>
>> _P()
>> [00001352](01) 55 push ebp
>> [00001353](02) 8bec mov ebp,esp
>> [00001355](03) 8b4508 mov eax,[ebp+08]
>> [00001358](01) 50 push eax // push P
>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>> [0000135c](01) 51 push ecx // push P
>> [0000135d](05) e840feffff call 000011a2 // call H
>> [00001362](03) 83c408 add esp,+08
>> [00001365](02) 85c0 test eax,eax
>> [00001367](02) 7402 jz 0000136b
>> [00001369](02) ebfe jmp 00001369
>> [0000136b](01) 5d pop ebp
>> [0000136c](01) c3 ret
>> Size in bytes:(0027) [0000136c]
>>
>> It is completely obvious that when H(P,P) correctly emulates its
>> input that it must emulate the first seven instructions of P. Because
>> the seventh instruction of P repeats this process we can know with
>> complete certainty that the emulated P never reaches its final “ret”
>> instruction, thus never halts.
>
> You've got nothing, nothing but hot air.
>
> /Flibble
>

On Mon, 13 Jun 2022 15:56:44 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/13/2022 3:50 PM, Mr Flibble wrote:
> > On Mon, 13 Jun 2022 15:14:48 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/13/2022 3:07 PM, Mr Flibble wrote:
> >>> On Mon, 13 Jun 2022 14:47:16 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/13/2022 2:29 PM, Mr Flibble wrote:
> >>>>> On Mon, 13 Jun 2022 14:25:47 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 6/13/2022 2:12 PM, Mr Flibble wrote:
> >>>>>>> On Mon, 13 Jun 2022 13:25:50 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 6/13/2022 1:07 PM, Mr Flibble wrote:
> >>>>>>>>> On Mon, 13 Jun 2022 12:51:08 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
> >>>>>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
> >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
> >>>>>>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>> *The criterion measure for a simulating halt decider
> >>>>>>>>>>>>>> SHD* When the correct partial simulation of the input
> >>>>>>>>>>>>>> matches a non-halting behavior pattern such that it
> >>>>>>>>>>>>>> can be correctly determined that a correct and complete
> >>>>>>>>>>>>>> simulation of the input would never stop running, or
> >>>>>>>>>>>>>> reach the final state of this input then the SHD aborts
> >>>>>>>>>>>>>> its simulation and returns 0.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> *H and P match the above halting problem relationship
> >>>>>>>>>>>>>> to each other*
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>> [00001352](01) 55 push ebp
> >>>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>> [00001358](01) 50 push eax // push P
> >>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
> >>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
> >>>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
> >>>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
> >>>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
> >>>>>>>>>>>>>> [0000136b](01) 5d pop ebp
> >>>>>>>>>>>>>> [0000136c](01) c3 ret
> >>>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
> >>>>>>>>>>>>>> emulates its input that it must emulate the first seven
> >>>>>>>>>>>>>> instructions of P. Because the seventh instruction of P
> >>>>>>>>>>>>>> repeats this process we can know with complete
> >>>>>>>>>>>>>> certainty that the emulated P never reaches its final
> >>>>>>>>>>>>>> “ret” instruction, thus never halts.
> >>>>>>>>>>>>> So your case is that you have dry run P(P) and
> >>>>>>>>>>>>> determined that it never halts. Additionally H(P,P)
> >>>>>>>>>>>>> reports non-halting. Therefore you conclude that H is
> >>>>>>>>>>>>> correct.
> >>>>>>>>>>>>
> >>>>>>>>>>>> In the above case when H(P,P) partially emulates its
> >>>>>>>>>>>> input it correctly determines that a correct and complete
> >>>>>>>>>>>> emulation of its input would never stop running or reach
> >>>>>>>>>>>> the "ret" instruction of P. Instead it would be stuck in
> >>>>>>>>>>>> infinitely recursive emulation.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I have updated the algorithm so that it is a pure
> >>>>>>>>>>>> function of its inputs. As soon as P calls H for the
> >>>>>>>>>>>> first time, H (knowing its own machine address) is able
> >>>>>>>>>>>> to look though the prior execution trace and see that P
> >>>>>>>>>>>> is calling H with the same arguments that it was called
> >>>>>>>>>>>> with and there are no instructions in P that would break
> >>>>>>>>>>>> this cycle.
> >>>>>>>>>>>
> >>>>>>>>>>> Naive.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> The last paragraph has been extensively reviewed and
> >>>>>>>>>> validated on another forum, thus saying that it is simply
> >>>>>>>>>> Naive carries zero weight.
> >>>>>>>>>>
> >>>>>>>>>> The only way that the last paragraph can be rebutted is to
> >>>>>>>>>> find a counter-example that proves it to be incorrect.
> >>>>>>>>>
> >>>>>>>>> Publish your algorithm which determines that there are no
> >>>>>>>>> instructions in P that would break the cycle.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _P()
> >>>>>>>> [00001352](01) 55 push ebp
> >>>>>>>> [00001353](02) 8bec mov ebp,esp
> >>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>> [00001358](01) 50 push eax // push P
> >>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>> [0000135c](01) 51 push ecx // push P
> >>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>>>>>> [00001362](03) 83c408 add esp,+08
> >>>>>>>> [00001365](02) 85c0 test eax,eax
> >>>>>>>> [00001367](02) 7402 jz 0000136b
> >>>>>>>> [00001369](02) ebfe jmp 00001369
> >>>>>>>> [0000136b](01) 5d pop ebp
> >>>>>>>> [0000136c](01) c3 ret
> >>>>>>>> Size in bytes:(0027) [0000136c]
> >>>>>>>
> >>>>>>> That is a trace of P, it is not an algorithm which determines
> >>>>>>> that there are no instructions in P that would break the
> >>>>>>> cycle. Publish the source code of your algorithm.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> Because everyone can see that above first seven instructions
> >>>>>> of P provide no means for the emulated input to H(P,P) to
> >>>>>> break out of repeated x86 emulations your request for code
> >>>>>> that recognizes this is merely playing head games.
> >>>>>
> >>>>> You've got nothing.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> Every competent software engineer can very easily tell that it
> >>>> would be very easy to write a program that examines the correct
> >>>> x86 emulation of the above P to determine that P cannot break
> >>>> out of its recursive emulation.
> >>>>
> >>>> That you imply that this cannot be correctly determined without
> >>>> actually seeing the code that does this can't reasonably be
> >>>> construed as any honest mistake.
> >>>
> >>> Are you pattern matching x86 opcodes "EB FE" or not? Publish
> >>> source code so we don't have to guess.
> >>>
> >>> /Flibble
> >>>
> >>
> >> The only actual relevant question is this:
> >> Is it possible or impossible for an algorithm to correctly
> >> determine that the correctly emulated input to H(P,P) never halts?
> >>
> >> If it is possible then H(P,P)==0 is proven to be correct.
> >>
> >> void P(u32 x)
> >> {
> >> if (H(x, x))
> >> HERE: goto HERE;
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H((u32)P, (u32)P));
> >> }
> >>
> >> _P()
> >> [00001352](01) 55 push ebp
> >> [00001353](02) 8bec mov ebp,esp
> >> [00001355](03) 8b4508 mov eax,[ebp+08]
> >> [00001358](01) 50 push eax // push P
> >> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >> [0000135c](01) 51 push ecx // push P
> >> [0000135d](05) e840feffff call 000011a2 // call H
> >> [00001362](03) 83c408 add esp,+08
> >> [00001365](02) 85c0 test eax,eax
> >> [00001367](02) 7402 jz 0000136b
> >> [00001369](02) ebfe jmp 00001369
> >> [0000136b](01) 5d pop ebp
> >> [0000136c](01) c3 ret
> >> Size in bytes:(0027) [0000136c]
> >>
> >> It is completely obvious that when H(P,P) correctly emulates its
> >> input that it must emulate the first seven instructions of P.
> >> Because the seventh instruction of P repeats this process we can
> >> know with complete certainty that the emulated P never reaches its
> >> final “ret” instruction, thus never halts.
> >
> > You've got nothing, nothing but hot air.
> >
> > /Flibble
> >
>
> What dishonest person says when they know that they have been
> correctly refuted. On the other hand when an honest person forms a
> rebuttal they use reasoning to point out errors.

Click here to read the complete article

On 6/13/2022 4:16 PM, Mr Flibble wrote:
> On Mon, 13 Jun 2022 15:56:44 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/13/2022 3:50 PM, Mr Flibble wrote:
>>> On Mon, 13 Jun 2022 15:14:48 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/13/2022 3:07 PM, Mr Flibble wrote:
>>>>> On Mon, 13 Jun 2022 14:47:16 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/13/2022 2:29 PM, Mr Flibble wrote:
>>>>>>> On Mon, 13 Jun 2022 14:25:47 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 6/13/2022 2:12 PM, Mr Flibble wrote:
>>>>>>>>> On Mon, 13 Jun 2022 13:25:50 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 6/13/2022 1:07 PM, Mr Flibble wrote:
>>>>>>>>>>> On Mon, 13 Jun 2022 12:51:08 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>>>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
>>>>>>>>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> *The criterion measure for a simulating halt decider
>>>>>>>>>>>>>>>> SHD* When the correct partial simulation of the input
>>>>>>>>>>>>>>>> matches a non-halting behavior pattern such that it
>>>>>>>>>>>>>>>> can be correctly determined that a correct and complete
>>>>>>>>>>>>>>>> simulation of the input would never stop running, or
>>>>>>>>>>>>>>>> reach the final state of this input then the SHD aborts
>>>>>>>>>>>>>>>> its simulation and returns 0.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *H and P match the above halting problem relationship
>>>>>>>>>>>>>>>> to each other*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
>>>>>>>>>>>>>>>> emulates its input that it must emulate the first seven
>>>>>>>>>>>>>>>> instructions of P. Because the seventh instruction of P
>>>>>>>>>>>>>>>> repeats this process we can know with complete
>>>>>>>>>>>>>>>> certainty that the emulated P never reaches its final
>>>>>>>>>>>>>>>> “ret” instruction, thus never halts.
>>>>>>>>>>>>>>> So your case is that you have dry run P(P) and
>>>>>>>>>>>>>>> determined that it never halts. Additionally H(P,P)
>>>>>>>>>>>>>>> reports non-halting. Therefore you conclude that H is
>>>>>>>>>>>>>>> correct.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In the above case when H(P,P) partially emulates its
>>>>>>>>>>>>>> input it correctly determines that a correct and complete
>>>>>>>>>>>>>> emulation of its input would never stop running or reach
>>>>>>>>>>>>>> the "ret" instruction of P. Instead it would be stuck in
>>>>>>>>>>>>>> infinitely recursive emulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have updated the algorithm so that it is a pure
>>>>>>>>>>>>>> function of its inputs. As soon as P calls H for the
>>>>>>>>>>>>>> first time, H (knowing its own machine address) is able
>>>>>>>>>>>>>> to look though the prior execution trace and see that P
>>>>>>>>>>>>>> is calling H with the same arguments that it was called
>>>>>>>>>>>>>> with and there are no instructions in P that would break
>>>>>>>>>>>>>> this cycle.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Naive.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The last paragraph has been extensively reviewed and
>>>>>>>>>>>> validated on another forum, thus saying that it is simply
>>>>>>>>>>>> Naive carries zero weight.
>>>>>>>>>>>>
>>>>>>>>>>>> The only way that the last paragraph can be rebutted is to
>>>>>>>>>>>> find a counter-example that proves it to be incorrect.
>>>>>>>>>>>
>>>>>>>>>>> Publish your algorithm which determines that there are no
>>>>>>>>>>> instructions in P that would break the cycle.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _P()
>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>
>>>>>>>>> That is a trace of P, it is not an algorithm which determines
>>>>>>>>> that there are no instructions in P that would break the
>>>>>>>>> cycle. Publish the source code of your algorithm.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> Because everyone can see that above first seven instructions
>>>>>>>> of P provide no means for the emulated input to H(P,P) to
>>>>>>>> break out of repeated x86 emulations your request for code
>>>>>>>> that recognizes this is merely playing head games.
>>>>>>>
>>>>>>> You've got nothing.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Every competent software engineer can very easily tell that it
>>>>>> would be very easy to write a program that examines the correct
>>>>>> x86 emulation of the above P to determine that P cannot break
>>>>>> out of its recursive emulation.
>>>>>>
>>>>>> That you imply that this cannot be correctly determined without
>>>>>> actually seeing the code that does this can't reasonably be
>>>>>> construed as any honest mistake.
>>>>>
>>>>> Are you pattern matching x86 opcodes "EB FE" or not? Publish
>>>>> source code so we don't have to guess.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> The only actual relevant question is this:
>>>> Is it possible or impossible for an algorithm to correctly
>>>> determine that the correctly emulated input to H(P,P) never halts?
>>>>
>>>> If it is possible then H(P,P)==0 is proven to be correct.
>>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> _P()
>>>> [00001352](01) 55 push ebp
>>>> [00001353](02) 8bec mov ebp,esp
>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>> [00001358](01) 50 push eax // push P
>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>> [0000135c](01) 51 push ecx // push P
>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>> [00001362](03) 83c408 add esp,+08
>>>> [00001365](02) 85c0 test eax,eax
>>>> [00001367](02) 7402 jz 0000136b
>>>> [00001369](02) ebfe jmp 00001369
>>>> [0000136b](01) 5d pop ebp
>>>> [0000136c](01) c3 ret
>>>> Size in bytes:(0027) [0000136c]
>>>>
>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>> input that it must emulate the first seven instructions of P.
>>>> Because the seventh instruction of P repeats this process we can
>>>> know with complete certainty that the emulated P never reaches its
>>>> final “ret” instruction, thus never halts.
>>>
>>> You've got nothing, nothing but hot air.
>>>
>>> /Flibble
>>>
>>
>> What dishonest person says when they know that they have been
>> correctly refuted. On the other hand when an honest person forms a
>> rebuttal they use reasoning to point out errors.
>
> You simply ignore any reasoning pointing out errors. You are dishonest
> and you've got nothing.
>
> /Flibble
>

On Mon, 13 Jun 2022 16:20:00 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/13/2022 4:16 PM, Mr Flibble wrote:
> > On Mon, 13 Jun 2022 15:56:44 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/13/2022 3:50 PM, Mr Flibble wrote:
> >>> On Mon, 13 Jun 2022 15:14:48 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/13/2022 3:07 PM, Mr Flibble wrote:
> >>>>> On Mon, 13 Jun 2022 14:47:16 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 6/13/2022 2:29 PM, Mr Flibble wrote:
> >>>>>>> On Mon, 13 Jun 2022 14:25:47 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 6/13/2022 2:12 PM, Mr Flibble wrote:
> >>>>>>>>> On Mon, 13 Jun 2022 13:25:50 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 6/13/2022 1:07 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Mon, 13 Jun 2022 12:51:08 -0500
> >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
> >>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
> >>>>>>>>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>> *The criterion measure for a simulating halt decider
> >>>>>>>>>>>>>>>> SHD* When the correct partial simulation of the input
> >>>>>>>>>>>>>>>> matches a non-halting behavior pattern such that it
> >>>>>>>>>>>>>>>> can be correctly determined that a correct and
> >>>>>>>>>>>>>>>> complete simulation of the input would never stop
> >>>>>>>>>>>>>>>> running, or reach the final state of this input then
> >>>>>>>>>>>>>>>> the SHD aborts its simulation and returns 0.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *H and P match the above halting problem relationship
> >>>>>>>>>>>>>>>> to each other*
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>>>> [00001352](01) 55 push ebp
> >>>>>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>> [00001358](01) 50 push eax // push P
> >>>>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
> >>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>>>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
> >>>>>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
> >>>>>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
> >>>>>>>>>>>>>>>> [0000136b](01) 5d pop ebp
> >>>>>>>>>>>>>>>> [0000136c](01) c3 ret
> >>>>>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
> >>>>>>>>>>>>>>>> emulates its input that it must emulate the first
> >>>>>>>>>>>>>>>> seven instructions of P. Because the seventh
> >>>>>>>>>>>>>>>> instruction of P repeats this process we can know
> >>>>>>>>>>>>>>>> with complete certainty that the emulated P never
> >>>>>>>>>>>>>>>> reaches its final “ret” instruction, thus never
> >>>>>>>>>>>>>>>> halts.
> >>>>>>>>>>>>>>> So your case is that you have dry run P(P) and
> >>>>>>>>>>>>>>> determined that it never halts. Additionally H(P,P)
> >>>>>>>>>>>>>>> reports non-halting. Therefore you conclude that H is
> >>>>>>>>>>>>>>> correct.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> In the above case when H(P,P) partially emulates its
> >>>>>>>>>>>>>> input it correctly determines that a correct and
> >>>>>>>>>>>>>> complete emulation of its input would never stop
> >>>>>>>>>>>>>> running or reach the "ret" instruction of P. Instead
> >>>>>>>>>>>>>> it would be stuck in infinitely recursive emulation.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I have updated the algorithm so that it is a pure
> >>>>>>>>>>>>>> function of its inputs. As soon as P calls H for the
> >>>>>>>>>>>>>> first time, H (knowing its own machine address) is able
> >>>>>>>>>>>>>> to look though the prior execution trace and see that P
> >>>>>>>>>>>>>> is calling H with the same arguments that it was called
> >>>>>>>>>>>>>> with and there are no instructions in P that would
> >>>>>>>>>>>>>> break this cycle.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Naive.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> The last paragraph has been extensively reviewed and
> >>>>>>>>>>>> validated on another forum, thus saying that it is simply
> >>>>>>>>>>>> Naive carries zero weight.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The only way that the last paragraph can be rebutted is
> >>>>>>>>>>>> to find a counter-example that proves it to be
> >>>>>>>>>>>> incorrect.
> >>>>>>>>>>>
> >>>>>>>>>>> Publish your algorithm which determines that there are no
> >>>>>>>>>>> instructions in P that would break the cycle.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _P()
> >>>>>>>>>> [00001352](01) 55 push ebp
> >>>>>>>>>> [00001353](02) 8bec mov ebp,esp
> >>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>> [00001358](01) 50 push eax // push P
> >>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>> [0000135c](01) 51 push ecx // push P
> >>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>>>>>>>> [00001362](03) 83c408 add esp,+08
> >>>>>>>>>> [00001365](02) 85c0 test eax,eax
> >>>>>>>>>> [00001367](02) 7402 jz 0000136b
> >>>>>>>>>> [00001369](02) ebfe jmp 00001369
> >>>>>>>>>> [0000136b](01) 5d pop ebp
> >>>>>>>>>> [0000136c](01) c3 ret
> >>>>>>>>>> Size in bytes:(0027) [0000136c]
> >>>>>>>>>
> >>>>>>>>> That is a trace of P, it is not an algorithm which
> >>>>>>>>> determines that there are no instructions in P that would
> >>>>>>>>> break the cycle. Publish the source code of your algorithm.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Because everyone can see that above first seven instructions
> >>>>>>>> of P provide no means for the emulated input to H(P,P) to
> >>>>>>>> break out of repeated x86 emulations your request for code
> >>>>>>>> that recognizes this is merely playing head games.
> >>>>>>>
> >>>>>>> You've got nothing.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> Every competent software engineer can very easily tell that it
> >>>>>> would be very easy to write a program that examines the correct
> >>>>>> x86 emulation of the above P to determine that P cannot break
> >>>>>> out of its recursive emulation.
> >>>>>>
> >>>>>> That you imply that this cannot be correctly determined without
> >>>>>> actually seeing the code that does this can't reasonably be
> >>>>>> construed as any honest mistake.
> >>>>>
> >>>>> Are you pattern matching x86 opcodes "EB FE" or not? Publish
> >>>>> source code so we don't have to guess.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> The only actual relevant question is this:
> >>>> Is it possible or impossible for an algorithm to correctly
> >>>> determine that the correctly emulated input to H(P,P) never
> >>>> halts?
> >>>>
> >>>> If it is possible then H(P,P)==0 is proven to be correct.
> >>>>
> >>>> void P(u32 x)
> >>>> {
> >>>> if (H(x, x))
> >>>> HERE: goto HERE;
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>> }
> >>>>
> >>>> _P()
> >>>> [00001352](01) 55 push ebp
> >>>> [00001353](02) 8bec mov ebp,esp
> >>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>> [00001358](01) 50 push eax // push P
> >>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>> [0000135c](01) 51 push ecx // push P
> >>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>> [00001362](03) 83c408 add esp,+08
> >>>> [00001365](02) 85c0 test eax,eax
> >>>> [00001367](02) 7402 jz 0000136b
> >>>> [00001369](02) ebfe jmp 00001369
> >>>> [0000136b](01) 5d pop ebp
> >>>> [0000136c](01) c3 ret
> >>>> Size in bytes:(0027) [0000136c]
> >>>>
> >>>> It is completely obvious that when H(P,P) correctly emulates its
> >>>> input that it must emulate the first seven instructions of P.
> >>>> Because the seventh instruction of P repeats this process we can
> >>>> know with complete certainty that the emulated P never reaches
> >>>> its final “ret” instruction, thus never halts.
> >>>
> >>> You've got nothing, nothing but hot air.
> >>>
> >>> /Flibble
> >>>
> >>
> >> What dishonest person says when they know that they have been
> >> correctly refuted. On the other hand when an honest person forms a
> >> rebuttal they use reasoning to point out errors.
> >
> > You simply ignore any reasoning pointing out errors. You are
> > dishonest and you've got nothing.
> >
> > /Flibble
> >
>
> I provided the reasoning above and it is still there.
> You provided no rebuttal to this reasoning as the clearly record
> shows.

Click here to read the complete article

On 6/13/2022 5:07 PM, Mr Flibble wrote:
> On Mon, 13 Jun 2022 16:20:00 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/13/2022 4:16 PM, Mr Flibble wrote:
>>> On Mon, 13 Jun 2022 15:56:44 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/13/2022 3:50 PM, Mr Flibble wrote:
>>>>> On Mon, 13 Jun 2022 15:14:48 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/13/2022 3:07 PM, Mr Flibble wrote:
>>>>>>> On Mon, 13 Jun 2022 14:47:16 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 6/13/2022 2:29 PM, Mr Flibble wrote:
>>>>>>>>> On Mon, 13 Jun 2022 14:25:47 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 6/13/2022 2:12 PM, Mr Flibble wrote:
>>>>>>>>>>> On Mon, 13 Jun 2022 13:25:50 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 6/13/2022 1:07 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Mon, 13 Jun 2022 12:51:08 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
>>>>>>>>>>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> *The criterion measure for a simulating halt decider
>>>>>>>>>>>>>>>>>> SHD* When the correct partial simulation of the input
>>>>>>>>>>>>>>>>>> matches a non-halting behavior pattern such that it
>>>>>>>>>>>>>>>>>> can be correctly determined that a correct and
>>>>>>>>>>>>>>>>>> complete simulation of the input would never stop
>>>>>>>>>>>>>>>>>> running, or reach the final state of this input then
>>>>>>>>>>>>>>>>>> the SHD aborts its simulation and returns 0.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *H and P match the above halting problem relationship
>>>>>>>>>>>>>>>>>> to each other*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>>>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>>>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
>>>>>>>>>>>>>>>>>> emulates its input that it must emulate the first
>>>>>>>>>>>>>>>>>> seven instructions of P. Because the seventh
>>>>>>>>>>>>>>>>>> instruction of P repeats this process we can know
>>>>>>>>>>>>>>>>>> with complete certainty that the emulated P never
>>>>>>>>>>>>>>>>>> reaches its final “ret” instruction, thus never
>>>>>>>>>>>>>>>>>> halts.
>>>>>>>>>>>>>>>>> So your case is that you have dry run P(P) and
>>>>>>>>>>>>>>>>> determined that it never halts. Additionally H(P,P)
>>>>>>>>>>>>>>>>> reports non-halting. Therefore you conclude that H is
>>>>>>>>>>>>>>>>> correct.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In the above case when H(P,P) partially emulates its
>>>>>>>>>>>>>>>> input it correctly determines that a correct and
>>>>>>>>>>>>>>>> complete emulation of its input would never stop
>>>>>>>>>>>>>>>> running or reach the "ret" instruction of P. Instead
>>>>>>>>>>>>>>>> it would be stuck in infinitely recursive emulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have updated the algorithm so that it is a pure
>>>>>>>>>>>>>>>> function of its inputs. As soon as P calls H for the
>>>>>>>>>>>>>>>> first time, H (knowing its own machine address) is able
>>>>>>>>>>>>>>>> to look though the prior execution trace and see that P
>>>>>>>>>>>>>>>> is calling H with the same arguments that it was called
>>>>>>>>>>>>>>>> with and there are no instructions in P that would
>>>>>>>>>>>>>>>> break this cycle.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Naive.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The last paragraph has been extensively reviewed and
>>>>>>>>>>>>>> validated on another forum, thus saying that it is simply
>>>>>>>>>>>>>> Naive carries zero weight.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The only way that the last paragraph can be rebutted is
>>>>>>>>>>>>>> to find a counter-example that proves it to be
>>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Publish your algorithm which determines that there are no
>>>>>>>>>>>>> instructions in P that would break the cycle.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _P()
>>>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>
>>>>>>>>>>> That is a trace of P, it is not an algorithm which
>>>>>>>>>>> determines that there are no instructions in P that would
>>>>>>>>>>> break the cycle. Publish the source code of your algorithm.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Because everyone can see that above first seven instructions
>>>>>>>>>> of P provide no means for the emulated input to H(P,P) to
>>>>>>>>>> break out of repeated x86 emulations your request for code
>>>>>>>>>> that recognizes this is merely playing head games.
>>>>>>>>>
>>>>>>>>> You've got nothing.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> Every competent software engineer can very easily tell that it
>>>>>>>> would be very easy to write a program that examines the correct
>>>>>>>> x86 emulation of the above P to determine that P cannot break
>>>>>>>> out of its recursive emulation.
>>>>>>>>
>>>>>>>> That you imply that this cannot be correctly determined without
>>>>>>>> actually seeing the code that does this can't reasonably be
>>>>>>>> construed as any honest mistake.
>>>>>>>
>>>>>>> Are you pattern matching x86 opcodes "EB FE" or not? Publish
>>>>>>> source code so we don't have to guess.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> The only actual relevant question is this:
>>>>>> Is it possible or impossible for an algorithm to correctly
>>>>>> determine that the correctly emulated input to H(P,P) never
>>>>>> halts?
>>>>>>
>>>>>> If it is possible then H(P,P)==0 is proven to be correct.
>>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>> }
>>>>>>
>>>>>> _P()
>>>>>> [00001352](01) 55 push ebp
>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>> [00001358](01) 50 push eax // push P
>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>> [0000136b](01) 5d pop ebp
>>>>>> [0000136c](01) c3 ret
>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>
>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>> input that it must emulate the first seven instructions of P.
>>>>>> Because the seventh instruction of P repeats this process we can
>>>>>> know with complete certainty that the emulated P never reaches
>>>>>> its final “ret” instruction, thus never halts.
>>>>>
>>>>> You've got nothing, nothing but hot air.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> What dishonest person says when they know that they have been
>>>> correctly refuted. On the other hand when an honest person forms a
>>>> rebuttal they use reasoning to point out errors.
>>>
>>> You simply ignore any reasoning pointing out errors. You are
>>> dishonest and you've got nothing.
>>>
>>> /Flibble
>>>
>>
>> I provided the reasoning above and it is still there.
>> You provided no rebuttal to this reasoning as the clearly record
>> shows.
>
> The hubris is unbelievable.
>
> /Flibble
>

On Mon, 13 Jun 2022 17:15:29 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/13/2022 5:07 PM, Mr Flibble wrote:
> > On Mon, 13 Jun 2022 16:20:00 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/13/2022 4:16 PM, Mr Flibble wrote:
> >>> On Mon, 13 Jun 2022 15:56:44 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/13/2022 3:50 PM, Mr Flibble wrote:
> >>>>> On Mon, 13 Jun 2022 15:14:48 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 6/13/2022 3:07 PM, Mr Flibble wrote:
> >>>>>>> On Mon, 13 Jun 2022 14:47:16 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 6/13/2022 2:29 PM, Mr Flibble wrote:
> >>>>>>>>> On Mon, 13 Jun 2022 14:25:47 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 6/13/2022 2:12 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Mon, 13 Jun 2022 13:25:50 -0500
> >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 6/13/2022 1:07 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Mon, 13 Jun 2022 12:51:08 -0500
> >>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
> >>>>>>>>>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
> >>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
> >>>>>>>>>>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>> *The criterion measure for a simulating halt
> >>>>>>>>>>>>>>>>>> decider SHD* When the correct partial simulation
> >>>>>>>>>>>>>>>>>> of the input matches a non-halting behavior
> >>>>>>>>>>>>>>>>>> pattern such that it can be correctly determined
> >>>>>>>>>>>>>>>>>> that a correct and complete simulation of the
> >>>>>>>>>>>>>>>>>> input would never stop running, or reach the final
> >>>>>>>>>>>>>>>>>> state of this input then the SHD aborts its
> >>>>>>>>>>>>>>>>>> simulation and returns 0.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> *H and P match the above halting problem
> >>>>>>>>>>>>>>>>>> relationship to each other*
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>>>>>> [00001352](01) 55 push ebp
> >>>>>>>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>> [00001358](01) 50 push eax // push P
> >>>>>>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
> >>>>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>>>>>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
> >>>>>>>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
> >>>>>>>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
> >>>>>>>>>>>>>>>>>> [0000136b](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>> [0000136c](01) c3 ret
> >>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
> >>>>>>>>>>>>>>>>>> emulates its input that it must emulate the first
> >>>>>>>>>>>>>>>>>> seven instructions of P. Because the seventh
> >>>>>>>>>>>>>>>>>> instruction of P repeats this process we can know
> >>>>>>>>>>>>>>>>>> with complete certainty that the emulated P never
> >>>>>>>>>>>>>>>>>> reaches its final “ret” instruction, thus never
> >>>>>>>>>>>>>>>>>> halts.
> >>>>>>>>>>>>>>>>> So your case is that you have dry run P(P) and
> >>>>>>>>>>>>>>>>> determined that it never halts. Additionally H(P,P)
> >>>>>>>>>>>>>>>>> reports non-halting. Therefore you conclude that H
> >>>>>>>>>>>>>>>>> is correct.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> In the above case when H(P,P) partially emulates its
> >>>>>>>>>>>>>>>> input it correctly determines that a correct and
> >>>>>>>>>>>>>>>> complete emulation of its input would never stop
> >>>>>>>>>>>>>>>> running or reach the "ret" instruction of P. Instead
> >>>>>>>>>>>>>>>> it would be stuck in infinitely recursive emulation.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I have updated the algorithm so that it is a pure
> >>>>>>>>>>>>>>>> function of its inputs. As soon as P calls H for the
> >>>>>>>>>>>>>>>> first time, H (knowing its own machine address) is
> >>>>>>>>>>>>>>>> able to look though the prior execution trace and
> >>>>>>>>>>>>>>>> see that P is calling H with the same arguments that
> >>>>>>>>>>>>>>>> it was called with and there are no instructions in
> >>>>>>>>>>>>>>>> P that would break this cycle.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Naive.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The last paragraph has been extensively reviewed and
> >>>>>>>>>>>>>> validated on another forum, thus saying that it is
> >>>>>>>>>>>>>> simply Naive carries zero weight.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The only way that the last paragraph can be rebutted is
> >>>>>>>>>>>>>> to find a counter-example that proves it to be
> >>>>>>>>>>>>>> incorrect.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Publish your algorithm which determines that there are
> >>>>>>>>>>>>> no instructions in P that would break the cycle.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> _P()
> >>>>>>>>>>>> [00001352](01) 55 push ebp
> >>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
> >>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>> [00001358](01) 50 push eax // push P
> >>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
> >>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
> >>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
> >>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
> >>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
> >>>>>>>>>>>> [0000136b](01) 5d pop ebp
> >>>>>>>>>>>> [0000136c](01) c3 ret
> >>>>>>>>>>>> Size in bytes:(0027) [0000136c]
> >>>>>>>>>>>
> >>>>>>>>>>> That is a trace of P, it is not an algorithm which
> >>>>>>>>>>> determines that there are no instructions in P that would
> >>>>>>>>>>> break the cycle. Publish the source code of your
> >>>>>>>>>>> algorithm.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Because everyone can see that above first seven
> >>>>>>>>>> instructions of P provide no means for the emulated input
> >>>>>>>>>> to H(P,P) to break out of repeated x86 emulations your
> >>>>>>>>>> request for code that recognizes this is merely playing
> >>>>>>>>>> head games.
> >>>>>>>>>
> >>>>>>>>> You've got nothing.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Every competent software engineer can very easily tell that
> >>>>>>>> it would be very easy to write a program that examines the
> >>>>>>>> correct x86 emulation of the above P to determine that P
> >>>>>>>> cannot break out of its recursive emulation.
> >>>>>>>>
> >>>>>>>> That you imply that this cannot be correctly determined
> >>>>>>>> without actually seeing the code that does this can't
> >>>>>>>> reasonably be construed as any honest mistake.
> >>>>>>>
> >>>>>>> Are you pattern matching x86 opcodes "EB FE" or not? Publish
> >>>>>>> source code so we don't have to guess.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> The only actual relevant question is this:
> >>>>>> Is it possible or impossible for an algorithm to correctly
> >>>>>> determine that the correctly emulated input to H(P,P) never
> >>>>>> halts?
> >>>>>>
> >>>>>> If it is possible then H(P,P)==0 is proven to be correct.
> >>>>>>
> >>>>>> void P(u32 x)
> >>>>>> {
> >>>>>> if (H(x, x))
> >>>>>> HERE: goto HERE;
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>> }
> >>>>>>
> >>>>>> _P()
> >>>>>> [00001352](01) 55 push ebp
> >>>>>> [00001353](02) 8bec mov ebp,esp
> >>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>>>> [00001358](01) 50 push eax // push P
> >>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>> [0000135c](01) 51 push ecx // push P
> >>>>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>>>> [00001362](03) 83c408 add esp,+08
> >>>>>> [00001365](02) 85c0 test eax,eax
> >>>>>> [00001367](02) 7402 jz 0000136b
> >>>>>> [00001369](02) ebfe jmp 00001369
> >>>>>> [0000136b](01) 5d pop ebp
> >>>>>> [0000136c](01) c3 ret
> >>>>>> Size in bytes:(0027) [0000136c]
> >>>>>>
> >>>>>> It is completely obvious that when H(P,P) correctly emulates
> >>>>>> its input that it must emulate the first seven instructions of
> >>>>>> P. Because the seventh instruction of P repeats this process
> >>>>>> we can know with complete certainty that the emulated P never
> >>>>>> reaches its final “ret” instruction, thus never halts.
> >>>>>
> >>>>> You've got nothing, nothing but hot air.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> What dishonest person says when they know that they have been
> >>>> correctly refuted. On the other hand when an honest person forms
> >>>> a rebuttal they use reasoning to point out errors.
> >>>
> >>> You simply ignore any reasoning pointing out errors. You are
> >>> dishonest and you've got nothing.
> >>>
> >>> /Flibble
> >>>
> >>
> >> I provided the reasoning above and it is still there.
> >> You provided no rebuttal to this reasoning as the clearly record
> >> shows.
> >
> > The hubris is unbelievable.
> >
> > /Flibble
> >
>
> So far every single reviewer has managed to dodge a rigorous
> point-by-point software engineering review of H(P,P)==0.
>
> Like you they resort to mere rhetoric presumably because they know
> that when using correct reaoning as a basis that every rebuttal must
> fail.

Click here to read the complete article

On 6/13/22 10:27 AM, olcott wrote:
> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
>>> *The criterion measure for a simulating halt decider SHD*
>>> When the correct partial simulation of the input matches a non-halting
>>> behavior pattern such that it can be correctly determined that a correct
>>> and complete simulation of the input would never stop running, or reach
>>> the final state of this input then the SHD aborts its simulation and
>>> returns 0.
>>>
>>> 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
>>>
>>> *H and P match the above halting problem relationship to each other*
>>>
>>> void P(u32 x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>>
>>> _P()
>>> [00001352](01) 55 push ebp
>>> [00001353](02) 8bec mov ebp,esp
>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>> [00001358](01) 50 push eax // push P
>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>> [0000135c](01) 51 push ecx // push P
>>> [0000135d](05) e840feffff call 000011a2 // call H
>>> [00001362](03) 83c408 add esp,+08
>>> [00001365](02) 85c0 test eax,eax
>>> [00001367](02) 7402 jz 0000136b
>>> [00001369](02) ebfe jmp 00001369
>>> [0000136b](01) 5d pop ebp
>>> [0000136c](01) c3 ret
>>> Size in bytes:(0027) [0000136c]
>>>
>>> It is completely obvious that when H(P,P) correctly emulates its input
>>> that it must emulate the first seven instructions of P. Because the
>>> seventh instruction of P repeats this process we can know with complete
>>> certainty that the emulated P never reaches its final “ret” instruction,
>>> thus never halts.
>>>
>> So your case is that you have dry run P(P) and determined that it
>> never halts.
>> Additionally H(P,P) reports non-halting. Therefore you conclude that H is
>> correct.
>
> In the above case when H(P,P) partially emulates its input it correctly
> determines that a correct and complete emulation of its input would
> never stop running or reach the "ret" instruction of P. Instead it would
> be stuck in infinitely recursive emulation.
>
> I have updated the algorithm so that it is a pure function of its
> inputs. As soon as P calls H for the first time, H (knowing its own
> machine address) is able to look though the prior execution trace and
> see that P is calling H with the same arguments that it was called with
> and there are no instructions in P that would break this cycle.
>

Except that H is MISTAKEN on the behavior of H, because, since THIS H is
going to abort its simulation, it needs to allow for the H that it is
simulating to do the same thing.

Thus H makes the same mistake that you keep on doing and thinking that H
can actually do a complete and correct emulation and also return an
annswer for P.

This is impossible, ALL H(P,P) must do the same thing, either return 0
or recurse infinitely in their simulatings, and any statement contrary
is just a LIE.

If you want to show that it can. just provide, as previously ask, to
provide the FIRST x86 instruction that behaved differently in those two
different paths.

You claim that H is a "Pure Function" of its inputs, so that at that
first difference, the instruction will be the same, and the inputs to it
will be the same, but the results will be different.

Since you have the code for H already (or so you claim) this should be
easy to find, and when you show it you will be famous.

When you don't show it, you will be shown to just be a pathlogical liar.

Note, you keep on making this mistake of forgetting that the H that P
calls is part of that function, so the conditionals there DO count for
breaking the cycle. Your missing this just shows how ignorant you are of
the basic of programming.

On 6/13/22 1:51 PM, olcott wrote:
> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>> On Mon, 13 Jun 2022 09:27:08 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
>>>>> *The criterion measure for a simulating halt decider SHD*
>>>>> When the correct partial simulation of the input matches a
>>>>> non-halting behavior pattern such that it can be correctly
>>>>> determined that a correct and complete simulation of the input
>>>>> would never stop running, or reach the final state of this input
>>>>> then the SHD aborts its simulation and returns 0.
>>>>>
>>>>> 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
>>>>>
>>>>> *H and P match the above halting problem relationship to each
>>>>> other*
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [00001352](01) 55 push ebp
>>>>> [00001353](02) 8bec mov ebp,esp
>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>> [00001358](01) 50 push eax // push P
>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>> [0000135c](01) 51 push ecx // push P
>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>> [00001362](03) 83c408 add esp,+08
>>>>> [00001365](02) 85c0 test eax,eax
>>>>> [00001367](02) 7402 jz 0000136b
>>>>> [00001369](02) ebfe jmp 00001369
>>>>> [0000136b](01) 5d pop ebp
>>>>> [0000136c](01) c3 ret
>>>>> Size in bytes:(0027) [0000136c]
>>>>>
>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>> input that it must emulate the first seven instructions of P.
>>>>> Because the seventh instruction of P repeats this process we can
>>>>> know with complete certainty that the emulated P never reaches its
>>>>> final “ret” instruction, thus never halts.
>>>> So your case is that you have dry run P(P) and determined that it
>>>> never halts. Additionally H(P,P) reports non-halting. Therefore you
>>>> conclude that H is correct.
>>>
>>> In the above case when H(P,P) partially emulates its input it
>>> correctly determines that a correct and complete emulation of its
>>> input would never stop running or reach the "ret" instruction of P.
>>> Instead it would be stuck in infinitely recursive emulation.
>>>
>>> I have updated the algorithm so that it is a pure function of its
>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>> machine address) is able to look though the prior execution trace and
>>> see that P is calling H with the same arguments that it was called
>>> with and there are no instructions in P that would break this cycle.
>> Naive.
>>
>> /Flibble
>>
>
> The last paragraph has been extensively reviewed and validated on
> another forum, thus saying that it is simply Naive carries zero weight.
>
> The only way that the last paragraph can be rebutted is to find a
> counter-example that proves it to be incorrect.
>

Can you point to the message where someone actually agreed with your
conclusion?

I don't remember seeing one, so I think this is another of your lies.

On 6/13/22 3:25 PM, olcott wrote:
> On 6/13/2022 2:12 PM, Mr Flibble wrote:
>> On Mon, 13 Jun 2022 13:25:50 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/13/2022 1:07 PM, Mr Flibble wrote:
>>>> On Mon, 13 Jun 2022 12:51:08 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
>>>>>>>>> *The criterion measure for a simulating halt decider SHD*
>>>>>>>>> When the correct partial simulation of the input matches a
>>>>>>>>> non-halting behavior pattern such that it can be correctly
>>>>>>>>> determined that a correct and complete simulation of the input
>>>>>>>>> would never stop running, or reach the final state of this
>>>>>>>>> input then the SHD aborts its simulation and returns 0.
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> *H and P match the above halting problem relationship to each
>>>>>>>>> other*
>>>>>>>>>
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>> if (H(x, x))
>>>>>>>>> HERE: goto HERE;
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _P()
>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>
>>>>>>>>> It is completely obvious that when H(P,P) correctly emulates
>>>>>>>>> its input that it must emulate the first seven instructions of
>>>>>>>>> P. Because the seventh instruction of P repeats this process
>>>>>>>>> we can know with complete certainty that the emulated P never
>>>>>>>>> reaches its final “ret” instruction, thus never halts.
>>>>>>>> So your case is that you have dry run P(P) and determined that
>>>>>>>> it never halts. Additionally H(P,P) reports non-halting.
>>>>>>>> Therefore you conclude that H is correct.
>>>>>>>
>>>>>>> In the above case when H(P,P) partially emulates its input it
>>>>>>> correctly determines that a correct and complete emulation of its
>>>>>>> input would never stop running or reach the "ret" instruction of
>>>>>>> P. Instead it would be stuck in infinitely recursive emulation.
>>>>>>>
>>>>>>> I have updated the algorithm so that it is a pure function of its
>>>>>>> inputs. As soon as P calls H for the first time, H (knowing its
>>>>>>> own machine address) is able to look though the prior execution
>>>>>>> trace and see that P is calling H with the same arguments that
>>>>>>> it was called with and there are no instructions in P that would
>>>>>>> break this cycle.
>>>>>> Naive.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> The last paragraph has been extensively reviewed and validated on
>>>>> another forum, thus saying that it is simply Naive carries zero
>>>>> weight.
>>>>>
>>>>> The only way that the last paragraph can be rebutted is to find a
>>>>> counter-example that proves it to be incorrect.
>>>> Publish your algorithm which determines that there are no
>>>> instructions in P that would break the cycle.
>>>>
>>>> /Flibble
>>>
>>>
>>> _P()
>>> [00001352](01)  55              push ebp
>>> [00001353](02)  8bec            mov ebp,esp
>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>> [00001358](01)  50              push eax      // push P
>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>> [0000135c](01)  51              push ecx      // push P
>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>> [00001362](03)  83c408          add esp,+08
>>> [00001365](02)  85c0            test eax,eax
>>> [00001367](02)  7402            jz 0000136b
>>> [00001369](02)  ebfe            jmp 00001369
>>> [0000136b](01)  5d              pop ebp
>>> [0000136c](01)  c3              ret
>>> Size in bytes:(0027) [0000136c]
>>
>> That is a trace of P, it is not an algorithm which determines that
>> there are no instructions in P that would break the cycle.  Publish the
>> source code of your algorithm.
>>
>> /Flibble
>>
>
> Because everyone can see that above first seven instructions of P
> provide no means for the emulated input to H(P,P) to break out of
> repeated x86 emulations your request for code that recognizes this is
> merely playing head games.
>

But it doesn't matter, since the alogrithm of H is part of the algorithm
of P by the call.

THAT has the code to break out of the emulation cycle.

You are just showing your stupidity by ignoring the basic facts.

On 6/13/2022 6:18 PM, Richard Damon wrote:
>
> On 6/13/22 1:51 PM, olcott wrote:
>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
>>>>>> *The criterion measure for a simulating halt decider SHD*
>>>>>> When the correct partial simulation of the input matches a
>>>>>> non-halting behavior pattern such that it can be correctly
>>>>>> determined that a correct and complete simulation of the input
>>>>>> would never stop running, or reach the final state of this input
>>>>>> then the SHD aborts its simulation and returns 0.
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> *H and P match the above halting problem relationship to each
>>>>>> other*
>>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>> }
>>>>>>
>>>>>> _P()
>>>>>> [00001352](01) 55 push ebp
>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>> [00001358](01) 50 push eax // push P
>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>> [0000136b](01) 5d pop ebp
>>>>>> [0000136c](01) c3 ret
>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>
>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>> input that it must emulate the first seven instructions of P.
>>>>>> Because the seventh instruction of P repeats this process we can
>>>>>> know with complete certainty that the emulated P never reaches its
>>>>>> final “ret” instruction, thus never halts.
>>>>> So your case is that you have dry run P(P) and determined that it
>>>>> never halts. Additionally H(P,P) reports non-halting. Therefore you
>>>>> conclude that H is correct.
>>>>
>>>> In the above case when H(P,P) partially emulates its input it
>>>> correctly determines that a correct and complete emulation of its
>>>> input would never stop running or reach the "ret" instruction of P.
>>>> Instead it would be stuck in infinitely recursive emulation.
>>>>
>>>> I have updated the algorithm so that it is a pure function of its
>>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>>> machine address) is able to look though the prior execution trace and
>>>> see that P is calling H with the same arguments that it was called
>>>> with and there are no instructions in P that would break this cycle.
>>> Naive.
>>>
>>> /Flibble
>>>
>>
>> The last paragraph has been extensively reviewed and validated on
>> another forum, thus saying that it is simply Naive carries zero weight.
>>
>> The only way that the last paragraph can be rebutted is to find a
>> counter-example that proves it to be incorrect.
>>
>
> Can you point to the message where someone actually agreed with your
> conclusion?
>
> I don't remember seeing one, so I think this is another of your lies.

The last paragraph has been extensively reviewed and validated on
another forum, not USENET.

Ultimately the truth of it depends on the fact that zero correct
rebuttals exist.

--
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 6/13/22 7:25 PM, olcott wrote:
> On 6/13/2022 6:18 PM, Richard Damon wrote:
>>
>> On 6/13/22 1:51 PM, olcott wrote:
>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
>>>>>>> *The criterion measure for a simulating halt decider SHD*
>>>>>>> When the correct partial simulation of the input matches a
>>>>>>> non-halting behavior pattern such that it can be correctly
>>>>>>> determined that a correct and complete simulation of the input
>>>>>>> would never stop running, or reach the final state of this input
>>>>>>> then the SHD aborts its simulation and returns 0.
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>> *H and P match the above halting problem relationship to each
>>>>>>> other*
>>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>> if (H(x, x))
>>>>>>> HERE: goto HERE;
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>> }
>>>>>>>
>>>>>>> _P()
>>>>>>> [00001352](01) 55 push ebp
>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>> [0000136c](01) c3 ret
>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>
>>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>> Because the seventh instruction of P repeats this process we can
>>>>>>> know with complete certainty that the emulated P never reaches its
>>>>>>> final “ret” instruction, thus never halts.
>>>>>> So your case is that you have dry run P(P) and determined that it
>>>>>> never halts. Additionally H(P,P) reports non-halting. Therefore you
>>>>>> conclude that H is correct.
>>>>>
>>>>> In the above case when H(P,P) partially emulates its input it
>>>>> correctly determines that a correct and complete emulation of its
>>>>> input would never stop running or reach the "ret" instruction of P.
>>>>> Instead it would be stuck in infinitely recursive emulation.
>>>>>
>>>>> I have updated the algorithm so that it is a pure function of its
>>>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>>>> machine address) is able to look though the prior execution trace and
>>>>> see that P is calling H with the same arguments that it was called
>>>>> with and there are no instructions in P that would break this cycle.
>>>> Naive.
>>>>
>>>> /Flibble
>>>>
>>>
>>> The last paragraph has been extensively reviewed and validated on
>>> another forum, thus saying that it is simply Naive carries zero weight.
>>>
>>> The only way that the last paragraph can be rebutted is to find a
>>> counter-example that proves it to be incorrect.
>>>
>>
>> Can you point to the message where someone actually agreed with your
>> conclusion?
>>
>> I don't remember seeing one, so I think this is another of your lies.
>
> The last paragraph has been extensively reviewed and validated on
> another forum, not USENET.
>
> Ultimately the truth of it depends on the fact that zero correct
> rebuttals exist.
>

Nope, lack of evidence of error is not evidence of lack of error.

So, can you actually QUOTE someone who agrees with you?

Note, you LIE that no correct rebuttalls exist as many have been posted,
not of which you have shown an error in.

"Correct" is not just agreeing with YOUR beliefs.

Until you can show an ACTUAL proof of what you claim (which is
impossible basedd on the actual definitions) all you statemeents are
just LIES.

You don't even KNOW the meaning of Truth.

I can say by your logic, that since "NO correct rebuttals exist" about
the claim that you are just a pathological liar, that must be true, and
by your logic you need to accept it.

On 6/13/2022 7:06 PM, Richard Damon wrote:
>
> On 6/13/22 7:25 PM, olcott wrote:
>> On 6/13/2022 6:18 PM, Richard Damon wrote:
>>>
>>> On 6/13/22 1:51 PM, olcott wrote:
>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
>>>>>>>> *The criterion measure for a simulating halt decider SHD*
>>>>>>>> When the correct partial simulation of the input matches a
>>>>>>>> non-halting behavior pattern such that it can be correctly
>>>>>>>> determined that a correct and complete simulation of the input
>>>>>>>> would never stop running, or reach the final state of this input
>>>>>>>> then the SHD aborts its simulation and returns 0.
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>> *H and P match the above halting problem relationship to each
>>>>>>>> other*
>>>>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>> if (H(x, x))
>>>>>>>> HERE: goto HERE;
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>> [0000136c](01) c3 ret
>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>
>>>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>>> Because the seventh instruction of P repeats this process we can
>>>>>>>> know with complete certainty that the emulated P never reaches its
>>>>>>>> final “ret” instruction, thus never halts.
>>>>>>> So your case is that you have dry run P(P) and determined that it
>>>>>>> never halts. Additionally H(P,P) reports non-halting. Therefore you
>>>>>>> conclude that H is correct.
>>>>>>
>>>>>> In the above case when H(P,P) partially emulates its input it
>>>>>> correctly determines that a correct and complete emulation of its
>>>>>> input would never stop running or reach the "ret" instruction of P.
>>>>>> Instead it would be stuck in infinitely recursive emulation.
>>>>>>
>>>>>> I have updated the algorithm so that it is a pure function of its
>>>>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>>>>> machine address) is able to look though the prior execution trace and
>>>>>> see that P is calling H with the same arguments that it was called
>>>>>> with and there are no instructions in P that would break this cycle.
>>>>> Naive.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> The last paragraph has been extensively reviewed and validated on
>>>> another forum, thus saying that it is simply Naive carries zero weight.
>>>>
>>>> The only way that the last paragraph can be rebutted is to find a
>>>> counter-example that proves it to be incorrect.
>>>>
>>>
>>> Can you point to the message where someone actually agreed with your
>>> conclusion?
>>>
>>> I don't remember seeing one, so I think this is another of your lies.
>>
>> The last paragraph has been extensively reviewed and validated on
>> another forum, not USENET.
>>
>> Ultimately the truth of it depends on the fact that zero correct
>> rebuttals exist.
>>
>
> Nope, lack of evidence of error is not evidence of lack of error.
If there has been no evidence that anyone has presented then this is not
proof at all that the claim is true.

If there is no evidence that anyone could ever possibly present then
this is proof that the claim is true.

--
Copyright 2022 Pete Olcott

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

On 6/13/22 8:20 PM, olcott wrote:
> On 6/13/2022 7:06 PM, Richard Damon wrote:
>>
>> On 6/13/22 7:25 PM, olcott wrote:
>>> On 6/13/2022 6:18 PM, Richard Damon wrote:
>>>>
>>>> On 6/13/22 1:51 PM, olcott wrote:
>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>
>>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
>>>>>>>>> *The criterion measure for a simulating halt decider SHD*
>>>>>>>>> When the correct partial simulation of the input matches a
>>>>>>>>> non-halting behavior pattern such that it can be correctly
>>>>>>>>> determined that a correct and complete simulation of the input
>>>>>>>>> would never stop running, or reach the final state of this input
>>>>>>>>> then the SHD aborts its simulation and returns 0.
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> *H and P match the above halting problem relationship to each
>>>>>>>>> other*
>>>>>>>>>
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>> if (H(x, x))
>>>>>>>>> HERE: goto HERE;
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _P()
>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>
>>>>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>>>> Because the seventh instruction of P repeats this process we can
>>>>>>>>> know with complete certainty that the emulated P never reaches its
>>>>>>>>> final “ret” instruction, thus never halts.
>>>>>>>> So your case is that you have dry run P(P) and determined that it
>>>>>>>> never halts. Additionally H(P,P) reports non-halting. Therefore you
>>>>>>>> conclude that H is correct.
>>>>>>>
>>>>>>> In the above case when H(P,P) partially emulates its input it
>>>>>>> correctly determines that a correct and complete emulation of its
>>>>>>> input would never stop running or reach the "ret" instruction of P.
>>>>>>> Instead it would be stuck in infinitely recursive emulation.
>>>>>>>
>>>>>>> I have updated the algorithm so that it is a pure function of its
>>>>>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>>>>>> machine address) is able to look though the prior execution trace
>>>>>>> and
>>>>>>> see that P is calling H with the same arguments that it was called
>>>>>>> with and there are no instructions in P that would break this cycle.
>>>>>> Naive.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> The last paragraph has been extensively reviewed and validated on
>>>>> another forum, thus saying that it is simply Naive carries zero
>>>>> weight.
>>>>>
>>>>> The only way that the last paragraph can be rebutted is to find a
>>>>> counter-example that proves it to be incorrect.
>>>>>
>>>>
>>>> Can you point to the message where someone actually agreed with your
>>>> conclusion?
>>>>
>>>> I don't remember seeing one, so I think this is another of your lies.
>>>
>>> The last paragraph has been extensively reviewed and validated on
>>> another forum, not USENET.
>>>
>>> Ultimately the truth of it depends on the fact that zero correct
>>> rebuttals exist.
>>>
>>
>> Nope, lack of evidence of error is not evidence of lack of error.
> If there has been no evidence that anyone has presented then this is not
> proof at all that the claim is true.
>
> If there is no evidence that anyone could ever possibly present then
> this is proof that the claim is true.
>

Evidence of error HAS been given, and IGNRORED by you, proving your
ignorance, and that you are a pathological liar.

Your choosing to ignore the evidence doesn't negate that it does prove
you to be wrong, just that you are incapable of learning.

You can continue this way, and when you are gone, all people will
remember you for is what an idiot you were.

Your choice.

On 6/13/2022 7:31 PM, Richard Damon wrote:
> On 6/13/22 8:20 PM, olcott wrote:
>> On 6/13/2022 7:06 PM, Richard Damon wrote:
>>>
>>> On 6/13/22 7:25 PM, olcott wrote:
>>>> On 6/13/2022 6:18 PM, Richard Damon wrote:
>>>>>
>>>>> On 6/13/22 1:51 PM, olcott wrote:
>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
>>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
>>>>>>>>>> *The criterion measure for a simulating halt decider SHD*
>>>>>>>>>> When the correct partial simulation of the input matches a
>>>>>>>>>> non-halting behavior pattern such that it can be correctly
>>>>>>>>>> determined that a correct and complete simulation of the input
>>>>>>>>>> would never stop running, or reach the final state of this input
>>>>>>>>>> then the SHD aborts its simulation and returns 0.
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> *H and P match the above halting problem relationship to each
>>>>>>>>>> other*
>>>>>>>>>>
>>>>>>>>>> void P(u32 x)
>>>>>>>>>> {
>>>>>>>>>> if (H(x, x))
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> _P()
>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>
>>>>>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>>>>> Because the seventh instruction of P repeats this process we can
>>>>>>>>>> know with complete certainty that the emulated P never reaches
>>>>>>>>>> its
>>>>>>>>>> final “ret” instruction, thus never halts.
>>>>>>>>> So your case is that you have dry run P(P) and determined that it
>>>>>>>>> never halts. Additionally H(P,P) reports non-halting. Therefore
>>>>>>>>> you
>>>>>>>>> conclude that H is correct.
>>>>>>>>
>>>>>>>> In the above case when H(P,P) partially emulates its input it
>>>>>>>> correctly determines that a correct and complete emulation of its
>>>>>>>> input would never stop running or reach the "ret" instruction of P.
>>>>>>>> Instead it would be stuck in infinitely recursive emulation.
>>>>>>>>
>>>>>>>> I have updated the algorithm so that it is a pure function of its
>>>>>>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>>>>>>> machine address) is able to look though the prior execution
>>>>>>>> trace and
>>>>>>>> see that P is calling H with the same arguments that it was called
>>>>>>>> with and there are no instructions in P that would break this
>>>>>>>> cycle.
>>>>>>> Naive.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> The last paragraph has been extensively reviewed and validated on
>>>>>> another forum, thus saying that it is simply Naive carries zero
>>>>>> weight.
>>>>>>
>>>>>> The only way that the last paragraph can be rebutted is to find a
>>>>>> counter-example that proves it to be incorrect.
>>>>>>
>>>>>
>>>>> Can you point to the message where someone actually agreed with
>>>>> your conclusion?
>>>>>
>>>>> I don't remember seeing one, so I think this is another of your lies.
>>>>
>>>> The last paragraph has been extensively reviewed and validated on
>>>> another forum, not USENET.
>>>>
>>>> Ultimately the truth of it depends on the fact that zero correct
>>>> rebuttals exist.
>>>>
>>>
>>> Nope, lack of evidence of error is not evidence of lack of error.
>> If there has been no evidence that anyone has presented then this is
>> not proof at all that the claim is true.
>>
>> If there is no evidence that anyone could ever possibly present then
>> this is proof that the claim is true.
>>
>
>
> Evidence of error HAS been given, and IGNRORED by you, proving your
> ignorance, and that you are a pathological liar.
>

Only the rebuttals that you and Flibble provide are woefully incorrect.
You can't even understand that a dead process does not continue to
execute and Flibble cannot understand that unreachable code has no
effect on behavior.

--
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 6/13/22 8:45 PM, olcott wrote:
> On 6/13/2022 7:31 PM, Richard Damon wrote:
>> On 6/13/22 8:20 PM, olcott wrote:
>>> On 6/13/2022 7:06 PM, Richard Damon wrote:
>>>>
>>>> On 6/13/22 7:25 PM, olcott wrote:
>>>>> On 6/13/2022 6:18 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 6/13/22 1:51 PM, olcott wrote:
>>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>
>>>>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
>>>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
>>>>>>>>>>> *The criterion measure for a simulating halt decider SHD*
>>>>>>>>>>> When the correct partial simulation of the input matches a
>>>>>>>>>>> non-halting behavior pattern such that it can be correctly
>>>>>>>>>>> determined that a correct and complete simulation of the input
>>>>>>>>>>> would never stop running, or reach the final state of this input
>>>>>>>>>>> then the SHD aborts its simulation and returns 0.
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> *H and P match the above halting problem relationship to each
>>>>>>>>>>> other*
>>>>>>>>>>>
>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>> {
>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>> return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> _P()
>>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>
>>>>>>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>>>>>> Because the seventh instruction of P repeats this process we can
>>>>>>>>>>> know with complete certainty that the emulated P never
>>>>>>>>>>> reaches its
>>>>>>>>>>> final “ret” instruction, thus never halts.
>>>>>>>>>> So your case is that you have dry run P(P) and determined that it
>>>>>>>>>> never halts. Additionally H(P,P) reports non-halting.
>>>>>>>>>> Therefore you
>>>>>>>>>> conclude that H is correct.
>>>>>>>>>
>>>>>>>>> In the above case when H(P,P) partially emulates its input it
>>>>>>>>> correctly determines that a correct and complete emulation of its
>>>>>>>>> input would never stop running or reach the "ret" instruction
>>>>>>>>> of P.
>>>>>>>>> Instead it would be stuck in infinitely recursive emulation.
>>>>>>>>>
>>>>>>>>> I have updated the algorithm so that it is a pure function of its
>>>>>>>>> inputs. As soon as P calls H for the first time, H (knowing its
>>>>>>>>> own
>>>>>>>>> machine address) is able to look though the prior execution
>>>>>>>>> trace and
>>>>>>>>> see that P is calling H with the same arguments that it was called
>>>>>>>>> with and there are no instructions in P that would break this
>>>>>>>>> cycle.
>>>>>>>> Naive.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> The last paragraph has been extensively reviewed and validated on
>>>>>>> another forum, thus saying that it is simply Naive carries zero
>>>>>>> weight.
>>>>>>>
>>>>>>> The only way that the last paragraph can be rebutted is to find a
>>>>>>> counter-example that proves it to be incorrect.
>>>>>>>
>>>>>>
>>>>>> Can you point to the message where someone actually agreed with
>>>>>> your conclusion?
>>>>>>
>>>>>> I don't remember seeing one, so I think this is another of your lies.
>>>>>
>>>>> The last paragraph has been extensively reviewed and validated on
>>>>> another forum, not USENET.
>>>>>
>>>>> Ultimately the truth of it depends on the fact that zero correct
>>>>> rebuttals exist.
>>>>>
>>>>
>>>> Nope, lack of evidence of error is not evidence of lack of error.
>>> If there has been no evidence that anyone has presented then this is
>>> not proof at all that the claim is true.
>>>
>>> If there is no evidence that anyone could ever possibly present then
>>> this is proof that the claim is true.
>>>
>>
>>
>> Evidence of error HAS been given, and IGNRORED by you, proving your
>> ignorance, and that you are a pathological liar.
>>
>
> Only the rebuttals that you and Flibble provide are woefully incorrect.
> You can't even understand that a dead process does not continue to
> execute and Flibble cannot understand that unreachable code has no
> effect on behavior.
>

Show the ACTUAL error.

Your "Dead Process" claim just shows your ignorance, as you have been
told multiple times (but seem to dumb to understand) that Halting is a
property of the TURING MACHINE, not the simulaiton of it, and the TURING
MACHINE doesn't halt until it reaches a final state

What is wrong with that statement, or are you going to admit to being
ignorant of the meaning of the words.

You just keep repeating your LIES that have been PROVEN incorrect, the
world knows you are wrong, the universe knows you are wrong, the Theory
knows you are wrong.

You are just wrong, and are going to die as the promoter of errors.

On Mon, 13 Jun 2022 19:45:49 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/13/2022 7:31 PM, Richard Damon wrote:
> > On 6/13/22 8:20 PM, olcott wrote:
> >> On 6/13/2022 7:06 PM, Richard Damon wrote:
> >>>
> >>> On 6/13/22 7:25 PM, olcott wrote:
> >>>> On 6/13/2022 6:18 PM, Richard Damon wrote:
> >>>>>
> >>>>> On 6/13/22 1:51 PM, olcott wrote:
> >>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
> >>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
> >>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
> >>>>>>>>>> *The criterion measure for a simulating halt decider SHD*
> >>>>>>>>>> When the correct partial simulation of the input matches a
> >>>>>>>>>> non-halting behavior pattern such that it can be correctly
> >>>>>>>>>> determined that a correct and complete simulation of the
> >>>>>>>>>> input would never stop running, or reach the final state
> >>>>>>>>>> of this input then the SHD aborts its simulation and
> >>>>>>>>>> returns 0.
> >>>>>>>>>>
> >>>>>>>>>> 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
> >>>>>>>>>>
> >>>>>>>>>> *H and P match the above halting problem relationship to
> >>>>>>>>>> each other*
> >>>>>>>>>>
> >>>>>>>>>> void P(u32 x)
> >>>>>>>>>> {
> >>>>>>>>>> if (H(x, x))
> >>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>> return;
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> int main()
> >>>>>>>>>> {
> >>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> _P()
> >>>>>>>>>> [00001352](01) 55 push ebp
> >>>>>>>>>> [00001353](02) 8bec mov ebp,esp
> >>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>> [00001358](01) 50 push eax // push P
> >>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>> [0000135c](01) 51 push ecx // push P
> >>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>>>>>>>> [00001362](03) 83c408 add esp,+08
> >>>>>>>>>> [00001365](02) 85c0 test eax,eax
> >>>>>>>>>> [00001367](02) 7402 jz 0000136b
> >>>>>>>>>> [00001369](02) ebfe jmp 00001369
> >>>>>>>>>> [0000136b](01) 5d pop ebp
> >>>>>>>>>> [0000136c](01) c3 ret
> >>>>>>>>>> Size in bytes:(0027) [0000136c]
> >>>>>>>>>>
> >>>>>>>>>> It is completely obvious that when H(P,P) correctly
> >>>>>>>>>> emulates its input that it must emulate the first seven
> >>>>>>>>>> instructions of P. Because the seventh instruction of P
> >>>>>>>>>> repeats this process we can know with complete certainty
> >>>>>>>>>> that the emulated P never reaches its
> >>>>>>>>>> final “ret” instruction, thus never halts.
> >>>>>>>>> So your case is that you have dry run P(P) and determined
> >>>>>>>>> that it never halts. Additionally H(P,P) reports
> >>>>>>>>> non-halting. Therefore you
> >>>>>>>>> conclude that H is correct.
> >>>>>>>>
> >>>>>>>> In the above case when H(P,P) partially emulates its input it
> >>>>>>>> correctly determines that a correct and complete emulation
> >>>>>>>> of its input would never stop running or reach the "ret"
> >>>>>>>> instruction of P. Instead it would be stuck in infinitely
> >>>>>>>> recursive emulation.
> >>>>>>>>
> >>>>>>>> I have updated the algorithm so that it is a pure function
> >>>>>>>> of its inputs. As soon as P calls H for the first time, H
> >>>>>>>> (knowing its own machine address) is able to look though the
> >>>>>>>> prior execution trace and
> >>>>>>>> see that P is calling H with the same arguments that it was
> >>>>>>>> called with and there are no instructions in P that would
> >>>>>>>> break this cycle.
> >>>>>>> Naive.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> The last paragraph has been extensively reviewed and validated
> >>>>>> on another forum, thus saying that it is simply Naive carries
> >>>>>> zero weight.
> >>>>>>
> >>>>>> The only way that the last paragraph can be rebutted is to
> >>>>>> find a counter-example that proves it to be incorrect.
> >>>>>>
> >>>>>
> >>>>> Can you point to the message where someone actually agreed with
> >>>>> your conclusion?
> >>>>>
> >>>>> I don't remember seeing one, so I think this is another of your
> >>>>> lies.
> >>>>
> >>>> The last paragraph has been extensively reviewed and validated on
> >>>> another forum, not USENET.
> >>>>
> >>>> Ultimately the truth of it depends on the fact that zero correct
> >>>> rebuttals exist.
> >>>>
> >>>
> >>> Nope, lack of evidence of error is not evidence of lack of error.
> >>>
> >> If there has been no evidence that anyone has presented then this
> >> is not proof at all that the claim is true.
> >>
> >> If there is no evidence that anyone could ever possibly present
> >> then this is proof that the claim is true.
> >>
> >
> >
> > Evidence of error HAS been given, and IGNRORED by you, proving your
> > ignorance, and that you are a pathological liar.
> >
>
> Only the rebuttals that you and Flibble provide are woefully
> incorrect. You can't even understand that a dead process does not
> continue to execute and Flibble cannot understand that unreachable
> code has no effect on behavior.
Of course I understand that unreachable code has no effect on
behaviour; what has an effect on behaviour is changing unreachable code
to be reachable -- i.e. what *if* P isn't pathological (i.e. it halts),
your H never returns to allow such code to be reach which is an error:
all halting deciders return a value to their caller.

/Flibble

On 6/13/2022 8:15 PM, Mr Flibble wrote:
> On Mon, 13 Jun 2022 19:45:49 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/13/2022 7:31 PM, Richard Damon wrote:
>>> On 6/13/22 8:20 PM, olcott wrote:
>>>> On 6/13/2022 7:06 PM, Richard Damon wrote:
>>>>>
>>>>> On 6/13/22 7:25 PM, olcott wrote:
>>>>>> On 6/13/2022 6:18 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 6/13/22 1:51 PM, olcott wrote:
>>>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
>>>>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
>>>>>>>>>>>> *The criterion measure for a simulating halt decider SHD*
>>>>>>>>>>>> When the correct partial simulation of the input matches a
>>>>>>>>>>>> non-halting behavior pattern such that it can be correctly
>>>>>>>>>>>> determined that a correct and complete simulation of the
>>>>>>>>>>>> input would never stop running, or reach the final state
>>>>>>>>>>>> of this input then the SHD aborts its simulation and
>>>>>>>>>>>> returns 0.
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>> *H and P match the above halting problem relationship to
>>>>>>>>>>>> each other*
>>>>>>>>>>>>
>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>> {
>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> _P()
>>>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>>
>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
>>>>>>>>>>>> emulates its input that it must emulate the first seven
>>>>>>>>>>>> instructions of P. Because the seventh instruction of P
>>>>>>>>>>>> repeats this process we can know with complete certainty
>>>>>>>>>>>> that the emulated P never reaches its
>>>>>>>>>>>> final “ret” instruction, thus never halts.
>>>>>>>>>>> So your case is that you have dry run P(P) and determined
>>>>>>>>>>> that it never halts. Additionally H(P,P) reports
>>>>>>>>>>> non-halting. Therefore you
>>>>>>>>>>> conclude that H is correct.
>>>>>>>>>>
>>>>>>>>>> In the above case when H(P,P) partially emulates its input it
>>>>>>>>>> correctly determines that a correct and complete emulation
>>>>>>>>>> of its input would never stop running or reach the "ret"
>>>>>>>>>> instruction of P. Instead it would be stuck in infinitely
>>>>>>>>>> recursive emulation.
>>>>>>>>>>
>>>>>>>>>> I have updated the algorithm so that it is a pure function
>>>>>>>>>> of its inputs. As soon as P calls H for the first time, H
>>>>>>>>>> (knowing its own machine address) is able to look though the
>>>>>>>>>> prior execution trace and
>>>>>>>>>> see that P is calling H with the same arguments that it was
>>>>>>>>>> called with and there are no instructions in P that would
>>>>>>>>>> break this cycle.
>>>>>>>>> Naive.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> The last paragraph has been extensively reviewed and validated
>>>>>>>> on another forum, thus saying that it is simply Naive carries
>>>>>>>> zero weight.
>>>>>>>>
>>>>>>>> The only way that the last paragraph can be rebutted is to
>>>>>>>> find a counter-example that proves it to be incorrect.
>>>>>>>>
>>>>>>>
>>>>>>> Can you point to the message where someone actually agreed with
>>>>>>> your conclusion?
>>>>>>>
>>>>>>> I don't remember seeing one, so I think this is another of your
>>>>>>> lies.
>>>>>>
>>>>>> The last paragraph has been extensively reviewed and validated on
>>>>>> another forum, not USENET.
>>>>>>
>>>>>> Ultimately the truth of it depends on the fact that zero correct
>>>>>> rebuttals exist.
>>>>>>
>>>>>
>>>>> Nope, lack of evidence of error is not evidence of lack of error.
>>>>>
>>>> If there has been no evidence that anyone has presented then this
>>>> is not proof at all that the claim is true.
>>>>
>>>> If there is no evidence that anyone could ever possibly present
>>>> then this is proof that the claim is true.
>>>>
>>>
>>>
>>> Evidence of error HAS been given, and IGNRORED by you, proving your
>>> ignorance, and that you are a pathological liar.
>>>
>>
>> Only the rebuttals that you and Flibble provide are woefully
>> incorrect. You can't even understand that a dead process does not
>> continue to execute and Flibble cannot understand that unreachable
>> code has no effect on behavior.
>
> Of course I understand that unreachable code has no effect on
> behaviour; what has an effect on behaviour is changing unreachable code
> to be reachable -- i.e. what *if* P isn't pathological (i.e. it halts),

On 6/13/22 9:15 PM, Mr Flibble wrote:
> On Mon, 13 Jun 2022 19:45:49 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/13/2022 7:31 PM, Richard Damon wrote:
>>> On 6/13/22 8:20 PM, olcott wrote:
>>>> On 6/13/2022 7:06 PM, Richard Damon wrote:
>>>>>
>>>>> On 6/13/22 7:25 PM, olcott wrote:
>>>>>> On 6/13/2022 6:18 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 6/13/22 1:51 PM, olcott wrote:
>>>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
>>>>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
>>>>>>>>>>>> *The criterion measure for a simulating halt decider SHD*
>>>>>>>>>>>> When the correct partial simulation of the input matches a
>>>>>>>>>>>> non-halting behavior pattern such that it can be correctly
>>>>>>>>>>>> determined that a correct and complete simulation of the
>>>>>>>>>>>> input would never stop running, or reach the final state
>>>>>>>>>>>> of this input then the SHD aborts its simulation and
>>>>>>>>>>>> returns 0.
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>> *H and P match the above halting problem relationship to
>>>>>>>>>>>> each other*
>>>>>>>>>>>>
>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>> {
>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> _P()
>>>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>>
>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
>>>>>>>>>>>> emulates its input that it must emulate the first seven
>>>>>>>>>>>> instructions of P. Because the seventh instruction of P
>>>>>>>>>>>> repeats this process we can know with complete certainty
>>>>>>>>>>>> that the emulated P never reaches its
>>>>>>>>>>>> final “ret” instruction, thus never halts.
>>>>>>>>>>> So your case is that you have dry run P(P) and determined
>>>>>>>>>>> that it never halts. Additionally H(P,P) reports
>>>>>>>>>>> non-halting. Therefore you
>>>>>>>>>>> conclude that H is correct.
>>>>>>>>>>
>>>>>>>>>> In the above case when H(P,P) partially emulates its input it
>>>>>>>>>> correctly determines that a correct and complete emulation
>>>>>>>>>> of its input would never stop running or reach the "ret"
>>>>>>>>>> instruction of P. Instead it would be stuck in infinitely
>>>>>>>>>> recursive emulation.
>>>>>>>>>>
>>>>>>>>>> I have updated the algorithm so that it is a pure function
>>>>>>>>>> of its inputs. As soon as P calls H for the first time, H
>>>>>>>>>> (knowing its own machine address) is able to look though the
>>>>>>>>>> prior execution trace and
>>>>>>>>>> see that P is calling H with the same arguments that it was
>>>>>>>>>> called with and there are no instructions in P that would
>>>>>>>>>> break this cycle.
>>>>>>>>> Naive.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> The last paragraph has been extensively reviewed and validated
>>>>>>>> on another forum, thus saying that it is simply Naive carries
>>>>>>>> zero weight.
>>>>>>>>
>>>>>>>> The only way that the last paragraph can be rebutted is to
>>>>>>>> find a counter-example that proves it to be incorrect.
>>>>>>>>
>>>>>>>
>>>>>>> Can you point to the message where someone actually agreed with
>>>>>>> your conclusion?
>>>>>>>
>>>>>>> I don't remember seeing one, so I think this is another of your
>>>>>>> lies.
>>>>>>
>>>>>> The last paragraph has been extensively reviewed and validated on
>>>>>> another forum, not USENET.
>>>>>>
>>>>>> Ultimately the truth of it depends on the fact that zero correct
>>>>>> rebuttals exist.
>>>>>>
>>>>>
>>>>> Nope, lack of evidence of error is not evidence of lack of error.
>>>>>
>>>> If there has been no evidence that anyone has presented then this
>>>> is not proof at all that the claim is true.
>>>>
>>>> If there is no evidence that anyone could ever possibly present
>>>> then this is proof that the claim is true.
>>>>
>>>
>>>
>>> Evidence of error HAS been given, and IGNRORED by you, proving your
>>> ignorance, and that you are a pathological liar.
>>>
>>
>> Only the rebuttals that you and Flibble provide are woefully
>> incorrect. You can't even understand that a dead process does not
>> continue to execute and Flibble cannot understand that unreachable
>> code has no effect on behavior.
>
> Of course I understand that unreachable code has no effect on
> behaviour; what has an effect on behaviour is changing unreachable code
> to be reachable -- i.e. what *if* P isn't pathological (i.e. it halts),
> your H never returns to allow such code to be reach which is an error:
> all halting deciders return a value to their caller.
>
> /Flibble
>

On 6/13/22 9:25 PM, olcott wrote:
> On 6/13/2022 8:15 PM, Mr Flibble wrote:
>> On Mon, 13 Jun 2022 19:45:49 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/13/2022 7:31 PM, Richard Damon wrote:
>>>> On 6/13/22 8:20 PM, olcott wrote:
>>>>> On 6/13/2022 7:06 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 6/13/22 7:25 PM, olcott wrote:
>>>>>>> On 6/13/2022 6:18 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 6/13/22 1:51 PM, olcott wrote:
>>>>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>> On 6/13/2022 2:44 AM, Malcolm McLean wrote:
>>>>>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
>>>>>>>>>>>>> *The criterion measure for a simulating halt decider SHD*
>>>>>>>>>>>>> When the correct partial simulation of the input matches a
>>>>>>>>>>>>> non-halting behavior pattern such that it can be correctly
>>>>>>>>>>>>> determined that a correct and complete simulation of the
>>>>>>>>>>>>> input would never stop running, or reach the final state
>>>>>>>>>>>>> of this input then the SHD aborts its simulation and
>>>>>>>>>>>>> returns 0.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>> *H and P match the above halting problem relationship to
>>>>>>>>>>>>> each other*
>>>>>>>>>>>>>
>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>> return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> _P()
>>>>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
>>>>>>>>>>>>> emulates its input that it must emulate the first seven
>>>>>>>>>>>>> instructions of P. Because the seventh instruction of P
>>>>>>>>>>>>> repeats this process we can know with complete certainty
>>>>>>>>>>>>> that the emulated P never reaches its
>>>>>>>>>>>>> final “ret” instruction, thus never halts.
>>>>>>>>>>>> So your case is that you have dry run P(P) and determined
>>>>>>>>>>>> that it never halts. Additionally H(P,P) reports
>>>>>>>>>>>> non-halting. Therefore you
>>>>>>>>>>>> conclude that H is correct.
>>>>>>>>>>>
>>>>>>>>>>> In the above case when H(P,P) partially emulates its input it
>>>>>>>>>>> correctly determines that a correct and complete emulation
>>>>>>>>>>> of its input would never stop running or reach the "ret"
>>>>>>>>>>> instruction of P. Instead it would be stuck in infinitely
>>>>>>>>>>> recursive emulation.
>>>>>>>>>>>
>>>>>>>>>>> I have updated the algorithm so that it is a pure function
>>>>>>>>>>> of its inputs. As soon as P calls H for the first time, H
>>>>>>>>>>> (knowing its own machine address) is able to look though the
>>>>>>>>>>> prior execution trace and
>>>>>>>>>>> see that P is calling H with the same arguments that it was
>>>>>>>>>>> called with and there are no instructions in P that would
>>>>>>>>>>> break this cycle.
>>>>>>>>>> Naive.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> The last paragraph has been extensively reviewed and validated
>>>>>>>>> on another forum, thus saying that it is simply Naive carries
>>>>>>>>> zero weight.
>>>>>>>>>
>>>>>>>>> The only way that the last paragraph can be rebutted is to
>>>>>>>>> find a counter-example that proves it to be incorrect.
>>>>>>>>
>>>>>>>> Can you point to the message where someone actually agreed with
>>>>>>>> your conclusion?
>>>>>>>>
>>>>>>>> I don't remember seeing one, so I think this is another of your
>>>>>>>> lies.
>>>>>>>
>>>>>>> The last paragraph has been extensively reviewed and validated on
>>>>>>> another forum, not USENET.
>>>>>>>
>>>>>>> Ultimately the truth of it depends on the fact that zero correct
>>>>>>> rebuttals exist.
>>>>>>
>>>>>> Nope, lack of evidence of error is not evidence of lack of error.
>>>>> If there has been no evidence that anyone has presented then this
>>>>> is not proof at all that the claim is true.
>>>>>
>>>>> If there is no evidence that anyone could ever possibly present
>>>>> then this is proof that the claim is true.
>>>>
>>>>
>>>> Evidence of error HAS been given, and IGNRORED by you, proving your
>>>> ignorance, and that you are a pathological liar.
>>>
>>> Only the rebuttals that you and Flibble provide are woefully
>>> incorrect. You can't even understand that a dead process does not
>>> continue to execute and Flibble cannot understand that unreachable
>>> code has no effect on behavior.
>> Of course I understand that unreachable code has no effect on
>> behaviour; what has an effect on behaviour is changing unreachable code
>> to be reachable -- i.e. what *if* P isn't pathological (i.e. it halts),
>
> (1) It is no longer P it is X
> (2) H(X,X)==1
>

On 2022-06-13 11:51, olcott wrote:
> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>> On Mon, 13 Jun 2022 09:27:08 -0500
>> olcott <NoOne@NoWhere.com> wrote:

>>> I have updated the algorithm so that it is a pure function of its
>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>> machine address) is able to look though the prior execution trace and
>>> see that P is calling H with the same arguments that it was called
>>> with and there are no instructions in P that would break this cycle.
>> Naive.
>>
>> /Flibble
>>
>
> The last paragraph has been extensively reviewed and validated on
> another forum, thus saying that it is simply Naive carries zero weight.

And which forum would that be?

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 6/13/2022 10:46 PM, André G. Isaak wrote:
> On 2022-06-13 11:51, olcott wrote:
>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>
>>>> I have updated the algorithm so that it is a pure function of its
>>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>>> machine address) is able to look though the prior execution trace and
>>>> see that P is calling H with the same arguments that it was called
>>>> with and there are no instructions in P that would break this cycle.
>>> Naive.
>>>
>>> /Flibble
>>>
>>
>> The last paragraph has been extensively reviewed and validated on
>> another forum, thus saying that it is simply Naive carries zero weight.
>
> And which forum would that be?
>
> André
>
>

That is irrelevant. You should know that Validity supersedes
credibility. Do you believe (like 40% of the electorate) that the
consensus of fools correctly determines the truth?

--
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 2022-06-13 21:50, olcott wrote:
> On 6/13/2022 10:46 PM, André G. Isaak wrote:
>> On 2022-06-13 11:51, olcott wrote:
>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>
>>>>> I have updated the algorithm so that it is a pure function of its
>>>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>>>> machine address) is able to look though the prior execution trace and
>>>>> see that P is calling H with the same arguments that it was called
>>>>> with and there are no instructions in P that would break this cycle.
>>>> Naive.
>>>>
>>>> /Flibble
>>>>
>>>
>>> The last paragraph has been extensively reviewed and validated on
>>> another forum, thus saying that it is simply Naive carries zero weight.
>>
>> And which forum would that be?
>>
>> André
>>
>>
>
> That is irrelevant.

It's certainly relevant to anyone interested in reading those reviews.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 6/13/2022 11:59 PM, André G. Isaak wrote:
> On 2022-06-13 21:50, olcott wrote:
>> On 6/13/2022 10:46 PM, André G. Isaak wrote:
>>> On 2022-06-13 11:51, olcott wrote:
>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>>>> I have updated the algorithm so that it is a pure function of its
>>>>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>>>>> machine address) is able to look though the prior execution trace and
>>>>>> see that P is calling H with the same arguments that it was called
>>>>>> with and there are no instructions in P that would break this cycle.
>>>>> Naive.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> The last paragraph has been extensively reviewed and validated on
>>>> another forum, thus saying that it is simply Naive carries zero weight.
>>>
>>> And which forum would that be?
>>>
>>> André
>>>
>>>
>>
>> That is irrelevant.
>
> It's certainly relevant to anyone interested in reading those reviews.
>
> André
>
>

I do appreciate that you are reviewing my work.
So you don't feel technically qualified to assess the merits of this
directly yourself? The impossibility of finding a valid counter-example
disproving the claim counts as proof that the claim is true.

--
Copyright 2022 Pete Olcott

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

On 6/13/22 11:50 PM, olcott wrote:
> On 6/13/2022 10:46 PM, André G. Isaak wrote:
>> On 2022-06-13 11:51, olcott wrote:
>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>
>>>>> I have updated the algorithm so that it is a pure function of its
>>>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>>>> machine address) is able to look though the prior execution trace and
>>>>> see that P is calling H with the same arguments that it was called
>>>>> with and there are no instructions in P that would break this cycle.
>>>> Naive.
>>>>
>>>> /Flibble
>>>>
>>>
>>> The last paragraph has been extensively reviewed and validated on
>>> another forum, thus saying that it is simply Naive carries zero weight.
>>
>> And which forum would that be?
>>
>> André
>>
>>
>
> That is irrelevant. You should know that Validity supersedes
> credibility. Do you believe (like 40% of the electorate) that the
> consensus of fools correctly determines the truth?
>

Yes, and since you have none of the later, verification of validity is
important.

You SAYING you have reviewed it elsewhere means absolutely nothing, but
if you have, then saying where should be easy and simple. If you
actually haven't, your lie gets revealed.

YOU of course know the answer for certain if you have done this.

If you have, why hide the proof and add fuel to the, thus false, claims
that you are lying about this. If you haven't, you need to ask yourself
why did you lie about it?