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.

--
Copyright 2022 Pete Olcott

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