• All my reviewers expect a halt decider to have psychic power

    From olcott@21:1/5 to All on Sat Apr 23 09:49:51 2022
    XPost: comp.theory, sci.logic, sci.math

    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).

    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.

    Since my reviewers expect the halt decider to compute the halt status of
    P(P) yet the input to H(P,P) specifies a different halt status my
    reviewers expect H to read their mind so that it can compute different
    behavior than the behavior that the input actually specifies.



    The function named H continues to simulate its input using an x86
    emulator until this input either halts on its own or H detects that it
    would never halt. If its input halts H returns 1. If H detects that its
    input would never halt H returns 0.

    #include <stdint.h>
    #define u32 uint32_t

    void P(u32 x)
    {
    if (H(x, x))
    HERE: goto HERE;
    return;
    }

    int main()
    {
    Output("Input_Halts = ", H((u32)P, (u32)P));
    }

    _P()
    [000009d6](01) 55 push ebp
    [000009d7](02) 8bec mov ebp,esp
    [000009d9](03) 8b4508 mov eax,[ebp+08]
    [000009dc](01) 50 push eax // push P
    [000009dd](03) 8b4d08 mov ecx,[ebp+08]
    [000009e0](01) 51 push ecx // push P
    [000009e1](05) e840feffff call 00000826 // call H
    [000009e6](03) 83c408 add esp,+08
    [000009e9](02) 85c0 test eax,eax
    [000009eb](02) 7402 jz 000009ef
    [000009ed](02) ebfe jmp 000009ed
    [000009ef](01) 5d pop ebp
    [000009f0](01) c3 ret // Final state
    Size in bytes:(0027) [000009f0]

    The simulated input to H(P,P) cannot possibly reach its own final state
    of [000009f0] it keeps repeating [000009d6] to [000009e1] until aborted.

    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

    Because the correctly simulated input to H(P,P) cannot possibly reach
    its own final state at [000009f0] it is necessarily correct for H to
    reject this input as non-halting.

    The correctly simulated 27 bytes of machine code at [000009d6] would
    never reach its own final state at [000009f0] when correctly simulated
    by the simulating halt decider (SHD) at machine address [00000826].




    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to wij on Sat Apr 23 11:34:47 2022
    XPost: comp.theory, sci.math, sci.logic

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to wij on Sat Apr 23 11:51:52 2022
    XPost: comp.theory, sci.logic, sci.math

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to wij on Sat May 7 16:50:35 2022
    XPost: comp.theory, sci.logic, comp.lang.prolog

    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.

    My H proves that H(P,P)== false
    on the basis that H does correctly compute the mapping from its input parameters to its own final reject state on the basis of the actual
    behavior actually specified by its input parameters.

    The details of this are shown here: https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

    A bunch of goofy people here do not understand that this meets the
    definition of a correct halt decider.

    They believe that H must compute a mapping from non-inputs. This is
    quite nuts because they already know that no decider can ever do this.



    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)