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.

>
>> If H doesn't detects them as infinitely nested, and never aborts, H
>> simulates
>> forever, because they are infinitely nested.
>>
>> Either way, H gets it wrong.
>>
>
> So you are saying that it is impossible for H0 to correctly detect that
> _Infinite_Loop() would never reach its final "ret" instruction because
> as soon _Infinite_Loop() has had its simulation aborted it magically
> leaps to its "ret" instruction.

Nope, he NEVER said that. You apparently just can't read, and thus prove
your stupidity.

You keep on making this mistake, that when people say your H can't do
one thing about P, that you say "Are you saying it can't do it for this
other trivial program?"

You are a great example of someone using many different logical
fallicies in their arguement.

You use them SO well, it really seems to be deliberate.

All you have proved so far is that you just don't understand how to do
proper logical arguments, and are appatently way out of your depth in
what you are talking about.

>
>> My own view is that you've actually got something interesting here.
>> That isn't
>> shared by other posters, probably because you've put them off by
>> claims to have
>> "solved the halting problem", repeated at great length.
>
>