On 6/4/22 2:39 PM, olcott wrote:
> On 6/4/2022 1:31 PM, Richard Damon wrote:
>> On 6/4/22 2:14 PM, olcott wrote:
>>> On 6/4/2022 1:09 PM, Richard Damon wrote:
>>>> On 6/4/22 1:23 PM, olcott wrote:
>>>>> On 6/4/2022 12:15 PM, Richard Damon wrote:
>>>>>> On 6/4/22 12:25 PM, olcott wrote:
>>>>>>> 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.
>>>>>>
>>>>>> Nope, different invocations of H's so not part of the same trace.
>>>>> That is what a brain dead moron (or a despicable liar) would say.
>>>>>
>>>>> The whole point is whether or not the correct x86 emulation of the
>>>>> original input would ever reach its final "ret" instruction.
>>>>>
>>>>
>>>> Right, the correct x86 emulation of the ORIGINAL input. The second
>>>> layer of simulation is
>>>
>>> invoked in the same execution chain that invokes the first layer and
>>> is thus a subordinate aspect of this first emulation.
>>>
>>
>> Nope, the execution of that is NOT part of the actual execution trace
>> of the original input.
>
> When you start denying easily verifiable facts I quit even glancing at
> what you say for at least a week.
>

When you start denying easily verified truth, it becomes clear that you
are lying. Run the program P(P) in a REAL debugger and single step
through it. Do you EVER actually get back to the original code like your
trace shows? It won't if your H is actually a real emulator.

I don't think you even know the actual MEANING of TRUTH.

By sticking your fingers in your ears and saying "I can't hear you", and
ignoring correct rebutalls, you are just proving that you don't know
what you are talking about.

You legacy is going to be that of a lying kook that just didn't know
what he was talking about.

Think about it.