• As easy as 1,2,3 H(P,P)==0 is proved to be correct

    From olcott@21:1/5 to Malcolm McLean on Thu Jun 16 08:47:29 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/14/2022 5:03 AM, Malcolm McLean wrote:
    On Tuesday, 14 June 2022 at 06:04:37 UTC+1, olcott wrote:
    On 6/13/2022 11:59 PM, André G. Isaak wrote:
    On 2022-06-13 21:50, olcott wrote:
    On 6/13/2022 10:46 PM, André G. Isaak wrote:
    On 2022-06-13 11:51, olcott wrote:
    On 6/13/2022 11:13 AM, Mr Flibble wrote:
    On Mon, 13 Jun 2022 09:27:08 -0500
    olcott <No...@NoWhere.com> wrote:

    I have updated the algorithm so that it is a pure function of its >>>>>>>> inputs. As soon as P calls H for the first time, H (knowing its own >>>>>>>> machine address) is able to look though the prior execution trace and >>>>>>>> see that P is calling H with the same arguments that it was called >>>>>>>> with and there are no instructions in P that would break this cycle. >>>>>>> Naive.

    /Flibble


    The last paragraph has been extensively reviewed and validated on
    another forum, thus saying that it is simply Naive carries zero weight. >>>>>
    And which forum would that be?

    André



    That is irrelevant.

    It's certainly relevant to anyone interested in reading those reviews.

    André


    I do appreciate that you are reviewing my work.
    So you don't feel technically qualified to assess the merits of this
    directly yourself? The impossibility of finding a valid counter-example
    disproving the claim counts as proof that the claim is true.

    We're dealing with our hands tied behind our backs, because we can't see H.
    I and other people have suggested an explanation for the results that you
    are seeing. But it can only be a shrewd guess. The behaviour of the program depends on how the emulator H is written. If it is in fact an emulator - some posters have disputed that. I doubt that they are right and that H is, as you describe it, an emulator. But it's impossible to actually prove these people wrong.

    #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]

    (1) It is an easily verified fact that when we assume that H is only an
    x86 emulator that the correctly emulated P never reaches its "ret"
    instruction.

    (2) It is an easily verified fact that if H has been adapted to
    correctly detect (in a finite number of steps) that the correct and
    complete x86 emulation of its input would never each its "ret"
    instruction that H could abort its emulation and return 0 to report this.

    (3) When the halt status criteria is defined as correctly determining
    whether or not an x86 emulated input would ever reach its "ret"
    instruction then it becomes an easily verified fact H(P,P) could
    correctly reject its input as non-halting.

    Correct deductive inference proves that all of these things are true
    without any need what-so-ever to see either the source-code or the
    execution trace of H.

    The one thing that is not proved is whether or not an actual encoded
    H(P,P) does indeed correctly determine that its input would never reach
    its "ret" instruction as a pure function of its inputs.


    --
    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 Thu Jun 16 18:47:23 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/16/22 9:47 AM, olcott wrote:
    On 6/14/2022 5:03 AM, Malcolm McLean wrote:
    On Tuesday, 14 June 2022 at 06:04:37 UTC+1, olcott wrote:
    On 6/13/2022 11:59 PM, André G. Isaak wrote:
    On 2022-06-13 21:50, olcott wrote:
    On 6/13/2022 10:46 PM, André G. Isaak wrote:
    On 2022-06-13 11:51, olcott wrote:
    On 6/13/2022 11:13 AM, Mr Flibble wrote:
    On Mon, 13 Jun 2022 09:27:08 -0500
    olcott <No...@NoWhere.com> wrote:

    I have updated the algorithm so that it is a pure function of its >>>>>>>>> inputs. As soon as P calls H for the first time, H (knowing its >>>>>>>>> own
    machine address) is able to look though the prior execution
    trace and
    see that P is calling H with the same arguments that it was called >>>>>>>>> with and there are no instructions in P that would break this >>>>>>>>> cycle.
    Naive.

    /Flibble


    The last paragraph has been extensively reviewed and validated on >>>>>>> another forum, thus saying that it is simply Naive carries zero
    weight.

    And which forum would that be?

    André



    That is irrelevant.

    It's certainly relevant to anyone interested in reading those reviews. >>>>
    André


    I do appreciate that you are reviewing my work.
    So you don't feel technically qualified to assess the merits of this
    directly yourself? The impossibility of finding a valid counter-example
    disproving the claim counts as proof that the claim is true.

    We're dealing with our hands tied behind our backs, because we can't
    see H.
    I and other people have suggested an explanation for the results that you
    are seeing. But it can only be a shrewd guess. The behaviour of the
    program
    depends on how the emulator H is written. If it is in fact an emulator
    - some
    posters have disputed that. I doubt that they are right and that H is,
    as you
    describe it, an emulator. But it's impossible to actually prove these
    people
    wrong.

    #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]

    (1) It is an easily verified fact that when we assume that H is only an
    x86 emulator that the correctly emulated P never reaches its "ret" instruction.

    (2) It is an easily verified fact that if H has been adapted to
    correctly detect (in a finite number of steps) that the correct and
    complete x86 emulation of its input would never each its "ret"
    instruction that H could abort its emulation and return 0 to report this.

    And since H is now not the pure x86 emulator, the information from (1)
    no longer holds.


    (3) When the halt status criteria is defined as correctly determining
    whether or not an x86 emulated input would ever reach its "ret"
    instruction then it becomes an easily verified fact H(P,P) could
    correctly reject its input as non-halting.


    Such a pattern has been proved to not exist in H's trace of P(P).

    Correct deductive inference proves that all of these things are true
    without any need what-so-ever to see either the source-code or the
    execution trace of H.

    The one thing that is not proved is whether or not an actual encoded
    H(P,P) does indeed correctly determine that its input would never reach
    its "ret" instruction as a pure function of its inputs.



    So, you have nothing.

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