• Re: Olcott's H

    From olcott@21:1/5 to Mr Flibble on Fri Jun 17 14:06:55 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/17/2022 1:37 PM, Mr Flibble wrote:
    Hi!

    Olcott claims that H is a pure function which somehow detects and
    prevents a second call to H however it does this through emulation so I
    am thinking that the second call would, if not prevented, be
    not to H but instead to an emulated and therefore different H?


    The exact same machine code at the exact same machine address yet a
    different process instance. None of these details actually matter
    because no matter what terms we use to describe it P is doing something
    that prevents it from reaching its "ret" instruction.

    This kind of goes back to my original category error hypothesis which
    would now morph into a category error whose categories are the emulator
    and the emulated.

    Am I barking up the wrong tree?

    Also, I am not convinced that merely being able to detect infinite
    recursion due to H masquerading as an impossible simulating halt
    decider is sufficient to refute proofs based on the [Strachey, 1965] impossible program.

    /Flibble



    --
    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 Mr Flibble@21:1/5 to olcott on Fri Jun 17 20:11:45 2022
    XPost: comp.theory, sci.logic, sci.math

    On Fri, 17 Jun 2022 14:06:55 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/17/2022 1:37 PM, Mr Flibble wrote:
    Hi!

    Olcott claims that H is a pure function which somehow detects and
    prevents a second call to H however it does this through emulation
    so I am thinking that the second call would, if not prevented, be
    not to H but instead to an emulated and therefore different H?


    The exact same machine code at the exact same machine address yet a
    different process instance. None of these details actually matter
    because no matter what terms we use to describe it P is doing
    something that prevents it from reaching its "ret" instruction.

    The only thing preventing P doing what it should do is your simulator.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Mr Flibble on Fri Jun 17 14:21:05 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/17/2022 2:11 PM, Mr Flibble wrote:
    On Fri, 17 Jun 2022 14:06:55 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/17/2022 1:37 PM, Mr Flibble wrote:
    Hi!

    Olcott claims that H is a pure function which somehow detects and
    prevents a second call to H however it does this through emulation
    so I am thinking that the second call would, if not prevented, be
    not to H but instead to an emulated and therefore different H?


    The exact same machine code at the exact same machine address yet a
    different process instance. None of these details actually matter
    because no matter what terms we use to describe it P is doing
    something that prevents it from reaching its "ret" instruction.

    The only thing preventing P doing what it should do is your simulator.

    /Flibble


    #include <stdint.h>
    typedef void (*ptr)();

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

    int main()
    {
    Output("Input_Halts = ", 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]

    Every competent software engineer (thus perhaps not you) can very easily
    see that the correct and complete x86 emulation of the input to H(P,P)
    would never reach its "ret" instruction.

    --
    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 Richard Damon@21:1/5 to olcott on Fri Jun 17 20:45:56 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/17/22 3:21 PM, olcott wrote:
    On 6/17/2022 2:11 PM, Mr Flibble wrote:
    On Fri, 17 Jun 2022 14:06:55 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/17/2022 1:37 PM, Mr Flibble wrote:
    Hi!

    Olcott claims that H is a pure function which somehow detects and
    prevents a second call to H however it does this through emulation
    so I am thinking that the second call would, if not prevented, be
    not to H but instead to an emulated and therefore different H?

    The exact same machine code at the exact same machine address yet a
    different process instance. None of these details actually matter
    because no matter what terms we use to describe it P is doing
    something that prevents it from reaching its "ret" instruction.

    The only thing preventing P doing what it should do is your simulator.

    /Flibble


    #include <stdint.h>
    typedef void (*ptr)();

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

    int main()
    {
      Output("Input_Halts = ", 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]

    Every competent software engineer (thus perhaps not you) can very easily
    see that the correct and complete x86 emulation of the input to H(P,P)
    would never reach its "ret" instruction.


    No, if you point out that H(P,P) is known to return 0, then the obvious
    answer is that P(P) will reach the ret instruction.

    Only by LYING that H does an actual correct and complete emulation, when
    it actually doesn't, do you get your results.

    Which H are you defining your H to be.

    The one that does a correct and complete emulation and thus never
    answers H(P,P), or

    The one that does abort its emulation to return 0 from H(P,P) and thus
    creates a P(P) that returns?

    It can't be both.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Jun 17 20:42:51 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/17/22 3:06 PM, olcott wrote:
    On 6/17/2022 1:37 PM, Mr Flibble wrote:
    Hi!

    Olcott claims that H is a pure function which somehow detects and
    prevents a second call to H however it does this through emulation so I
    am thinking that the second call would, if not prevented, be
    not to H but instead to an emulated and therefore different H?


    The exact same machine code at the exact same machine address yet a
    different process instance. None of these details actually matter
    because no matter what terms we use to describe it P is doing something
    that prevents it from reaching its "ret" instruction.

    And thus needs to behave exactly the same, so since H(P,P) directly
    called by main returns 0, so must the emulated H(P,P) called by the
    emulated (P).

    If you want to show that it can behave differerently, what is the first
    x86 assembly instruction for the emulated H(P,P) that generates
    different results from the directly executed H(P,P).

    Until you can provide that information, you claim of the "impossible"
    behavior is just an obvious lie.

    That, or H just doesn't do a correct emulation of its input program,
    which includes not only the x86 instructions of the subroutine P itself,
    but everything that P calls.

    Until you show proof of your claims of impossible behavior, the only
    actual conclusion we can make is that you are either lying or are mistaken.


    This kind of goes back to my original category error hypothesis which
    would now morph into a category error whose categories are the emulator
    and the emulated.

    Am I barking up the wrong tree?

    Also, I am not convinced that merely being able to detect infinite
    recursion due to H masquerading as an impossible simulating halt
    decider is sufficient to refute proofs based on the [Strachey, 1965]
    impossible program.

    /Flibble




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