On 6/4/22 11:51 AM, olcott wrote:
> On 6/4/2022 10:38 AM, Richard Damon wrote:
>> On 6/4/22 11:11 AM, olcott wrote:
>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>
>>>>>>>>> This post assumes that you already know my work, otherwise please
>>>>>>>>> read the linked paper provided below. This work is based on the
>>>>>>>>> x86utm operating system that was created so that every detail
>>>>>>>>> of the
>>>>>>>>> halting problem could be directly examined in C/x86.
>>>>>>>>>
>>>>>>>>> void Infinite_Loop()
>>>>>>>>> {
>>>>>>>>>      HERE: goto HERE;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>      Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _Infinite_Loop()
>>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>>> [00001348](01)  c3              ret
>>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>>
>>>>>>>>> It is totally obvious that the _Infinite_Loop() would never halt
>>>>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>>>>> instruction).
>>>>>>>>>
>>>>>>>>> Equally obvious is the fact that a partial x86 emulation of this
>>>>>>>>> input conclusively proves that its complete x86 emulation would
>>>>>>>>> never
>>>>>>>>> halt.
>>>>>>>>>
>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>>>> at:212343
>>>>>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>>>>>>>
>>>>>>>>> The exact same reasoning applies to the correctly emulated
>>>>>>>>> input to
>>>>>>>>> H(P,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 repeats this process we can
>>>>>>>>> know with
>>>>>>>>> complete certainty that the emulated P never reaches its final
>>>>>>>>> “ret”
>>>>>>>>> instruction, thus never halts.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>>>> (V5)
>>>>>>>>>
>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Unfortunately your logic is such that the decision as to whether
>>>>>>>> or not
>>>>>>>> to enter the infinite loop is predicated on an infinite
>>>>>>>> recursion (call
>>>>>>>> H) that is not present in the Halting Problem proofs you are
>>>>>>>> attempting
>>>>>>>> to refute.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> It is when a simulating halt decider is assumed.
>>>>>>
>>>>>> But you can not assume that an actual simulating Halt Decider
>>>>>> actually
>>>>>> exists.
>>>>> I proved that H(P,P)==0 is correct.
>>>>>
>>>> You've got nested simulations.
>>>> If H detects them as infinitely nested, and aborts, they are no
>>>> longer infinitely
>>>> nested, so it gets the wrong answer (as happens here).
>>>
>>> I can't understand how you can be so wrong about this. It is like you
>>> make sure to never read anything that I say before spouting off a
>>> canned rebuttal.
>>>
>>> void Infinite_Loop()
>>> {
>>>    HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H0(Infinite_Loop));
>>> }
>>>
>>> _Infinite_Loop()
>>> [00001342](01)  55              push ebp
>>> [00001343](02)  8bec            mov ebp,esp
>>> [00001345](02)  ebfe            jmp 00001345
>>> [00001347](01)  5d              pop ebp
>>> [00001348](01)  c3              ret
>>> Size in bytes:(0007) [00001348]
>>>
>>> In the same way that H0 detects that the complete x86 emulation of
>>> _Infinite_Loop() would never reach its final "ret" instruction H(P,P)
>>> on the basis of a partial simulation H(P,P) detects that the complete
>>> x86 emulation of its input would never reach its final "ret"
>>> instruction.
>>>
>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?
>>>
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>
>> Right, and for the simulation of H(P,P), that is all that happen
>>
>>
>>>
>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY
>>
>>
>> And the input to H(P,P) does TERMINATE NORMALLY when correct simulated.
>>
> THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
>
> _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 repeats this process we can know with complete
> certainty that the emulated P never reaches its final “ret” instruction,
> thus never halts.
>
>

Right, it emulates the first seven instructions, and then the eigth
instruction that the input specifies, which is a 000011a2, which you
haven't specified in this listing.

That is the ONLY CORRECT way to emulate the input per the definition of
an x86 processort.

The seventh doesn't "Just repeat to proces", it asks H to make a
decision, and that decision process is PART of the program P, so any
emulation of the program P must include it.

There is nothing in the "definition of an x86 processor" that means
anything like what you are claiming.

You just don't seem to understand what a PROGRAM is.

FAIL.