On 6/4/2022 11:11 AM, Richard Damon wrote:
>
> 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,

BRAIN DEAD MORONS DON'T GET THIS:
Because we verified that H(P,P) emulates the first seven instructions of
P we know that it will keep doing this every time that H(P,P) is invoked
as long as the simulation continues.

This is the exact same process that H0(Infinite_Loop) correctly
determines that its input specifies infinite behavior.

BRAIN DEAD MORONS believe that infinite behavior can only be correctly
recognized after infinite simulation.

--
Copyright 2022 Pete Olcott

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