• Re: olcott, it's really simple

    From olcott@21:1/5 to Mr Flibble on Thu Jun 16 12:40:19 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/16/2022 12:17 PM, Mr Flibble wrote:
    Given olcott's code,

    #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));
    }

    and olcott's assertion that H is a pure function and H(P,P) == 0,
    then, P should halt as H should also return 0 to P (pure functions
    ALWAYS return the same result for the same arguments with no side
    effects). P doesn't halt so H is erroneous; olcott, it's really that
    simple.

    /Flibble


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

    Any competent software engineer will see that the correct and complete
    x86 emulation of the input to H(P,P) will never reach its "ret"
    instruction (the final state of P).

    When H(P,P) aborts the x86 emulation of its input on this basis and
    returns 0 to main competent software engineers will know that this does
    not cause P to reach its "ret" instruction.

    computation that halts … the Turing machine will halt whenever it enters
    a final state. (Linz:1990:234)

    Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)

    --
    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 Mr Flibble on Thu Jun 16 13:07:29 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/16/2022 1:02 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 12:40:19 -0500
    olcott <NoOne@NoWhere.com> wrote:

    It would be better if you actually addressed the content of people's
    posts. Your H is erroneous.

    /Flibble


    Competent software engineers will agree that
    the following proves that H(P,P)==0 is correct.

    #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 it remains stuck in repeated cycles of emulation.

    (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 Mr Flibble@21:1/5 to olcott on Thu Jun 16 19:02:13 2022
    XPost: comp.theory, sci.logic, sci.math

    On Thu, 16 Jun 2022 12:40:19 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 12:17 PM, Mr Flibble wrote:
    Given olcott's code,

    #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));
    }

    and olcott's assertion that H is a pure function and H(P,P) == 0,
    then, P should halt as H should also return 0 to P (pure functions
    ALWAYS return the same result for the same arguments with no side
    effects). P doesn't halt so H is erroneous; olcott, it's really that simple.

    /Flibble


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

    Any competent software engineer will see that the correct and
    complete x86 emulation of the input to H(P,P) will never reach its
    "ret" instruction (the final state of P).

    When H(P,P) aborts the x86 emulation of its input on this basis and
    returns 0 to main competent software engineers will know that this
    does not cause P to reach its "ret" instruction.

    computation that halts … the Turing machine will halt whenever it
    enters a final state. (Linz:1990:234)

    Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)

    It would be better if you actually addressed the content of people's
    posts. Your H is erroneous.

    /Flibble

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

    On Thu, 16 Jun 2022 13:07:29 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:02 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 12:40:19 -0500
    olcott <NoOne@NoWhere.com> wrote:

    It would be better if you actually addressed the content of people's
    posts. Your H is erroneous.

    /Flibble


    Competent software engineers will agree that
    the following proves that H(P,P)==0 is correct.

    #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 it remains stuck in repeated cycles of emulation.

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

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble

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

    On 6/16/2022 1:11 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:07:29 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:02 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 12:40:19 -0500
    olcott <NoOne@NoWhere.com> wrote:

    It would be better if you actually addressed the content of people's
    posts. Your H is erroneous.

    /Flibble


    Competent software engineers will agree that
    the following proves that H(P,P)==0 is correct.

    #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 it remains stuck in repeated cycles of emulation.

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

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    Competent software engineers would understand that H(P,P)==0 is correct
    and be unable to find any software engineering mistakes.

    It is an easily verified fact that the correct and complete x86
    emulation of the input to H(P,P) by H cannot possibly reach its "ret" instruction.

    Since this is the criterion measure for returning 0 then H(P,P)==0 has
    been proven to be correct on the basis of software engineering.

    --
    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 Thu Jun 16 19:22:37 2022
    XPost: comp.theory, sci.logic, sci.math

    On Thu, 16 Jun 2022 13:21:45 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:11 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:07:29 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:02 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 12:40:19 -0500
    olcott <NoOne@NoWhere.com> wrote:

    It would be better if you actually addressed the content of
    people's posts. Your H is erroneous.

    /Flibble


    Competent software engineers will agree that
    the following proves that H(P,P)==0 is correct.

    #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 it remains stuck in repeated cycles of
    emulation.

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

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    Competent software engineers would understand that H(P,P)==0 is
    correct and be unable to find any software engineering mistakes.

    It is an easily verified fact that the correct and complete x86
    emulation of the input to H(P,P) by H cannot possibly reach its "ret" instruction.

    Since this is the criterion measure for returning 0 then H(P,P)==0
    has been proven to be correct on the basis of software engineering.

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble

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

    On Thu, 16 Jun 2022 13:26:25 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:22 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:21:45 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:11 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:07:29 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:02 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 12:40:19 -0500
    olcott <NoOne@NoWhere.com> wrote:

    It would be better if you actually addressed the content of
    people's posts. Your H is erroneous.

    /Flibble


    Competent software engineers will agree that
    the following proves that H(P,P)==0 is correct.

    #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 it remains stuck in repeated cycles of
    emulation.

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

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    Competent software engineers would understand that H(P,P)==0 is
    correct and be unable to find any software engineering mistakes.

    It is an easily verified fact that the correct and complete x86
    emulation of the input to H(P,P) by H cannot possibly reach its
    "ret" instruction.

    Since this is the criterion measure for returning 0 then H(P,P)==0
    has been proven to be correct on the basis of software
    engineering.

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    People that are not competent software engineers and people that
    prefer rebuttal to truth will avoid addressing the above irrefutably
    correct reasoning.

    Your reasoning is incorrect. If H(P,P) == 0 then P should halt.

    /Flibble

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

    On 6/16/2022 1:22 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:21:45 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:11 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:07:29 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:02 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 12:40:19 -0500
    olcott <NoOne@NoWhere.com> wrote:

    It would be better if you actually addressed the content of
    people's posts. Your H is erroneous.

    /Flibble


    Competent software engineers will agree that
    the following proves that H(P,P)==0 is correct.

    #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 it remains stuck in repeated cycles of
    emulation.

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

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    Competent software engineers would understand that H(P,P)==0 is
    correct and be unable to find any software engineering mistakes.

    It is an easily verified fact that the correct and complete x86
    emulation of the input to H(P,P) by H cannot possibly reach its "ret"
    instruction.

    Since this is the criterion measure for returning 0 then H(P,P)==0
    has been proven to be correct on the basis of software engineering.

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    People that are not competent software engineers and people that prefer rebuttal to truth will avoid addressing the above irrefutably correct reasoning.

    --
    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 Thu Jun 16 19:32:59 2022
    XPost: comp.theory, sci.logic, sci.math

    On Thu, 16 Jun 2022 13:31:57 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:30 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:26:25 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:22 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:21:45 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:11 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:07:29 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:02 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 12:40:19 -0500
    olcott <NoOne@NoWhere.com> wrote:

    It would be better if you actually addressed the content of
    people's posts. Your H is erroneous.

    /Flibble


    Competent software engineers will agree that
    the following proves that H(P,P)==0 is correct.

    #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 it remains stuck in repeated
    cycles of emulation.

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

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    Competent software engineers would understand that H(P,P)==0 is
    correct and be unable to find any software engineering mistakes.

    It is an easily verified fact that the correct and complete x86
    emulation of the input to H(P,P) by H cannot possibly reach its
    "ret" instruction.

    Since this is the criterion measure for returning 0 then
    H(P,P)==0 has been proven to be correct on the basis of software
    engineering.

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    People that are not competent software engineers and people that
    prefer rebuttal to truth will avoid addressing the above
    irrefutably correct reasoning.

    Your reasoning is incorrect. If H(P,P) == 0 then P should halt.

    /Flibble


    Which one of these are you:

    People that are not competent software engineers and people that
    prefer rebuttal to truth will avoid addressing the above irrefutably
    correct reasoning.

    Your reasoning is incorrect. If H(P,P) == 0 then P should halt.

    /Flibble

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

    On 6/16/2022 1:30 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:26:25 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:22 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:21:45 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:11 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:07:29 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:02 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 12:40:19 -0500
    olcott <NoOne@NoWhere.com> wrote:

    It would be better if you actually addressed the content of
    people's posts. Your H is erroneous.

    /Flibble


    Competent software engineers will agree that
    the following proves that H(P,P)==0 is correct.

    #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 it remains stuck in repeated cycles of
    emulation.

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

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    Competent software engineers would understand that H(P,P)==0 is
    correct and be unable to find any software engineering mistakes.

    It is an easily verified fact that the correct and complete x86
    emulation of the input to H(P,P) by H cannot possibly reach its
    "ret" instruction.

    Since this is the criterion measure for returning 0 then H(P,P)==0
    has been proven to be correct on the basis of software
    engineering.

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    People that are not competent software engineers and people that
    prefer rebuttal to truth will avoid addressing the above irrefutably
    correct reasoning.

    Your reasoning is incorrect. If H(P,P) == 0 then P should halt.

    /Flibble


    Which one of these are you:

    People that are not competent software engineers and people that
    prefer rebuttal to truth will avoid addressing the above irrefutably
    correct reasoning.


    --
    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 Mr Flibble on Thu Jun 16 13:45:07 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/16/2022 1:32 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:31:57 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:30 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:26:25 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:22 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:21:45 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:11 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:07:29 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:02 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 12:40:19 -0500
    olcott <NoOne@NoWhere.com> wrote:

    It would be better if you actually addressed the content of
    people's posts. Your H is erroneous.

    /Flibble


    Competent software engineers will agree that
    the following proves that H(P,P)==0 is correct.

    #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 it remains stuck in repeated
    cycles of emulation.

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

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    Competent software engineers would understand that H(P,P)==0 is
    correct and be unable to find any software engineering mistakes.

    It is an easily verified fact that the correct and complete x86
    emulation of the input to H(P,P) by H cannot possibly reach its
    "ret" instruction.

    Since this is the criterion measure for returning 0 then
    H(P,P)==0 has been proven to be correct on the basis of software
    engineering.

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    People that are not competent software engineers and people that
    prefer rebuttal to truth will avoid addressing the above
    irrefutably correct reasoning.

    Your reasoning is incorrect. If H(P,P) == 0 then P should halt.

    /Flibble


    Which one of these are you:

    People that are not competent software engineers and people that
    prefer rebuttal to truth will avoid addressing the above irrefutably
    correct reasoning.

    Your reasoning is incorrect. If H(P,P) == 0 then P should halt.

    /Flibble


    Since my reasoning is trivially proven to be correct:

    It is an easily verified fact that the correct and complete x86
    emulation of the input to H(P,P) by H cannot possibly reach its
    "ret" instruction.

    H returns 0 whenever the complete and correct x86 emulation of its input
    would never reach the "ret" instruction of this input.

    Every possible rebuttal is simultaneously proven to be incorrect.

    --
    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 Thu Jun 16 19:49:35 2022
    XPost: comp.theory, sci.logic, sci.math

    On Thu, 16 Jun 2022 13:45:07 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:32 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:31:57 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:30 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:26:25 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:22 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:21:45 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:11 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:07:29 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:02 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 12:40:19 -0500
    olcott <NoOne@NoWhere.com> wrote:

    It would be better if you actually addressed the content of >>>>>>>>> people's posts. Your H is erroneous.

    /Flibble


    Competent software engineers will agree that
    the following proves that H(P,P)==0 is correct.

    #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 it remains stuck in repeated
    cycles of emulation.

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

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    Competent software engineers would understand that H(P,P)==0 is
    correct and be unable to find any software engineering
    mistakes.

    It is an easily verified fact that the correct and complete x86
    emulation of the input to H(P,P) by H cannot possibly reach its
    "ret" instruction.

    Since this is the criterion measure for returning 0 then
    H(P,P)==0 has been proven to be correct on the basis of
    software engineering.

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    People that are not competent software engineers and people that
    prefer rebuttal to truth will avoid addressing the above
    irrefutably correct reasoning.

    Your reasoning is incorrect. If H(P,P) == 0 then P should halt.

    /Flibble


    Which one of these are you:

    People that are not competent software engineers and people that
    prefer rebuttal to truth will avoid addressing the above
    irrefutably correct reasoning.

    Your reasoning is incorrect. If H(P,P) == 0 then P should halt.

    /Flibble


    Since my reasoning is trivially proven to be correct:

    It is an easily verified fact that the correct and complete x86
    emulation of the input to H(P,P) by H cannot possibly reach its
    "ret" instruction.

    H returns 0 whenever the complete and correct x86 emulation of its
    input would never reach the "ret" instruction of this input.

    Every possible rebuttal is simultaneously proven to be incorrect.

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble

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

    On 6/16/2022 1:49 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:45:07 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:32 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:31:57 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:30 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:26:25 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:22 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:21:45 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:11 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 13:07:29 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/16/2022 1:02 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 12:40:19 -0500
    olcott <NoOne@NoWhere.com> wrote:

    It would be better if you actually addressed the content of >>>>>>>>>>> people's posts. Your H is erroneous.

    /Flibble


    Competent software engineers will agree that
    the following proves that H(P,P)==0 is correct.

    #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 it remains stuck in repeated >>>>>>>>>> cycles of emulation.

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

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    Competent software engineers would understand that H(P,P)==0 is >>>>>>>> correct and be unable to find any software engineering
    mistakes.

    It is an easily verified fact that the correct and complete x86 >>>>>>>> emulation of the input to H(P,P) by H cannot possibly reach its >>>>>>>> "ret" instruction.

    Since this is the criterion measure for returning 0 then
    H(P,P)==0 has been proven to be correct on the basis of
    software engineering.

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble


    People that are not competent software engineers and people that
    prefer rebuttal to truth will avoid addressing the above
    irrefutably correct reasoning.

    Your reasoning is incorrect. If H(P,P) == 0 then P should halt.

    /Flibble


    Which one of these are you:

    People that are not competent software engineers and people that
    prefer rebuttal to truth will avoid addressing the above
    irrefutably correct reasoning.

    Your reasoning is incorrect. If H(P,P) == 0 then P should halt.

    /Flibble


    Since my reasoning is trivially proven to be correct:

    It is an easily verified fact that the correct and complete x86
    emulation of the input to H(P,P) by H cannot possibly reach its
    "ret" instruction.

    H returns 0 whenever the complete and correct x86 emulation of its
    input would never reach the "ret" instruction of this input.

    Every possible rebuttal is simultaneously proven to be incorrect.

    Nope. If H(P,P) == 0 then P should halt.

    /Flibble



    (X) It is an easily verified fact that the correct and complete x86
    emulation of the input to H(P,P) by H cannot possibly reach its "ret" instruction.

    (Y) H returns 0 whenever the correct and complete x86 emulation of its
    input would never reach the "ret" instruction of this input.

    (Z) H(P,P)==0 is correct

    When (X & Y) proves Z and we know X & Y then Z is proved.

    Even you can understand that there is no escape from this last line.
    Failing to acknowledge the correctness of this last line is sufficient
    evidence of dishonesty.


    --
    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 Ben Bacarisse on Thu Jun 16 14:27:21 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/16/2022 2:15 PM, Ben Bacarisse wrote:
    Mr Flibble <flibble@reddwarf.jmc> writes:

    Given olcott's code,

    #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));
    }

    and olcott's assertion that H is a pure function and H(P,P) == 0,
    then, P should halt as H should also return 0 to P

    You mean P(P) should halt, and it does. PO does not dispute this fact.
    Not only has he posted a trace of P(P) halting, he has clearly stated
    that H(P,P) == 0 "is the correct answer even though P(P) halts".[1]

    (pure functions
    ALWAYS return the same result for the same arguments with no side
    effects). P doesn't halt so H is erroneous; olcott, it's really that
    simple.

    Except that he is now just asserting that H(P,P) == 0 is correct about something else (the "correct simulation of the input to H(P,P)") and the mistakes in that irrelevant statement are keeping him supplied with the attention he craves. You might consider not giving him what he wants.

    [1] Message-ID: <c8idnbFAF6C8QuP8nZ2dnUU7-avNnZ2d@giganews.com>


    When a simulating halt decider rejects all inputs as non-halting
    whenever it correctly detects that its correct and complete simulation
    of its input would never reach the final state of this input that all
    inputs (including pathological inputs) are decided correctly.

    *computation that halts* … the Turing machine will halt whenever it
    enters a final state. (Linz:1990:234)

    Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)



    --
    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 21:58:16 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/16/22 1:40 PM, olcott wrote:
    On 6/16/2022 12:17 PM, Mr Flibble wrote:
    Given olcott's code,

    #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));
    }

    and olcott's assertion that H is a pure function and H(P,P) == 0,
    then, P should halt as H should also return 0 to P (pure functions
    ALWAYS return the same result for the same arguments with no side
    effects). P doesn't halt so H is erroneous; olcott, it's really that
    simple.

    /Flibble


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

    Any competent software engineer will see that the correct and complete
    x86 emulation of the input to H(P,P) will never reach its "ret"
    instruction (the final state of P).

    So, does H do a compete and correct emulation, or does it abort its
    simulation to give an answer?

    The fact that you seem to claim that when H is called by main, it aborts
    and returns an answer, but when H is called by the simulated P it
    doesn't, just proves that H isn't the pure function you claim, or H's
    emulaiton isn't correct.


    When H(P,P) aborts the x86 emulation of its input on this basis and
    returns 0 to main competent software engineers will know that this does
    not cause P to reach its "ret" instruction.

    You mean that not all calls of H(P,P) do the same thing? Then H isn't
    the pure function you claim.


    computation that halts … the Turing machine will halt whenever it enters
    a final state. (Linz:1990:234)

    Right, we look at the TURING MACHINE, that is the actual function P (not
    H;s emulation of it) and that seems to Halt becahse H should return the
    value 0 to it.


    Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)


    So, which statement of yours is the LIE?

    Is H not actually a pure function, or

    Does H not accurately emulate its input, or

    Is P not actualy built as required?

    One of these has to be wrong.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Jun 16 22:03:11 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/16/22 2:07 PM, olcott wrote:
    On 6/16/2022 1:02 PM, Mr Flibble wrote:
    On Thu, 16 Jun 2022 12:40:19 -0500
    olcott <NoOne@NoWhere.com> wrote:

    It would be better if you actually addressed the content of people's
    posts.  Your H is erroneous.

    /Flibble


    Competent software engineers will agree that
    the following proves that H(P,P)==0 is correct.

    #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 it remains stuck in repeated cycles of emulation.

    This ONLY applies if H is actually the pure emulator that you talk about.


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

    Yes, buyt ONLY if H is that pure emulator that NEVER aborts is emulation.


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


    Except that to reject the input, your H has not NOT be that pure
    emulation, thus if H acts as in (3), then it can't use the logic of (1)
    or (2), since those both were based on the stipulation that H did a
    complete and correct emulation and NEVER aborted.

    FALSE PREMISE, UNSOUND logic.

    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.

    Nope. You have been told this many times, so your continued repeating of
    it just shows either ignorance or just being a pathological liar.


    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.


    Right, because it CAN'T.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Jun 16 22:08:23 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/16/22 3:27 PM, olcott wrote:
    On 6/16/2022 2:15 PM, Ben Bacarisse wrote:
    Mr Flibble <flibble@reddwarf.jmc> writes:

    Given olcott's code,

    #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));
    }

    and olcott's assertion that H is a pure function and H(P,P) == 0,
    then, P should halt as H should also return 0 to P

    You mean P(P) should halt, and it does.  PO does not dispute this fact.
    Not only has he posted a trace of P(P) halting, he has clearly stated
    that H(P,P) == 0 "is the correct answer even though P(P) halts".[1]

    (pure functions
    ALWAYS return the same result for the same arguments with no side
    effects). P doesn't halt so H is erroneous; olcott, it's really that
    simple.

    Except that he is now just asserting that H(P,P) == 0 is correct about
    something else (the "correct simulation of the input to H(P,P)") and the
    mistakes in that irrelevant statement are keeping him supplied with the
    attention he craves.  You might consider not giving him what he wants.

    [1] Message-ID: <c8idnbFAF6C8QuP8nZ2dnUU7-avNnZ2d@giganews.com>


    When a simulating halt decider rejects all inputs as non-halting
    whenever it correctly detects that its correct and complete simulation
    of its input would never reach the final state of this input that all
    inputs (including pathological inputs) are decided correctly.

    *computation that halts* … the Turing machine will halt whenever it
    enters a final state. (Linz:1990:234)

    Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)




    It needs to be CORRECT in its detection, and it isn't if "its" correct
    and complete simulation of its input would never reach the final state
    unless it actually DOES that.

    If H DOES a complete emulation of its input P, then it never answers and
    fails.

    If H DOES abort its emulation, it doesn't actually do a complete and
    correct emulation, so your definition isn't applicable, and when we look
    at the ACTUAL complete and correct emulation, we see it halts, so H was
    wrong.

    Note, you quoteing Linz on a computation that Halts actually shows that
    your criterion is incorrect, as it never references a "simultion" or "emulation" of the machine, but the machine it self, thus, since even
    you agree that P(P) will halt if H(P,P) returns 0, Linz definition says
    P(P) is a Halting computaiton in that case, so H(P,P) returning 0 is
    incorrect for something actually claiming to be a Halting Decider.

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