On 4/23/22 1:35 PM, olcott wrote:
> On 4/23/2022 12:29 PM, wij wrote:
>> On Sunday, 24 April 2022 at 01:20:23 UTC+8, olcott wrote:
>>> On 4/23/2022 12:15 PM, wij wrote:
>>>> On Sunday, 24 April 2022 at 00:52:00 UTC+8, olcott wrote:
>>>>> On 4/23/2022 11:43 AM, wij wrote:
>>>>>> On Sunday, 24 April 2022 at 00:34:55 UTC+8, olcott wrote:
>>>>>>> On 4/23/2022 11:29 AM, wij wrote:
>>>>>>>> On Sunday, 24 April 2022 at 00:05:19 UTC+8, olcott wrote:
>>>>>>>>> On 4/23/2022 10:58 AM, wij wrote:
>>>>>>>>>> On Saturday, 23 April 2022 at 22:49:59 UTC+8, olcott wrote:
>>>>>>>>>>> All of my reviewers expect H(P,P) to compute the halt status
>>>>>>>>>>> of P(P),
>>>>>>>>>>> yet the behavior specified by the input to H(P,P) is not the
>>>>>>>>>>> same as the
>>>>>>>>>>> behavior specified by P(P).
>>>>>>>>>>
>>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>>> program and an input, whether the program will finish running,
>>>>>>>>>> or continue to run forever
>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>
>>>>>>>>>> If using this common concept, the halting decider H, when
>>>>>>>>>> given an argument P
>>>>>>>>>> (or P P), is supposed to answer whether P(P) will halt or not.
>>>>>>>>>> This is a very
>>>>>>>>>> simple, easy idea to understand even for teenager students.
>>>>>>>>>>
>>>>>>>>> When this very simple idea is very rigorously examined (as it
>>>>>>>>> is in my
>>>>>>>>> paper) one sees that this requires the halt decider to be a
>>>>>>>>> mind reader
>>>>>>>>> and compute the halt status other than the actual halt status
>>>>>>>>> specified
>>>>>>>>> by its actual input.
>>>>>>>>
>>>>>>>> Your wording/interpretations/paper change all the time. No idea
>>>>>>>> what this new
>>>>>>>> excuse 'mind reader' might mean. As said, the Halting Problem is
>>>>>>>> very simple
>>>>>>>> and intuitive.
>>>>>>>> H should be a decider that computes the actual halt status of
>>>>>>>> P(P). P is the
>>>>>>>> H's actual argument input.
>>>>>>>> I expect you might try to find some bugs of those descriptions
>>>>>>>> to rephrasing it
>>>>>>>> in your favor. But, what would be the point? What is the
>>>>>>>> usefulness of POOP?
>>>>>>> Yet when you carefully examine my paper:
>>>>>>> Anyone that is an expert in the C programming language, the x86
>>>>>>> programming language, exactly how C translates into x86 and what
>>>>>>> an x86
>>>>>>> processor emulator is can easily verify that the correctly simulated
>>>>>>> input to H(P,P) by H specifies a non-halting sequence of
>>>>>>> configurations.
>>>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>
>>>>>>> Simply ignoring the verified facts is a ridiculously foolish was
>>>>>>> to form
>>>>>>> any actual rebuttal.
>>>>>>> --
>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>
>>>>>>> "Talent hits a target no one else can hit;
>>>>>>> Genius hits a target no one else can see."
>>>>>>> Arthur Schopenhauer
>>>>>>
>>>>>> You already verified the fact that H(P,P) will be in an infinite
>>>>>> recursive call
>>>>>> (thus, undecidable). Why you say H(P,P)==false (or true)?
>>>>> You might make a wild guess like this if you make sure to hardly pay
>>>>> attention. When you actually pay close attention and carefully
>>>>> study my
>>>>> paper it is very easy to see that H sees the same infinitely repeating
>>>>> pattern that we see, thus can abort its simulation and reject its
>>>>> input.
>>>>> Begin Local Halt Decider Simulation
>>>>>
>>>>> machine stack stack machine assembly
>>>>> address address data code language
>>>>> ======== ======== ======== ========= =============
>>>>> ...[000009d6][00211368][0021136c] 55 push ebp // enter P
>>>>> ...[000009d7][00211368][0021136c] 8bec mov ebp,esp
>>>>> ...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
>>>>> ...[000009dc][00211364][000009d6] 50 push eax // Push P
>>>>> ...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
>>>>> ...[000009e0][00211360][000009d6] 51 push ecx // Push P
>>>>> ...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
>>>>> ...[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
>>>>> ...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
>>>>> ...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
>>>>> ...[000009dc][0025bd8c][000009d6] 50 push eax // Push P
>>>>> ...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
>>>>> ...[000009e0][0025bd88][000009d6] 51 push ecx // Push P
>>>>> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>>
>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>
>>>>> --
>>>>> Copyright 2022 Pete Olcott
>>>>>
>>>>> "Talent hits a target no one else can hit;
>>>>> Genius hits a target no one else can see."
>>>>> Arthur Schopenhauer
>>>>
>>>> "Local Halt Decider: Infinite Recursion Detected Simulation Stopped"
>>>> means
>>>> your x86utm emulator has encountered an infinite recursive call.
>>>> This is referred to as "undecidable". This is the fact.
>>> So you are saying that after H makes the correct halt status decision
>>> that this correct halt status decision is impossible to make.
>>>
>>> That is just like my example a smashing a Boston cream pie in your face
>>> and while this pie drips from your face you deny that the pie exists.
>>
>> Your H did not show 'correct decision' but 'unreachable' (exactly what
>> the HP says).
>>
>> This is like "0.999..." (or repeating decimal) problems: Infinite
>> repeating
>> simply means INFINITE repeating. Please, respect what it is.
>
> H simulates its input one x86 instruction at a time using an x86
> emulator. As soon as H(P,P) detects the same infinitely repeating
> pattern (that we can all see), it aborts its simulation and rejects its
> input.
>

Except that the pattern is proven to not actually be infinitely
recursive, as tracing the execution of that input shows that the H that
P calls will also make that same decision and abort its simulation and
return and then P stops.

What you have actually shown is that a DIFFERENT H, that doesn't abort
its simulation, would create non-halting behavior for both itself and
the P built on it. That is a DIFFERENT H and thus a DIFFERENT P then the
one this H has, because P INCLUDES the H it calls.

This is actually a fatal flaw in your example, your "string" of P is
incomplete and thus doesn't actually have defined behavior, it calls a
location in memory that it doesn't define. You need to include in your
string for P the copy of H that it is using, and that means that if the
H that is deciding is going to abort its simulation, then the P it is
simulting also has a H in it that will abort its simulation, and thus
NOT generate the infinite pattern you claim.