• Re: Experts would agree that my reviewers are incorrect [ H(P,P)==0 ]

    From olcott@21:1/5 to Dennis Bush on Sat May 28 10:48:33 2022
    XPost: comp.theory, sci.logic, sci.math

    On 5/28/2022 10:23 AM, Dennis Bush wrote:
    On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:
    On 5/28/2022 8:58 AM, Richard Damon wrote:

    On 5/28/22 6:26 AM, olcott wrote:
    On 5/27/2022 7:33 PM, Richard Damon wrote:
    On 5/27/22 7:33 PM, olcott wrote:
    On 5/27/2022 6:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:42, olcott wrote:
    On 5/27/2022 5:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:13, olcott wrote:
    On 5/27/2022 4:41 PM, André G. Isaak wrote:
    On 2022-05-27 15:31, olcott wrote:
    On 5/27/2022 4:21 PM, André G. Isaak wrote:
    On 2022-05-27 14:38, olcott wrote:
    On 5/27/2022 3:06 PM, André G. Isaak wrote:
    On 2022-05-27 13:41, olcott wrote:
    On 5/27/2022 2:10 PM, André G. Isaak wrote:
    On 2022-05-27 13:01, olcott wrote:
    On 5/27/2022 1:57 PM, Richard Damon wrote:

    The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>
    The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>> configurations that may or may not reach their own final >>>>>>>>>>>>>>>>>> state.

    I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' >>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are not. >>>>>>>>>>>>>>>>>

    The distinction that I make between represent and specify >>>>>>>>>>>>>>>> is that the x86 source-code for P represents P(P) whereas >>>>>>>>>>>>>>>> the actual correct x86 emulation of the input to H(P,P) >>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not >>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P). >>>>>>>>>>>>>>>>
    A sequence of configurations means a list of x86 program >>>>>>>>>>>>>>>> steps executed or emulated in the order that their >>>>>>>>>>>>>>>> source-code specifies.

    Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>
    And this decidedly is *not* what a halt decider is given as >>>>>>>>>>>>>>> its input. It is not given a sequence of state transitions. >>>>>>>>>>>>>>> It is given a representation of a computation.


    No it is not and you know that it is not. A halt decider is >>>>>>>>>>>>>> given a finite string TM description that specifies a >>>>>>>>>>>>>> sequence of configurations.

    A TM description and a sequence of configurations are >>>>>>>>>>>>> entirely different things (and the former certainly does not >>>>>>>>>>>>> 'specify' the latter). It's given either one or the other. >>>>>>>>>>>>> Make up your mind.

    André


    _Infinite_Loop()
    [000012c2](01) 55 push ebp
    [000012c3](02) 8bec mov ebp,esp
    [000012c5](02) ebfe jmp 000012c5
    [000012c7](01) 5d pop ebp
    [000012c8](01) c3 ret
    Size in bytes:(0007) [000012c8]

    So then the above x86 code may specify a game of tic-tac-toe >>>>>>>>>>>> and there is no possible way to determine that it does not >>>>>>>>>>>> because the x86 source code of a function has nothing to do >>>>>>>>>>>> with the sequence of steps of its correct simulation.


    That is not a sequence of configurations. It is a piece of >>>>>>>>>>> assembly code which represents a subroutine which is an
    infinite loop. The sequence of configurations would look >>>>>>>>>>> something like this:


    Yes that code specifies this sequence.

    No, it does not. What you have above only generates the following >>>>>>>>> *only* if you (a) interpret it as representing x86 instructions >>>>>>>>> and (b) actually execute it on an x86 or some appropriate emulator. >>>>>>>>>

    Because no one in their right mind would think of doing it
    otherwise those ridiculously self-evident facts need not be stated. >>>>>>>
    You are the one who constantly makes much ado about nothing about >>>>>>> the fact that Turing Machines can ONLY accept finite strings as
    their inputs and object to anyone who suggests that something might >>>>>>> compute some function which isn't over strings.

    You don't seem to understand exactly what a finite string is. A
    finite string is simply a sequence of symbols. Given two strings, >>>>>>> you can ask questions like which is longer or whether one is a
    substring or permutation of the other, but not much else.

    That's because neither strings nor the symbols they are composed of >>>>>>> have any meaning whatsoever. They are just sequences of
    uninterpreted tokens. As soon as you start talking about 'sequences >>>>>>> of configurations' or 'numerical values' or anything along those >>>>>>> lines you are no longer talking about finite strings, but about the >>>>>>> entities which those strings represent to a particular TM/program. >>>>>>>
    Part of designing a TM involves specifying exactly how a string is >>>>>>> to be interpreted (however 'ridiculously self-evident' it might
    seem to you) So yes, they need to be stated.


    If it was not for communication context then every single rule of >>>>>>>> grammar would have to be repeated with every sentence and every >>>>>>>> definition of every work would have to be repeated over and over. >>>>>>>>
    You keep claiming that the input to the decider is a sequence of >>>>>>>>> configurations, but that's just plain wrong.

    The input to a decider

    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    A sequence of configirations

    Did you notice that I said SPECFIES this time ???

    But you still haven't provided a coherent definition of what *you* >>>>>>> mean by 'specify'. You gave a bit of wishy-washy verbiage a few
    posts ago, but nothing which made this clear. Repeating it over and >>>>>>> over again doesn't add any clarity.

    The question originally arose when you objected to the claim that >>>>>>> the input to a halt decider represents a computation (or TM
    description/input string pair) and instead insisted that it
    specifies a sequence of configurations.


    Yes of course as everyone knows x86 source-code is one of the
    ingredients to a milkshake and because there is a standard practice >>>>>> for making milkshakes they already know when and how the x86
    source-code must be applied to make a milkshake.

    Now it seems like you are trying to claim that a representation of >>>>>>> a computation specifies a sequence of configurations, but that
    doesn't explain why you so vehemently objected

    Your brain is welded in rebuttal mode?

    to the claim that the input to a halt decider represents a
    computation. So clearly you mean something else altogether.

    André


    Because your brain is welded in rebuttal mode you will always act
    like you never know.


    No, YOUR brain is welded in stupid mode. You are unable to make a
    clear sentence because you misuse the English language to hide your
    lies.

    It is easily provable that the C function H(P,P)==0 is correct on the
    basis of the fact correct execution trace of the x86 source-code of
    input to H(P,P) shows that P would never reach its "ret" instruction.

    Again, I say HOW, since the CORRECT emulation of the input to H(P,P), as >>> shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is
    defined to return 0 from H(P,P).
    Richard is one of the two liars.
    *The actual behavior of P when correctly emulated by H is shown below*

    #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()
    [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]

    _main()
    [00001372](01) 55 push ebp
    [00001373](02) 8bec mov ebp,esp
    [00001375](05) 6852130000 push 00001352 // push P
    [0000137a](05) 6852130000 push 00001352 // push P
    [0000137f](05) e81efeffff call 000011a2 // call H
    [00001384](03) 83c408 add esp,+08
    [00001387](01) 50 push eax
    [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
    [0000138d](05) e8e0f0ffff call 00000472 // call Output
    [00001392](03) 83c408 add esp,+08
    [00001395](02) 33c0 xor eax,eax
    [00001397](01) 5d pop ebp
    [00001398](01) c3 ret
    Size in bytes:(0039) [00001398]

    machine stack stack machine assembly
    address address data code language
    ======== ======== ======== ========= =============
    ...[00001372][0010229e][00000000] 55 push ebp
    ...[00001373][0010229e][00000000] 8bec mov ebp,esp
    ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
    ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
    ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

    Begin Local Halt Decider Simulation Execution Trace Stored at:212352

    // H emulates the first seven instructions of P
    ...[00001352][0021233e][00212342] 55 push ebp // enter P
    ...[00001353][0021233e][00212342] 8bec mov ebp,esp
    ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
    ...[00001358][0021233a][00001352] 50 push eax // push P
    ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
    ...[0000135c][00212336][00001352] 51 push ecx // push P
    ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

    Starting here is where the trace is incomplete. The emulation of the instructions of the inner instance of H are not shown. Also the lines below are not emulated by the top level H. They are emulated by the inner H called by P. So in between each
    of these lines is multiple instructions of the inner H performing the emulation of them.


    // The emulated H emulates the first seven instructions of P
    ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
    ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
    ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
    ...[00001358][0025cd62][00001352] 50 push eax // push P
    ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
    ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
    ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    Here is where H makes its error of aborting too soon. Explanation below:


    Several different confusions (see below).


    If the execution trace of function H() called by function P() shows:
    (1) Function H() is called twice in sequence from the same machine
    address of P().
    (2) With the same parameters to H().
    (3) With no conditional branch or indexed jump instructions in P().

    This condition is not met.

    (1) is proven
    (2) is proven // Third column shows TOS value of P's machine address
    (3) is proven //

    There are branches / jumps in the *program* P contained in the function H that can abort.

    We are not looking for jumps, we are looking for code that can change
    the behavior of P from one invocation to the next.
    (a) conditional branch or
    (b) indexed jump instructions (where the index can vary)

    The outer H is unable to detect that the inner H will do exactly what the outer H does,

    None of this could possibly show that the simulated P ever reaches its
    "ret" instruction, thus is irrelevant.

    We are not asking:
    [A] Does P stop running?

    We are asking:
    [B] Does the simulated P reach its "ret" instruction?

    The answer is no.

    Because the definition of halting means that a computation completed
    normally and reached is final instruction H would correctly abort its simulation of P and return 0.

    Halting problem undecidability and infinitely nested simulation (V5)

    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5


    namely abort its simulation and return 0. But the fixed algorithm of H (actually Ha) is unable to see that. H1 simulating this same input *is*
    able to see the H embedded in P abort and return 0, causing P to halt.

    (4) With no function call returns from H() to P().

    This does happen, but the fixed algorithm of H (again Ha) is unable to simulate to the point that this happens.

    then the function call from P() to H() is infinitely recursive.

    ...[00001384][0010229e][00000000] 83c408 add esp,+08
    ...[00001387][0010229a][00000000] 50 push eax
    ...[00001388][00102296][00000423] 6823040000 push 00000423 //
    "Input_Halts = "
    ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
    Input_Halts = 0
    ...[00001392][0010229e][00000000] 83c408 add esp,+08
    ...[00001395][0010229e][00000000] 33c0 xor eax,eax
    ...[00001397][001022a2][00100000] 5d pop ebp
    ...[00001398][001022a6][00000004] c3 ret
    Number_of_User_Instructions(1)
    Number of Instructions Executed(15892) = 237 pages
    --
    Copyright 2022 Pete Olcott

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


    --
    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 Sat May 28 12:08:49 2022
    XPost: comp.theory, sci.logic, sci.math

    On 5/28/22 11:48 AM, olcott wrote:
    On 5/28/2022 10:23 AM, Dennis Bush wrote:
    On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:
    On 5/28/2022 8:58 AM, Richard Damon wrote:

    On 5/28/22 6:26 AM, olcott wrote:
    On 5/27/2022 7:33 PM, Richard Damon wrote:
    On 5/27/22 7:33 PM, olcott wrote:
    On 5/27/2022 6:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:42, olcott wrote:
    On 5/27/2022 5:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:13, olcott wrote:
    On 5/27/2022 4:41 PM, André G. Isaak wrote:
    On 2022-05-27 15:31, olcott wrote:
    On 5/27/2022 4:21 PM, André G. Isaak wrote:
    On 2022-05-27 14:38, olcott wrote:
    On 5/27/2022 3:06 PM, André G. Isaak wrote:
    On 2022-05-27 13:41, olcott wrote:
    On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
    On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>
    The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>>
    The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own final >>>>>>>>>>>>>>>>>>> state.

    I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' >>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are >>>>>>>>>>>>>>>>>> not.


    The distinction that I make between represent and specify >>>>>>>>>>>>>>>>> is that the x86 source-code for P represents P(P) whereas >>>>>>>>>>>>>>>>> the actual correct x86 emulation of the input to H(P,P) >>>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not >>>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P). >>>>>>>>>>>>>>>>>
    A sequence of configurations means a list of x86 program >>>>>>>>>>>>>>>>> steps executed or emulated in the order that their >>>>>>>>>>>>>>>>> source-code specifies.

    Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>
    And this decidedly is *not* what a halt decider is given as >>>>>>>>>>>>>>>> its input. It is not given a sequence of state transitions. >>>>>>>>>>>>>>>> It is given a representation of a computation. >>>>>>>>>>>>>>>>

    No it is not and you know that it is not. A halt decider is >>>>>>>>>>>>>>> given a finite string TM description that specifies a >>>>>>>>>>>>>>> sequence of configurations.

    A TM description and a sequence of configurations are >>>>>>>>>>>>>> entirely different things (and the former certainly does not >>>>>>>>>>>>>> 'specify' the latter). It's given either one or the other. >>>>>>>>>>>>>> Make up your mind.

    André


    _Infinite_Loop()
    [000012c2](01)  55              push ebp >>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp >>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5 >>>>>>>>>>>>> [000012c7](01)  5d              pop ebp >>>>>>>>>>>>> [000012c8](01)  c3              ret
    Size in bytes:(0007) [000012c8]

    So then the above x86 code may specify a game of tic-tac-toe >>>>>>>>>>>>> and there is no possible way to determine that it does not >>>>>>>>>>>>> because the x86 source code of a function has nothing to do >>>>>>>>>>>>> with the sequence of steps of its correct simulation. >>>>>>>>>>>>

    That is not a sequence of configurations. It is a piece of >>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>> something like this:


    Yes that code specifies this sequence.

    No, it does not. What you have above only generates the following >>>>>>>>>> *only* if you (a) interpret it as representing x86 instructions >>>>>>>>>> and (b) actually execute it on an x86 or some appropriate
    emulator.


    Because no one in their right mind would think of doing it
    otherwise those ridiculously self-evident facts need not be
    stated.

    You are the one who constantly makes much ado about nothing about >>>>>>>> the fact that Turing Machines can ONLY accept finite strings as >>>>>>>> their inputs and object to anyone who suggests that something might >>>>>>>> compute some function which isn't over strings.

    You don't seem to understand exactly what a finite string is. A >>>>>>>> finite string is simply a sequence of symbols. Given two strings, >>>>>>>> you can ask questions like which is longer or whether one is a >>>>>>>> substring or permutation of the other, but not much else.

    That's because neither strings nor the symbols they are composed of >>>>>>>> have any meaning whatsoever. They are just sequences of
    uninterpreted tokens. As soon as you start talking about 'sequences >>>>>>>> of configurations' or 'numerical values' or anything along those >>>>>>>> lines you are no longer talking about finite strings, but about the >>>>>>>> entities which those strings represent to a particular TM/program. >>>>>>>>
    Part of designing a TM involves specifying exactly how a string is >>>>>>>> to be interpreted (however 'ridiculously self-evident' it might >>>>>>>> seem to you) So yes, they need to be stated.


    If it was not for communication context then every single rule of >>>>>>>>> grammar would have to be repeated with every sentence and every >>>>>>>>> definition of every work would have to be repeated over and over. >>>>>>>>>
    You keep claiming that the input to the decider is a sequence of >>>>>>>>>> configurations, but that's just plain wrong.

    The input to a decider

    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    A sequence of configirations

    Did you notice that I said SPECFIES this time ???

    But you still haven't provided a coherent definition of what *you* >>>>>>>> mean by 'specify'. You gave a bit of wishy-washy verbiage a few >>>>>>>> posts ago, but nothing which made this clear. Repeating it over and >>>>>>>> over again doesn't add any clarity.

    The question originally arose when you objected to the claim that >>>>>>>> the input to a halt decider represents a computation (or TM
    description/input string pair) and instead insisted that it
    specifies a sequence of configurations.


    Yes of course as everyone knows x86 source-code is one of the
    ingredients to a milkshake and because there is a standard practice >>>>>>> for making milkshakes they already know when and how the x86
    source-code must be applied to make a milkshake.

    Now it seems like you are trying to claim that a representation of >>>>>>>> a computation specifies a sequence of configurations, but that >>>>>>>> doesn't explain why you so vehemently objected

    Your brain is welded in rebuttal mode?

    to the claim that the input to a halt decider represents a
    computation. So clearly you mean something else altogether.

    André


    Because your brain is welded in rebuttal mode you will always act >>>>>>> like you never know.


    No, YOUR brain is welded in stupid mode. You are unable to make a
    clear sentence because you misuse the English language to hide your >>>>>> lies.

    It is easily provable that the C function H(P,P)==0 is correct on the >>>>> basis of the fact correct execution trace of the x86 source-code of
    input to H(P,P) shows that P would never reach its "ret" instruction. >>>>
    Again, I say HOW, since the CORRECT emulation of the input to
    H(P,P), as
    shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is
    defined to return 0 from H(P,P).
    Richard is one of the two liars.
    *The actual behavior of P when correctly emulated by H is shown below*

    #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()
    [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]

    _main()
    [00001372](01) 55 push ebp
    [00001373](02) 8bec mov ebp,esp
    [00001375](05) 6852130000 push 00001352 // push P
    [0000137a](05) 6852130000 push 00001352 // push P
    [0000137f](05) e81efeffff call 000011a2 // call H
    [00001384](03) 83c408 add esp,+08
    [00001387](01) 50 push eax
    [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
    [0000138d](05) e8e0f0ffff call 00000472 // call Output
    [00001392](03) 83c408 add esp,+08
    [00001395](02) 33c0 xor eax,eax
    [00001397](01) 5d pop ebp
    [00001398](01) c3 ret
    Size in bytes:(0039) [00001398]

    machine stack stack machine assembly
    address address data code language
    ======== ======== ======== ========= =============
    ...[00001372][0010229e][00000000] 55 push ebp
    ...[00001373][0010229e][00000000] 8bec mov ebp,esp
    ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
    ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
    ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

    Begin Local Halt Decider Simulation Execution Trace Stored at:212352

    // H emulates the first seven instructions of P
    ...[00001352][0021233e][00212342] 55 push ebp // enter P
    ...[00001353][0021233e][00212342] 8bec mov ebp,esp
    ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
    ...[00001358][0021233a][00001352] 50 push eax // push P
    ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
    ...[0000135c][00212336][00001352] 51 push ecx // push P
    ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

    Starting here is where the trace is incomplete.  The emulation of the
    instructions of the inner instance of H are not shown.  Also the lines
    below are not emulated by the top level H.  They are emulated by the
    inner H called by P.  So in between each of these lines is multiple
    instructions of the inner H performing the emulation of them.


    // The emulated H emulates the first seven instructions of P
    ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
    ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
    ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
    ...[00001358][0025cd62][00001352] 50 push eax // push P
    ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
    ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
    ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    Here is where H makes its error of aborting too soon.  Explanation below: >>

    Several different confusions (see below).


    If the execution trace of function H() called by function P() shows:
    (1) Function H() is called twice in sequence from the same machine
    address of P().
    (2) With the same parameters to H().
    (3) With no conditional branch or indexed jump instructions in P().

    This condition is not met.

    (1) is proven
    (2) is proven // Third column shows TOS value of P's machine address
    (3) is proven //

    But there is no Valid rule that actually uses (3), so your whole Thesis
    is incorrect.


    There are branches / jumps in the *program* P contained in the
    function H that can abort.

    We are not looking for jumps, we are looking for code that can change
    the behavior of P from one invocation to the next.
    (a) conditional branch or
    (b) indexed jump instructions (where the index can vary)

    The key is that you don't correctly model H. H(P,P) doesn't just
    infinitely simulate its input, it WILL abort it at some point, we know
    that because you make the assertion that it does this, and then you
    INCORRECT assert that this action is correct.


    The outer H is unable to detect that the inner H will do exactly what
    the outer H does,

    None of this could possibly show that the simulated P ever reaches its
    "ret" instruction, thus is irrelevant.

    It shows that the CORRECT simulation (not the simulation by H, but by a
    CORRECT simulator) of the same input will reach that ret statement.




    We are not asking:
    [A] Does P stop running?

    We are asking:
    [B] Does the simulated P reach its "ret" instruction?

    No, we SHOULD be asking [C] "does the CORRECT simulation of P reach its
    ret instruction", but YOU are asking [D] "does the simulation by H reach
    its ret instruction."

    [C] is a valid restatement of the halting criteria (with correct being
    by definition a UTM).

    [] is NOT a valid restatement



    The answer is no.

    The answer to [C] is yes, so it Halts, the answer to [D] is no, so it
    doesn't POOP.

    Because the definition of halting means that a computation completed
    normally and reached is final instruction H would correctly abort its simulation of P and return 0.

    Right, THE COMPUTATION, not an incomplete simulation of it. The
    COMPUTATION P(P) Halts, so the CORRECT answer, for a Halting decider H
    for H(P,P) is Yes, but your H answers INCORRECTLY 0.


    Halting problem undecidability and infinitely nested simulation (V5)

    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5



    A bunch of FALLACIES.


    namely abort its simulation and return 0.  But the fixed algorithm of H (actually Ha) is unable to see that.  H1 simulating this same input *is* able to see the H embedded in P abort and return 0, causing P to halt.

    Right, the fact that H can't see the halting doesn't mean it doesn't happen.

    H1 gets it right and shows that Ha/H was wrong.



    (4) With no function call returns from H() to P().

    This does happen, but the fixed algorithm of H (again Ha) is unable to
    simulate to the point that this happens.

    then the function call from P() to H() is infinitely recursive.

    ...[00001384][0010229e][00000000] 83c408 add esp,+08
    ...[00001387][0010229a][00000000] 50 push eax
    ...[00001388][00102296][00000423] 6823040000 push 00000423 //
    "Input_Halts = "
    ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call
    Output
    Input_Halts = 0
    ...[00001392][0010229e][00000000] 83c408 add esp,+08
    ...[00001395][0010229e][00000000] 33c0 xor eax,eax
    ...[00001397][001022a2][00100000] 5d pop ebp
    ...[00001398][001022a6][00000004] c3 ret
    Number_of_User_Instructions(1)
    Number of Instructions Executed(15892) = 237 pages
    --
    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 Richard Damon on Sat May 28 11:02:21 2022
    XPost: comp.theory, sci.logic

    On 5/28/2022 10:29 AM, Richard Damon wrote:

    On 5/28/22 11:05 AM, olcott wrote:
    On 5/28/2022 8:58 AM, Richard Damon wrote:

    On 5/28/22 6:26 AM, olcott wrote:
    On 5/27/2022 7:33 PM, Richard Damon wrote:
    On 5/27/22 7:33 PM, olcott wrote:
    On 5/27/2022 6:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:42, olcott wrote:
    On 5/27/2022 5:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:13, olcott wrote:
    On 5/27/2022 4:41 PM, André G. Isaak wrote:
    On 2022-05-27 15:31, olcott wrote:
    On 5/27/2022 4:21 PM, André G. Isaak wrote:
    On 2022-05-27 14:38, olcott wrote:
    On 5/27/2022 3:06 PM, André G. Isaak wrote:
    On 2022-05-27 13:41, olcott wrote:
    On 5/27/2022 2:10 PM, André G. Isaak wrote:
    On 2022-05-27 13:01, olcott wrote:
    On 5/27/2022 1:57 PM, Richard Damon wrote:

    The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>
    The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>> configurations that may or may not reach their own >>>>>>>>>>>>>>>>>> final state.

    I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' >>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are >>>>>>>>>>>>>>>>> not.


    The distinction that I make between represent and >>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents >>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the >>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this >>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior >>>>>>>>>>>>>>>> specified by P(P).

    A sequence of configurations means a list of x86 program >>>>>>>>>>>>>>>> steps executed or emulated in the order that their >>>>>>>>>>>>>>>> source-code specifies.

    Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>
    And this decidedly is *not* what a halt decider is given >>>>>>>>>>>>>>> as its input. It is not given a sequence of state >>>>>>>>>>>>>>> transitions. It is given a representation of a computation. >>>>>>>>>>>>>>>

    No it is not and you know that it is not. A halt decider >>>>>>>>>>>>>> is given a finite string TM description that specifies a >>>>>>>>>>>>>> sequence of configurations.

    A TM description and a sequence of configurations are >>>>>>>>>>>>> entirely different things (and the former certainly does >>>>>>>>>>>>> not 'specify' the latter). It's given either one or the >>>>>>>>>>>>> other. Make up your mind.

    André


    _Infinite_Loop()
    [000012c2](01)  55              push ebp >>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp >>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5 >>>>>>>>>>>> [000012c7](01)  5d              pop ebp
    [000012c8](01)  c3              ret
    Size in bytes:(0007) [000012c8]

    So then the above x86 code may specify a game of tic-tac-toe >>>>>>>>>>>> and there is no possible way to determine that it does not >>>>>>>>>>>> because the x86 source code of a function has nothing to do >>>>>>>>>>>> with the sequence of steps of its correct simulation.


    That is not a sequence of configurations. It is a piece of >>>>>>>>>>> assembly code which represents a subroutine which is an
    infinite loop. The sequence of configurations would look >>>>>>>>>>> something like this:


    Yes that code specifies this sequence.

    No, it does not. What you have above only generates the
    following *only* if you (a) interpret it as representing x86 >>>>>>>>> instructions and (b) actually execute it on an x86 or some
    appropriate emulator.


    Because no one in their right mind would think of doing it
    otherwise those ridiculously self-evident facts need not be stated. >>>>>>>
    You are the one who constantly makes much ado about nothing about >>>>>>> the fact that Turing Machines can ONLY accept finite strings as
    their inputs and object to anyone who suggests that something
    might compute some function which isn't over strings.

    You don't seem to understand exactly what a finite string is. A
    finite string is simply a sequence of symbols. Given two strings, >>>>>>> you can ask questions like which is longer or whether one is a
    substring or permutation of the other, but not much else.

    That's because neither strings nor the symbols they are composed >>>>>>> of have any meaning whatsoever. They are just sequences of
    uninterpreted tokens. As soon as you start talking about
    'sequences of configurations' or 'numerical values' or anything
    along those lines you are no longer talking about finite strings, >>>>>>> but about the entities which those strings represent to a
    particular TM/program.

    Part of designing a TM involves specifying exactly how a string
    is to be interpreted (however 'ridiculously self-evident' it
    might seem to you) So yes, they need to be stated.


    If it was not for communication context then every single rule >>>>>>>> of grammar would have to be repeated with every sentence and
    every definition of every work would have to be repeated over
    and over.

    You keep claiming that the input to the decider is a sequence >>>>>>>>> of configurations, but that's just plain wrong.

    The input to a decider

    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    A sequence of configirations

    Did you notice that I said SPECFIES this time ???

    But you still haven't provided a coherent definition of what
    *you* mean by 'specify'. You gave a bit of wishy-washy verbiage a >>>>>>> few posts ago, but nothing which made this clear. Repeating it
    over and over again doesn't add any clarity.

    The question originally arose when you objected to the claim that >>>>>>> the input to a halt decider represents a computation (or TM
    description/input string pair) and instead insisted that it
    specifies a sequence of configurations.


    Yes of course as everyone knows x86 source-code is one of the
    ingredients to a milkshake and because there is a standard
    practice for making milkshakes they already know when and how the
    x86 source-code must be applied to make a milkshake.

    Now it seems like you are trying to claim that a representation
    of a computation specifies a sequence of configurations, but that >>>>>>> doesn't explain why you so vehemently objected

    Your brain is welded in rebuttal mode?

    to the claim that the input to a halt decider represents a
    computation. So clearly you mean something else altogether.

    André


    Because your brain is welded in rebuttal mode you will always act
    like you never know.


    No, YOUR brain is welded in stupid mode. You are unable to make a
    clear sentence because you misuse the English language to hide your
    lies.

    It is easily provable that the C function H(P,P)==0 is correct on
    the basis of the fact correct execution trace of the x86 source-code
    of input to H(P,P) shows that P would never reach its "ret"
    instruction.

    Again, I say HOW, since the CORRECT emulation of the input to H(P,P),
    as shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H
    is defined to return 0 from H(P,P).

    Richard is one of the two liars.
    *The actual behavior of P when correctly emulated by H is shown below*


    No, it isn't, because it LIES.

    #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()
    [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]

    _main()
    [00001372](01)  55              push ebp
    [00001373](02)  8bec            mov ebp,esp
    [00001375](05)  6852130000      push 00001352 // push P
    [0000137a](05)  6852130000      push 00001352 // push P
    [0000137f](05)  e81efeffff      call 000011a2 // call H
    [00001384](03)  83c408          add esp,+08
    [00001387](01)  50              push eax
    [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
    [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
    [00001392](03)  83c408          add esp,+08
    [00001395](02)  33c0            xor eax,eax
    [00001397](01)  5d              pop ebp
    [00001398](01)  c3              ret
    Size in bytes:(0039) [00001398]

         machine   stack     stack     machine    assembly
         address   address   data      code       language
         ========  ========  ========  =========  =============
    ...[00001372][0010229e][00000000] 55         push ebp
    ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
    ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
    ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
    ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

    Begin Local Halt Decider Simulation   Execution Trace Stored at:212352

    // H emulates the first seven instructions of P
    ...[00001352][0021233e][00212342] 55         push ebp      // enter P
    ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
    ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
    ...[00001358][0021233a][00001352] 50         push eax      // push P
    ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
    ...[0000135c][00212336][00001352] 51         push ecx      // push P
    ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

    // The emulated H emulates the first seven instructions of P
    So, the following is NOT an emulation of the P that the top level H is emulating, and

    Right.

    thus NOT part of a CORRECT x86 emulation of the program.

    Wrong.

    Just like the first invocation of infinite recursion is the root cause
    of the infinite recursion the first invocation of infinitely nested x86 emulation is its root cause.


    You are basically saying that when a C function H emulates another C
    function P and this second C function in

    I spent a year of development of the x86utm operating system so that
    when H(P,P) is invoked and its emulated P calls H(P,P) the outer H could correctly emulate P and P calling H(P,P) and this inner P calling H(P,P)
    to an arbitrary recursive depth.

    I don't show the 236 pages of the emulation of H because we can simply hypothesize that it merely emulates its input and then verify that this hypothesis is correct on the basis that the emulation of the inputs to
    H(P,P) always derive the same execution trace of P.

    LIES -> False Results.

    FAIL


    ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
    ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
    ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
    ...[00001358][0025cd62][00001352] 50         push eax      // push P
    ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
    ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
    ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    UNSOUND LOGIC. This conclusion based on an INCORRECT logicial deduction.

    No proof for the rule has been given.


    If the execution trace of function H() called by function P() shows:
    (1) Function H() is called twice in sequence from the same machine
    address of P().
    (2) With the same parameters to H().
    (3) With no conditional branch or indexed jump instructions in P().

    FALSE RULE, No such rules exists based on CONDITIONAL simulation (due to
    Halt Deciding). You logic is unsound as it assumes that the H that P
    calls never aborts its simulation. The rule that this seems to be based
    on needs no conditional in the FULL execution path from one invocation
    of H to the next, and there are in the "untraced" H.

    (4) With no function call returns from H() to P().
    then the function call from P() to H() is infinitely recursive.

    ...[00001384][0010229e][00000000] 83c408     add esp,+08
    ...[00001387][0010229a][00000000] 50         push eax
    ...[00001388][00102296][00000423] 6823040000 push 00000423 //
    "Input_Halts = "
    ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
    Input_Halts = 0
    ...[00001392][0010229e][00000000] 83c408     add esp,+08
    ...[00001395][0010229e][00000000] 33c0       xor eax,eax
    ...[00001397][001022a2][00100000] 5d         pop ebp
    ...[00001398][001022a6][00000004] c3         ret
    Number_of_User_Instructions(1)
    Number of Instructions Executed(15892) = 237 pages



    I have pointed out several ERRORS in you "Proof", where you quote rules
    that aren't quite correct.

    My guess is you are just going to ignore those comment.

    Provide reference for the rules AS YOU USE THEM, or you are just shown
    to be a LIAR.

    You have shown that you just don't understand the basics of the fields
    you are talking about, and that includes the epistemology that you wider argument is based on.

    You are shown to have NO knowledge of what Truth actually is, and that
    you just don't care about what is actually true, just that you need to
    do SOMETHING, no matter how perverse, to try to "prove" your great idea
    that can't be true.

    YOU FAIL.


    --
    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 Dennis Bush on Sat May 28 11:28:54 2022
    XPost: comp.theory, sci.logic, sci.math

    On 5/28/2022 11:11 AM, Dennis Bush wrote:
    On Saturday, May 28, 2022 at 12:02:30 PM UTC-4, olcott wrote:
    On 5/28/2022 10:29 AM, Richard Damon wrote:

    On 5/28/22 11:05 AM, olcott wrote:
    On 5/28/2022 8:58 AM, Richard Damon wrote:

    On 5/28/22 6:26 AM, olcott wrote:
    On 5/27/2022 7:33 PM, Richard Damon wrote:
    On 5/27/22 7:33 PM, olcott wrote:
    On 5/27/2022 6:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:42, olcott wrote:
    On 5/27/2022 5:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:13, olcott wrote:
    On 5/27/2022 4:41 PM, André G. Isaak wrote:
    On 2022-05-27 15:31, olcott wrote:
    On 5/27/2022 4:21 PM, André G. Isaak wrote:
    On 2022-05-27 14:38, olcott wrote:
    On 5/27/2022 3:06 PM, André G. Isaak wrote:
    On 2022-05-27 13:41, olcott wrote:
    On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
    On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>
    The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>>>
    The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own >>>>>>>>>>>>>>>>>>>> final state.

    I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' >>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are >>>>>>>>>>>>>>>>>>> not.


    The distinction that I make between represent and >>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents >>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the >>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this >>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior >>>>>>>>>>>>>>>>>> specified by P(P).

    A sequence of configurations means a list of x86 program >>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their >>>>>>>>>>>>>>>>>> source-code specifies.

    Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>>
    And this decidedly is *not* what a halt decider is given >>>>>>>>>>>>>>>>> as its input. It is not given a sequence of state >>>>>>>>>>>>>>>>> transitions. It is given a representation of a computation. >>>>>>>>>>>>>>>>>

    No it is not and you know that it is not. A halt decider >>>>>>>>>>>>>>>> is given a finite string TM description that specifies a >>>>>>>>>>>>>>>> sequence of configurations.

    A TM description and a sequence of configurations are >>>>>>>>>>>>>>> entirely different things (and the former certainly does >>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the >>>>>>>>>>>>>>> other. Make up your mind.

    André


    _Infinite_Loop()
    [000012c2](01) 55 push ebp
    [000012c3](02) 8bec mov ebp,esp
    [000012c5](02) ebfe jmp 000012c5
    [000012c7](01) 5d pop ebp
    [000012c8](01) c3 ret
    Size in bytes:(0007) [000012c8]

    So then the above x86 code may specify a game of tic-tac-toe >>>>>>>>>>>>>> and there is no possible way to determine that it does not >>>>>>>>>>>>>> because the x86 source code of a function has nothing to do >>>>>>>>>>>>>> with the sequence of steps of its correct simulation. >>>>>>>>>>>>>

    That is not a sequence of configurations. It is a piece of >>>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>>> something like this:


    Yes that code specifies this sequence.

    No, it does not. What you have above only generates the
    following *only* if you (a) interpret it as representing x86 >>>>>>>>>>> instructions and (b) actually execute it on an x86 or some >>>>>>>>>>> appropriate emulator.


    Because no one in their right mind would think of doing it >>>>>>>>>> otherwise those ridiculously self-evident facts need not be stated. >>>>>>>>>
    You are the one who constantly makes much ado about nothing about >>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as >>>>>>>>> their inputs and object to anyone who suggests that something >>>>>>>>> might compute some function which isn't over strings.

    You don't seem to understand exactly what a finite string is. A >>>>>>>>> finite string is simply a sequence of symbols. Given two strings, >>>>>>>>> you can ask questions like which is longer or whether one is a >>>>>>>>> substring or permutation of the other, but not much else.

    That's because neither strings nor the symbols they are composed >>>>>>>>> of have any meaning whatsoever. They are just sequences of
    uninterpreted tokens. As soon as you start talking about
    'sequences of configurations' or 'numerical values' or anything >>>>>>>>> along those lines you are no longer talking about finite strings, >>>>>>>>> but about the entities which those strings represent to a
    particular TM/program.

    Part of designing a TM involves specifying exactly how a string >>>>>>>>> is to be interpreted (however 'ridiculously self-evident' it >>>>>>>>> might seem to you) So yes, they need to be stated.


    If it was not for communication context then every single rule >>>>>>>>>> of grammar would have to be repeated with every sentence and >>>>>>>>>> every definition of every work would have to be repeated over >>>>>>>>>> and over.

    You keep claiming that the input to the decider is a sequence >>>>>>>>>>> of configurations, but that's just plain wrong.

    The input to a decider

    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    A sequence of configirations

    Did you notice that I said SPECFIES this time ???

    But you still haven't provided a coherent definition of what >>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage a >>>>>>>>> few posts ago, but nothing which made this clear. Repeating it >>>>>>>>> over and over again doesn't add any clarity.

    The question originally arose when you objected to the claim that >>>>>>>>> the input to a halt decider represents a computation (or TM
    description/input string pair) and instead insisted that it
    specifies a sequence of configurations.


    Yes of course as everyone knows x86 source-code is one of the
    ingredients to a milkshake and because there is a standard
    practice for making milkshakes they already know when and how the >>>>>>>> x86 source-code must be applied to make a milkshake.

    Now it seems like you are trying to claim that a representation >>>>>>>>> of a computation specifies a sequence of configurations, but that >>>>>>>>> doesn't explain why you so vehemently objected

    Your brain is welded in rebuttal mode?

    to the claim that the input to a halt decider represents a
    computation. So clearly you mean something else altogether.

    André


    Because your brain is welded in rebuttal mode you will always act >>>>>>>> like you never know.


    No, YOUR brain is welded in stupid mode. You are unable to make a >>>>>>> clear sentence because you misuse the English language to hide your >>>>>>> lies.

    It is easily provable that the C function H(P,P)==0 is correct on
    the basis of the fact correct execution trace of the x86 source-code >>>>>> of input to H(P,P) shows that P would never reach its "ret"
    instruction.

    Again, I say HOW, since the CORRECT emulation of the input to H(P,P), >>>>> as shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H >>>>> is defined to return 0 from H(P,P).

    Richard is one of the two liars.
    *The actual behavior of P when correctly emulated by H is shown below*


    No, it isn't, because it LIES.

    #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()
    [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]

    _main()
    [00001372](01) 55 push ebp
    [00001373](02) 8bec mov ebp,esp
    [00001375](05) 6852130000 push 00001352 // push P
    [0000137a](05) 6852130000 push 00001352 // push P
    [0000137f](05) e81efeffff call 000011a2 // call H
    [00001384](03) 83c408 add esp,+08
    [00001387](01) 50 push eax
    [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
    [0000138d](05) e8e0f0ffff call 00000472 // call Output
    [00001392](03) 83c408 add esp,+08
    [00001395](02) 33c0 xor eax,eax
    [00001397](01) 5d pop ebp
    [00001398](01) c3 ret
    Size in bytes:(0039) [00001398]

    machine stack stack machine assembly
    address address data code language
    ======== ======== ======== ========= =============
    ...[00001372][0010229e][00000000] 55 push ebp
    ...[00001373][0010229e][00000000] 8bec mov ebp,esp
    ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
    ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
    ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

    Begin Local Halt Decider Simulation Execution Trace Stored at:212352 >>>>
    // H emulates the first seven instructions of P
    ...[00001352][0021233e][00212342] 55 push ebp // enter P
    ...[00001353][0021233e][00212342] 8bec mov ebp,esp
    ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
    ...[00001358][0021233a][00001352] 50 push eax // push P
    ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
    ...[0000135c][00212336][00001352] 51 push ecx // push P
    ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

    // The emulated H emulates the first seven instructions of P
    So, the following is NOT an emulation of the P that the top level H is
    emulating, and
    Right.
    thus NOT part of a CORRECT x86 emulation of the program.
    Wrong.

    Just like the first invocation of infinite recursion is the root cause
    of the infinite recursion the first invocation of infinitely nested x86
    emulation is its root cause.


    You are basically saying that when a C function H emulates another C
    function P and this second C function in

    I spent a year of development of the x86utm operating system so that
    when H(P,P) is invoked and its emulated P calls H(P,P) the outer H could
    correctly emulate P and P calling H(P,P) and this inner P calling H(P,P)
    to an arbitrary recursive depth.

    I don't show the 236 pages of the emulation of H because we can simply
    hypothesize that it merely emulates its input

    Deceptive use of "H" to refer to multiple unrelated computations.

    The fixed algorithm of H, hereafter referred to as Ha, and the P that calls it referred to as Pa, does abort and does not "merely emulate". Hn is what does that. And since Pa doesn't call Hn that means we are no longer deciding on Pa but on Pn.

    So your argument boils down to: Ha(Pa,Pa)==0 is correct because Pn(Pn) does not halt.


    A halt decider must only compute the mapping from its input to an accept
    or reject state based on the actual behavior specified by this input.

    It is the case that the correct x86 emulation of the input to H(P,P) by
    H would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
    proved to be correct.





    --
    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 Sat May 28 12:43:06 2022
    XPost: comp.theory, sci.logic, sci.math

    On 5/28/22 12:28 PM, olcott wrote:
    On 5/28/2022 11:11 AM, Dennis Bush wrote:
    On Saturday, May 28, 2022 at 12:02:30 PM UTC-4, olcott wrote:
    On 5/28/2022 10:29 AM, Richard Damon wrote:

    On 5/28/22 11:05 AM, olcott wrote:
    On 5/28/2022 8:58 AM, Richard Damon wrote:

    On 5/28/22 6:26 AM, olcott wrote:
    On 5/27/2022 7:33 PM, Richard Damon wrote:
    On 5/27/22 7:33 PM, olcott wrote:
    On 5/27/2022 6:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:42, olcott wrote:
    On 5/27/2022 5:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:13, olcott wrote:
    On 5/27/2022 4:41 PM, André G. Isaak wrote:
    On 2022-05-27 15:31, olcott wrote:
    On 5/27/2022 4:21 PM, André G. Isaak wrote:
    On 2022-05-27 14:38, olcott wrote:
    On 5/27/2022 3:06 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
    On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
    On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>
    The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>>>>
    The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own >>>>>>>>>>>>>>>>>>>>> final state.

    I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' >>>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are >>>>>>>>>>>>>>>>>>>> not.


    The distinction that I make between represent and >>>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents >>>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the >>>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this >>>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior >>>>>>>>>>>>>>>>>>> specified by P(P).

    A sequence of configurations means a list of x86 program >>>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their >>>>>>>>>>>>>>>>>>> source-code specifies.

    Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>>>
    And this decidedly is *not* what a halt decider is given >>>>>>>>>>>>>>>>>> as its input. It is not given a sequence of state >>>>>>>>>>>>>>>>>> transitions. It is given a representation of a >>>>>>>>>>>>>>>>>> computation.


    No it is not and you know that it is not. A halt decider >>>>>>>>>>>>>>>>> is given a finite string TM description that specifies a >>>>>>>>>>>>>>>>> sequence of configurations.

    A TM description and a sequence of configurations are >>>>>>>>>>>>>>>> entirely different things (and the former certainly does >>>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the >>>>>>>>>>>>>>>> other. Make up your mind.

    André


    _Infinite_Loop()
    [000012c2](01)  55              push ebp >>>>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp >>>>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5 >>>>>>>>>>>>>>> [000012c7](01)  5d              pop ebp >>>>>>>>>>>>>>> [000012c8](01)  c3              ret >>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]

    So then the above x86 code may specify a game of tic-tac-toe >>>>>>>>>>>>>>> and there is no possible way to determine that it does not >>>>>>>>>>>>>>> because the x86 source code of a function has nothing to do >>>>>>>>>>>>>>> with the sequence of steps of its correct simulation. >>>>>>>>>>>>>>

    That is not a sequence of configurations. It is a piece of >>>>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>>>> something like this:


    Yes that code specifies this sequence.

    No, it does not. What you have above only generates the >>>>>>>>>>>> following *only* if you (a) interpret it as representing x86 >>>>>>>>>>>> instructions and (b) actually execute it on an x86 or some >>>>>>>>>>>> appropriate emulator.


    Because no one in their right mind would think of doing it >>>>>>>>>>> otherwise those ridiculously self-evident facts need not be >>>>>>>>>>> stated.

    You are the one who constantly makes much ado about nothing about >>>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as >>>>>>>>>> their inputs and object to anyone who suggests that something >>>>>>>>>> might compute some function which isn't over strings.

    You don't seem to understand exactly what a finite string is. A >>>>>>>>>> finite string is simply a sequence of symbols. Given two strings, >>>>>>>>>> you can ask questions like which is longer or whether one is a >>>>>>>>>> substring or permutation of the other, but not much else.

    That's because neither strings nor the symbols they are composed >>>>>>>>>> of have any meaning whatsoever. They are just sequences of >>>>>>>>>> uninterpreted tokens. As soon as you start talking about
    'sequences of configurations' or 'numerical values' or anything >>>>>>>>>> along those lines you are no longer talking about finite strings, >>>>>>>>>> but about the entities which those strings represent to a
    particular TM/program.

    Part of designing a TM involves specifying exactly how a string >>>>>>>>>> is to be interpreted (however 'ridiculously self-evident' it >>>>>>>>>> might seem to you) So yes, they need to be stated.


    If it was not for communication context then every single rule >>>>>>>>>>> of grammar would have to be repeated with every sentence and >>>>>>>>>>> every definition of every work would have to be repeated over >>>>>>>>>>> and over.

    You keep claiming that the input to the decider is a sequence >>>>>>>>>>>> of configurations, but that's just plain wrong.

    The input to a decider

    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    A sequence of configirations

    Did you notice that I said SPECFIES this time ???

    But you still haven't provided a coherent definition of what >>>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage a >>>>>>>>>> few posts ago, but nothing which made this clear. Repeating it >>>>>>>>>> over and over again doesn't add any clarity.

    The question originally arose when you objected to the claim that >>>>>>>>>> the input to a halt decider represents a computation (or TM >>>>>>>>>> description/input string pair) and instead insisted that it >>>>>>>>>> specifies a sequence of configurations.


    Yes of course as everyone knows x86 source-code is one of the >>>>>>>>> ingredients to a milkshake and because there is a standard
    practice for making milkshakes they already know when and how the >>>>>>>>> x86 source-code must be applied to make a milkshake.

    Now it seems like you are trying to claim that a representation >>>>>>>>>> of a computation specifies a sequence of configurations, but that >>>>>>>>>> doesn't explain why you so vehemently objected

    Your brain is welded in rebuttal mode?

    to the claim that the input to a halt decider represents a >>>>>>>>>> computation. So clearly you mean something else altogether. >>>>>>>>>>
    André


    Because your brain is welded in rebuttal mode you will always act >>>>>>>>> like you never know.


    No, YOUR brain is welded in stupid mode. You are unable to make a >>>>>>>> clear sentence because you misuse the English language to hide your >>>>>>>> lies.

    It is easily provable that the C function H(P,P)==0 is correct on >>>>>>> the basis of the fact correct execution trace of the x86 source-code >>>>>>> of input to H(P,P) shows that P would never reach its "ret"
    instruction.

    Again, I say HOW, since the CORRECT emulation of the input to H(P,P), >>>>>> as shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H >>>>>> is defined to return 0 from H(P,P).

    Richard is one of the two liars.
    *The actual behavior of P when correctly emulated by H is shown below* >>>>

    No, it isn't, because it LIES.

    #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()
    [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]

    _main()
    [00001372](01)  55              push ebp
    [00001373](02)  8bec            mov ebp,esp
    [00001375](05)  6852130000      push 00001352 // push P
    [0000137a](05)  6852130000      push 00001352 // push P
    [0000137f](05)  e81efeffff      call 000011a2 // call H
    [00001384](03)  83c408          add esp,+08
    [00001387](01)  50              push eax
    [00001388](05)  6823040000      push 00000423 // "Input_Halts = " >>>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
    [00001392](03)  83c408          add esp,+08
    [00001395](02)  33c0            xor eax,eax
    [00001397](01)  5d              pop ebp
    [00001398](01)  c3              ret
    Size in bytes:(0039) [00001398]

          machine   stack     stack     machine    assembly >>>>>       address   address   data      code       language
          ========  ========  ========  =========  ============= >>>>> ...[00001372][0010229e][00000000] 55         push ebp
    ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
    ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P >>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P >>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H >>>>>
    Begin Local Halt Decider Simulation   Execution Trace Stored at:212352 >>>>>
    // H emulates the first seven instructions of P
    ...[00001352][0021233e][00212342] 55         push ebp      // enter P
    ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
    ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
    ...[00001358][0021233a][00001352] 50         push eax      // push P
    ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
    ...[0000135c][00212336][00001352] 51         push ecx      // push P
    ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H >>>>>
    // The emulated H emulates the first seven instructions of P
    So, the following is NOT an emulation of the P that the top level H is >>>> emulating, and
    Right.
    thus NOT part of a CORRECT x86 emulation of the program.
    Wrong.

    Just like the first invocation of infinite recursion is the root cause
    of the infinite recursion the first invocation of infinitely nested x86
    emulation is its root cause.


    You are basically saying that when a C function H emulates another C
    function P and this second C function in

    I spent a year of development of the x86utm operating system so that
    when H(P,P) is invoked and its emulated P calls H(P,P) the outer H could >>> correctly emulate P and P calling H(P,P) and this inner P calling H(P,P) >>> to an arbitrary recursive depth.

    I don't show the 236 pages of the emulation of H because we can simply
    hypothesize that it merely emulates its input

    Deceptive use of "H" to refer to multiple unrelated computations.

    The fixed algorithm of H, hereafter referred to as Ha, and the P that
    calls it referred to as Pa, does abort and does not "merely emulate".
    Hn is what does that.  And since Pa doesn't call Hn that means we are
    no longer deciding on Pa but on Pn.

    So your argument boils down to:  Ha(Pa,Pa)==0 is correct because
    Pn(Pn) does  not halt.


    A halt decider must only compute the mapping from its input to an accept
    or reject state based on the actual behavior specified by this input.

    It is the case that the correct x86 emulation of the input to H(P,P) by
    H would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
    proved to be correct.


    Nope, you have the words wrong.

    A Halt Decider MUST compute the mapping from its input to an accept or
    reject state based on the actual mapping it is supposed to computer,
    which becomes the DEFINITION of the behavior specified by its inputs.

    For Halting H(M,w) Must accept if and only if M(w) halts.

    THAT IS THE "Behavior specified by its inputs"

    A Halt Decider CAN only compute something that actually computable, and
    we have no promise that Halting is that (in fact, that becomes your
    claim to be proven). The fact that H can't actually get the right answer doesn't say the question is wrong, just that the question might be
    uncomputable and thus the Halting Theorem asserted.

    The CORRECT x86 emulation of the input to H(P,P) will EXACTLY match the behavior of P(P), by the definition of CORRECT EMULATION. The fact that
    H can't actually do that is irrelevent.

    For this structure of design, NO implementation of H will ever be able
    to simulate its input till it reaches that ret instruciton.

    BUT, If that H aborts its simulation (and thus forfeit the ability to be
    a totally correct simulation) and returns 0, then it can be shown that
    the CORRECT simulation will reach that ret.

    If H doesn't abort its simulation, it then becomes clear that it fails
    to answer, and thus is not a decider.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sat May 28 12:35:46 2022
    XPost: comp.theory, sci.logic

    On 5/28/22 12:02 PM, olcott wrote:
    On 5/28/2022 10:29 AM, Richard Damon wrote:

    On 5/28/22 11:05 AM, olcott wrote:
    On 5/28/2022 8:58 AM, Richard Damon wrote:

    On 5/28/22 6:26 AM, olcott wrote:
    On 5/27/2022 7:33 PM, Richard Damon wrote:
    On 5/27/22 7:33 PM, olcott wrote:
    On 5/27/2022 6:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:42, olcott wrote:
    On 5/27/2022 5:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:13, olcott wrote:
    On 5/27/2022 4:41 PM, André G. Isaak wrote:
    On 2022-05-27 15:31, olcott wrote:
    On 5/27/2022 4:21 PM, André G. Isaak wrote:
    On 2022-05-27 14:38, olcott wrote:
    On 5/27/2022 3:06 PM, André G. Isaak wrote:
    On 2022-05-27 13:41, olcott wrote:
    On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
    On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>
    The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>>
    The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own >>>>>>>>>>>>>>>>>>> final state.

    I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of
    configurations' mean. Richard is perfectly correct. >>>>>>>>>>>>>>>>>> You, as usual, are not.


    The distinction that I make between represent and >>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents >>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the >>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this >>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior >>>>>>>>>>>>>>>>> specified by P(P).

    A sequence of configurations means a list of x86 >>>>>>>>>>>>>>>>> program steps executed or emulated in the order that >>>>>>>>>>>>>>>>> their source-code specifies.

    Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>
    And this decidedly is *not* what a halt decider is given >>>>>>>>>>>>>>>> as its input. It is not given a sequence of state >>>>>>>>>>>>>>>> transitions. It is given a representation of a computation. >>>>>>>>>>>>>>>>

    No it is not and you know that it is not. A halt decider >>>>>>>>>>>>>>> is given a finite string TM description that specifies a >>>>>>>>>>>>>>> sequence of configurations.

    A TM description and a sequence of configurations are >>>>>>>>>>>>>> entirely different things (and the former certainly does >>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the >>>>>>>>>>>>>> other. Make up your mind.

    André


    _Infinite_Loop()
    [000012c2](01)  55              push ebp >>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp >>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5 >>>>>>>>>>>>> [000012c7](01)  5d              pop ebp >>>>>>>>>>>>> [000012c8](01)  c3              ret
    Size in bytes:(0007) [000012c8]

    So then the above x86 code may specify a game of
    tic-tac-toe and there is no possible way to determine that >>>>>>>>>>>>> it does not because the x86 source code of a function has >>>>>>>>>>>>> nothing to do with the sequence of steps of its correct >>>>>>>>>>>>> simulation.


    That is not a sequence of configurations. It is a piece of >>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>> something like this:


    Yes that code specifies this sequence.

    No, it does not. What you have above only generates the
    following *only* if you (a) interpret it as representing x86 >>>>>>>>>> instructions and (b) actually execute it on an x86 or some >>>>>>>>>> appropriate emulator.


    Because no one in their right mind would think of doing it
    otherwise those ridiculously self-evident facts need not be
    stated.

    You are the one who constantly makes much ado about nothing
    about the fact that Turing Machines can ONLY accept finite
    strings as their inputs and object to anyone who suggests that >>>>>>>> something might compute some function which isn't over strings. >>>>>>>>
    You don't seem to understand exactly what a finite string is. A >>>>>>>> finite string is simply a sequence of symbols. Given two
    strings, you can ask questions like which is longer or whether >>>>>>>> one is a substring or permutation of the other, but not much else. >>>>>>>>
    That's because neither strings nor the symbols they are composed >>>>>>>> of have any meaning whatsoever. They are just sequences of
    uninterpreted tokens. As soon as you start talking about
    'sequences of configurations' or 'numerical values' or anything >>>>>>>> along those lines you are no longer talking about finite
    strings, but about the entities which those strings represent to >>>>>>>> a particular TM/program.

    Part of designing a TM involves specifying exactly how a string >>>>>>>> is to be interpreted (however 'ridiculously self-evident' it
    might seem to you) So yes, they need to be stated.


    If it was not for communication context then every single rule >>>>>>>>> of grammar would have to be repeated with every sentence and >>>>>>>>> every definition of every work would have to be repeated over >>>>>>>>> and over.

    You keep claiming that the input to the decider is a sequence >>>>>>>>>> of configurations, but that's just plain wrong.

    The input to a decider

    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    A sequence of configirations

    Did you notice that I said SPECFIES this time ???

    But you still haven't provided a coherent definition of what
    *you* mean by 'specify'. You gave a bit of wishy-washy verbiage >>>>>>>> a few posts ago, but nothing which made this clear. Repeating it >>>>>>>> over and over again doesn't add any clarity.

    The question originally arose when you objected to the claim
    that the input to a halt decider represents a computation (or TM >>>>>>>> description/input string pair) and instead insisted that it
    specifies a sequence of configurations.


    Yes of course as everyone knows x86 source-code is one of the
    ingredients to a milkshake and because there is a standard
    practice for making milkshakes they already know when and how the >>>>>>> x86 source-code must be applied to make a milkshake.

    Now it seems like you are trying to claim that a representation >>>>>>>> of a computation specifies a sequence of configurations, but
    that doesn't explain why you so vehemently objected

    Your brain is welded in rebuttal mode?

    to the claim that the input to a halt decider represents a
    computation. So clearly you mean something else altogether.

    André


    Because your brain is welded in rebuttal mode you will always act >>>>>>> like you never know.


    No, YOUR brain is welded in stupid mode. You are unable to make a
    clear sentence because you misuse the English language to hide
    your lies.

    It is easily provable that the C function H(P,P)==0 is correct on
    the basis of the fact correct execution trace of the x86
    source-code of input to H(P,P) shows that P would never reach its
    "ret" instruction.

    Again, I say HOW, since the CORRECT emulation of the input to
    H(P,P), as shown by UTM(P,P), H1(P,P), or even P(P) shows that it
    Halts, if H is defined to return 0 from H(P,P).

    Richard is one of the two liars.
    *The actual behavior of P when correctly emulated by H is shown below*


    No, it isn't, because it LIES.

    #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()
    [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]

    _main()
    [00001372](01)  55              push ebp
    [00001373](02)  8bec            mov ebp,esp
    [00001375](05)  6852130000      push 00001352 // push P
    [0000137a](05)  6852130000      push 00001352 // push P
    [0000137f](05)  e81efeffff      call 000011a2 // call H
    [00001384](03)  83c408          add esp,+08
    [00001387](01)  50              push eax
    [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
    [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
    [00001392](03)  83c408          add esp,+08
    [00001395](02)  33c0            xor eax,eax
    [00001397](01)  5d              pop ebp
    [00001398](01)  c3              ret
    Size in bytes:(0039) [00001398]

         machine   stack     stack     machine    assembly
         address   address   data      code       language >>>      ========  ========  ========  =========  =============
    ...[00001372][0010229e][00000000] 55         push ebp
    ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
    ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
    ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
    ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

    Begin Local Halt Decider Simulation   Execution Trace Stored at:212352 >>>
    // H emulates the first seven instructions of P
    ...[00001352][0021233e][00212342] 55         push ebp      // enter P
    ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
    ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
    ...[00001358][0021233a][00001352] 50         push eax      // push P
    ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
    ...[0000135c][00212336][00001352] 51         push ecx      // push P
    ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

    // The emulated H emulates the first seven instructions of P
    So, the following is NOT an emulation of the P that the top level H is
    emulating, and

    Right.

    thus NOT part of a CORRECT x86 emulation of the program.

    Wrong.

    Just like the first invocation of infinite recursion is the root cause
    of the infinite recursion the first invocation of infinitely nested x86 emulation is its root cause.


    Except you don't understand the definitions.

    The second emulation is NOT an emulation by the emulator we are looking
    at (At least not if H is how you have defined it), so can't be just
    called part of it.


    You are basically saying that when a C function H emulates another C
    function P and this second C function in

    I spent a year of development of the x86utm operating system so that
    when H(P,P) is invoked and its emulated P calls H(P,P) the outer H could correctly emulate P and P calling H(P,P) and this inner P calling H(P,P)
    to an arbitrary recursive depth.

    And that is your error. First, this seems to make H no longer a
    computation, as its "actual" behavior depends on if it is being emulated
    by a copy of H, which is something that H can't actually depend on and
    be a computation.



    I don't show the 236 pages of the emulation of H because we can simply hypothesize that it merely emulates its input and then verify that this hypothesis is correct on the basis that the emulation of the inputs to
    H(P,P) always derive the same execution trace of P.

    But then you trace needs to clearly label that, and your analysis needs
    to take that into account.

    Your rule of "No conditionals in the code of P" just fails when we take
    this into account. Once the P is actually a simulated P by a Halt
    Decider, EVERY INSTRUCTION becomes a conditional abort point by the
    action of that decider.

    Your whole argument is premised on that copy of H will never abort, but
    we know it would eventually if H is actually a computation, because the
    outer one does.

    Thus, you whole logic trains is proved both INVALID and UNSOUND.

    Part of the issue is you have re-written the definition of Halting (so
    it no longer is actually a Halting Definition) to be based on what H can
    deduce (when the Halting property of the computation represented by the
    inputs to H is NOT dependent on what that instance of H does). The mere
    fact that you say H(P,P) == 0 and H1(P,P) == 1 are both correct shows
    that what you are calling "Halting" can't be, as it is only a function
    of P,P, and not the decider looking at it.

    FAIL.


    LIES -> False Results.

    FAIL


    ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
    ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
    ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
    ...[00001358][0025cd62][00001352] 50         push eax      // push P
    ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
    ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
    ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    UNSOUND LOGIC. This conclusion based on an INCORRECT logicial deduction.

    No proof for the rule has been given.


    If the execution trace of function H() called by function P() shows:
    (1) Function H() is called twice in sequence from the same machine
    address of P().
    (2) With the same parameters to H().
    (3) With no conditional branch or indexed jump instructions in P().

    FALSE RULE, No such rules exists based on CONDITIONAL simulation (due
    to Halt Deciding). You logic is unsound as it assumes that the H that
    P calls never aborts its simulation. The rule that this seems to be
    based on needs no conditional in the FULL execution path from one
    invocation of H to the next, and there are in the "untraced" H.

    (4) With no function call returns from H() to P().
    then the function call from P() to H() is infinitely recursive.

    ...[00001384][0010229e][00000000] 83c408     add esp,+08
    ...[00001387][0010229a][00000000] 50         push eax
    ...[00001388][00102296][00000423] 6823040000 push 00000423 //
    "Input_Halts = "
    ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call
    Output
    Input_Halts = 0
    ...[00001392][0010229e][00000000] 83c408     add esp,+08
    ...[00001395][0010229e][00000000] 33c0       xor eax,eax
    ...[00001397][001022a2][00100000] 5d         pop ebp
    ...[00001398][001022a6][00000004] c3         ret
    Number_of_User_Instructions(1)
    Number of Instructions Executed(15892) = 237 pages



    I have pointed out several ERRORS in you "Proof", where you quote
    rules that aren't quite correct.

    My guess is you are just going to ignore those comment.

    Provide reference for the rules AS YOU USE THEM, or you are just shown
    to be a LIAR.

    You have shown that you just don't understand the basics of the fields
    you are talking about, and that includes the epistemology that you
    wider argument is based on.

    You are shown to have NO knowledge of what Truth actually is, and that
    you just don't care about what is actually true, just that you need to
    do SOMETHING, no matter how perverse, to try to "prove" your great
    idea that can't be true.

    YOU FAIL.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Dennis Bush on Sat May 28 11:24:56 2022
    XPost: comp.theory, sci.logic, sci.math

    On 5/28/2022 11:06 AM, Dennis Bush wrote:
    On Saturday, May 28, 2022 at 11:48:43 AM UTC-4, olcott wrote:
    On 5/28/2022 10:23 AM, Dennis Bush wrote:
    On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:
    On 5/28/2022 8:58 AM, Richard Damon wrote:

    On 5/28/22 6:26 AM, olcott wrote:
    On 5/27/2022 7:33 PM, Richard Damon wrote:
    On 5/27/22 7:33 PM, olcott wrote:
    On 5/27/2022 6:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:42, olcott wrote:
    On 5/27/2022 5:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:13, olcott wrote:
    On 5/27/2022 4:41 PM, André G. Isaak wrote:
    On 2022-05-27 15:31, olcott wrote:
    On 5/27/2022 4:21 PM, André G. Isaak wrote:
    On 2022-05-27 14:38, olcott wrote:
    On 5/27/2022 3:06 PM, André G. Isaak wrote:
    On 2022-05-27 13:41, olcott wrote:
    On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
    On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>
    The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>>>
    The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own final >>>>>>>>>>>>>>>>>>>> state.

    I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' >>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are not. >>>>>>>>>>>>>>>>>>>

    The distinction that I make between represent and specify >>>>>>>>>>>>>>>>>> is that the x86 source-code for P represents P(P) whereas >>>>>>>>>>>>>>>>>> the actual correct x86 emulation of the input to H(P,P) >>>>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not >>>>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P). >>>>>>>>>>>>>>>>>>
    A sequence of configurations means a list of x86 program >>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their >>>>>>>>>>>>>>>>>> source-code specifies.

    Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>>
    And this decidedly is *not* what a halt decider is given as >>>>>>>>>>>>>>>>> its input. It is not given a sequence of state transitions. >>>>>>>>>>>>>>>>> It is given a representation of a computation. >>>>>>>>>>>>>>>>>

    No it is not and you know that it is not. A halt decider is >>>>>>>>>>>>>>>> given a finite string TM description that specifies a >>>>>>>>>>>>>>>> sequence of configurations.

    A TM description and a sequence of configurations are >>>>>>>>>>>>>>> entirely different things (and the former certainly does not >>>>>>>>>>>>>>> 'specify' the latter). It's given either one or the other. >>>>>>>>>>>>>>> Make up your mind.

    André


    _Infinite_Loop()
    [000012c2](01) 55 push ebp
    [000012c3](02) 8bec mov ebp,esp
    [000012c5](02) ebfe jmp 000012c5
    [000012c7](01) 5d pop ebp
    [000012c8](01) c3 ret
    Size in bytes:(0007) [000012c8]

    So then the above x86 code may specify a game of tic-tac-toe >>>>>>>>>>>>>> and there is no possible way to determine that it does not >>>>>>>>>>>>>> because the x86 source code of a function has nothing to do >>>>>>>>>>>>>> with the sequence of steps of its correct simulation. >>>>>>>>>>>>>

    That is not a sequence of configurations. It is a piece of >>>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>>> something like this:


    Yes that code specifies this sequence.

    No, it does not. What you have above only generates the following >>>>>>>>>>> *only* if you (a) interpret it as representing x86 instructions >>>>>>>>>>> and (b) actually execute it on an x86 or some appropriate emulator. >>>>>>>>>>>

    Because no one in their right mind would think of doing it >>>>>>>>>> otherwise those ridiculously self-evident facts need not be stated. >>>>>>>>>
    You are the one who constantly makes much ado about nothing about >>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as >>>>>>>>> their inputs and object to anyone who suggests that something might >>>>>>>>> compute some function which isn't over strings.

    You don't seem to understand exactly what a finite string is. A >>>>>>>>> finite string is simply a sequence of symbols. Given two strings, >>>>>>>>> you can ask questions like which is longer or whether one is a >>>>>>>>> substring or permutation of the other, but not much else.

    That's because neither strings nor the symbols they are composed of >>>>>>>>> have any meaning whatsoever. They are just sequences of
    uninterpreted tokens. As soon as you start talking about 'sequences >>>>>>>>> of configurations' or 'numerical values' or anything along those >>>>>>>>> lines you are no longer talking about finite strings, but about the >>>>>>>>> entities which those strings represent to a particular TM/program. >>>>>>>>>
    Part of designing a TM involves specifying exactly how a string is >>>>>>>>> to be interpreted (however 'ridiculously self-evident' it might >>>>>>>>> seem to you) So yes, they need to be stated.


    If it was not for communication context then every single rule of >>>>>>>>>> grammar would have to be repeated with every sentence and every >>>>>>>>>> definition of every work would have to be repeated over and over. >>>>>>>>>>
    You keep claiming that the input to the decider is a sequence of >>>>>>>>>>> configurations, but that's just plain wrong.

    The input to a decider

    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    A sequence of configirations

    Did you notice that I said SPECFIES this time ???

    But you still haven't provided a coherent definition of what *you* >>>>>>>>> mean by 'specify'. You gave a bit of wishy-washy verbiage a few >>>>>>>>> posts ago, but nothing which made this clear. Repeating it over and >>>>>>>>> over again doesn't add any clarity.

    The question originally arose when you objected to the claim that >>>>>>>>> the input to a halt decider represents a computation (or TM
    description/input string pair) and instead insisted that it
    specifies a sequence of configurations.


    Yes of course as everyone knows x86 source-code is one of the
    ingredients to a milkshake and because there is a standard practice >>>>>>>> for making milkshakes they already know when and how the x86
    source-code must be applied to make a milkshake.

    Now it seems like you are trying to claim that a representation of >>>>>>>>> a computation specifies a sequence of configurations, but that >>>>>>>>> doesn't explain why you so vehemently objected

    Your brain is welded in rebuttal mode?

    to the claim that the input to a halt decider represents a
    computation. So clearly you mean something else altogether.

    André


    Because your brain is welded in rebuttal mode you will always act >>>>>>>> like you never know.


    No, YOUR brain is welded in stupid mode. You are unable to make a >>>>>>> clear sentence because you misuse the English language to hide your >>>>>>> lies.

    It is easily provable that the C function H(P,P)==0 is correct on the >>>>>> basis of the fact correct execution trace of the x86 source-code of >>>>>> input to H(P,P) shows that P would never reach its "ret" instruction. >>>>>
    Again, I say HOW, since the CORRECT emulation of the input to H(P,P), as >>>>> shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is >>>>> defined to return 0 from H(P,P).
    Richard is one of the two liars.
    *The actual behavior of P when correctly emulated by H is shown below* >>>>
    #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()
    [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]

    _main()
    [00001372](01) 55 push ebp
    [00001373](02) 8bec mov ebp,esp
    [00001375](05) 6852130000 push 00001352 // push P
    [0000137a](05) 6852130000 push 00001352 // push P
    [0000137f](05) e81efeffff call 000011a2 // call H
    [00001384](03) 83c408 add esp,+08
    [00001387](01) 50 push eax
    [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
    [0000138d](05) e8e0f0ffff call 00000472 // call Output
    [00001392](03) 83c408 add esp,+08
    [00001395](02) 33c0 xor eax,eax
    [00001397](01) 5d pop ebp
    [00001398](01) c3 ret
    Size in bytes:(0039) [00001398]

    machine stack stack machine assembly
    address address data code language
    ======== ======== ======== ========= =============
    ...[00001372][0010229e][00000000] 55 push ebp
    ...[00001373][0010229e][00000000] 8bec mov ebp,esp
    ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
    ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
    ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

    Begin Local Halt Decider Simulation Execution Trace Stored at:212352

    // H emulates the first seven instructions of P
    ...[00001352][0021233e][00212342] 55 push ebp // enter P
    ...[00001353][0021233e][00212342] 8bec mov ebp,esp
    ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
    ...[00001358][0021233a][00001352] 50 push eax // push P
    ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
    ...[0000135c][00212336][00001352] 51 push ecx // push P
    ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

    Starting here is where the trace is incomplete. The emulation of the instructions of the inner instance of H are not shown. Also the lines below are not emulated by the top level H. They are emulated by the inner H called by P. So in between each of
    these lines is multiple instructions of the inner H performing the emulation of them.


    // The emulated H emulates the first seven instructions of P
    ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
    ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
    ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
    ...[00001358][0025cd62][00001352] 50 push eax // push P
    ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
    ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
    ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    Here is where H makes its error of aborting too soon. Explanation below: >>>
    Several different confusions (see below).

    If the execution trace of function H() called by function P() shows:
    (1) Function H() is called twice in sequence from the same machine
    address of P().
    (2) With the same parameters to H().
    (3) With no conditional branch or indexed jump instructions in P().

    This condition is not met.
    (1) is proven
    (2) is proven // Third column shows TOS value of P's machine address
    (3) is proven //
    There are branches / jumps in the *program* P contained in the function H that can abort.
    We are not looking for jumps, we are looking for code that can change
    the behavior of P from one invocation to the next.

    And the conditional code of H that checks if its abort criteria is met does *exactly* that.

    It is possible that H can change the behavior of P, yet H does not do
    that until after its input has already correctly matched an infinite
    behavior pattern.

    It is easy to verify that H does not change the behavior of P for the
    first 14 instructions of P.

    The top level H is unable to see that the H called by P will trigger that abort condition if allowed to continue, such as when simulated by a UTM.

    (a) conditional branch or
    (b) indexed jump instructions (where the index can vary)
    The outer H is unable to detect that the inner H will do exactly what the outer H does,
    None of this could possibly show that the simulated P ever reaches its
    "ret" instruction, thus is irrelevant.

    We are not asking:
    [A] Does P stop running?

    We are by the definition of the problem: does an algorithm exist that can detect if *any* arbitrary algorithm will halt when given a particular input.

    No not at all this is false.
    A halt decider must only compute the mapping of its input to an accept
    or reject state based on the actual behavior specified by this input.



    We are asking:
    [B] Does the simulated P reach its "ret" instruction?

    By this definition, any simulator that aborts and returns non-halting is necessarily correct, such as Ha3(N,5)==0.


    The answer is no.

    Because the definition of halting means that a computation completed
    normally and reached is final instruction H would correctly abort its
    simulation of P and return 0.

    And since the computation that H(P,P) is deciding on *by definition* is P(P), and the computation P(P) completes, H is incorrect to abort and return 0.

    A halt decider must only compute the mapping of its input to an accept
    or reject state based on the actual behavior specified by this input.

    It is the case that the correct x86 emulation of the input to H(P,P) by
    H would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
    proved to be correct.


    --
    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 Richard Damon on Sat May 28 11:49:42 2022
    XPost: comp.theory, sci.logic

    On 5/28/2022 11:35 AM, Richard Damon wrote:
    On 5/28/22 12:02 PM, olcott wrote:
    On 5/28/2022 10:29 AM, Richard Damon wrote:

    On 5/28/22 11:05 AM, olcott wrote:
    On 5/28/2022 8:58 AM, Richard Damon wrote:

    On 5/28/22 6:26 AM, olcott wrote:
    On 5/27/2022 7:33 PM, Richard Damon wrote:
    On 5/27/22 7:33 PM, olcott wrote:
    On 5/27/2022 6:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:42, olcott wrote:
    On 5/27/2022 5:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:13, olcott wrote:
    On 5/27/2022 4:41 PM, André G. Isaak wrote:
    On 2022-05-27 15:31, olcott wrote:
    On 5/27/2022 4:21 PM, André G. Isaak wrote:
    On 2022-05-27 14:38, olcott wrote:
    On 5/27/2022 3:06 PM, André G. Isaak wrote:
    On 2022-05-27 13:41, olcott wrote:
    On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
    On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>
    The input to H is NOT a "sequence of >>>>>>>>>>>>>>>>>>>>> configuratios", but the representation of an >>>>>>>>>>>>>>>>>>>>> algorithm and its input.

    The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own >>>>>>>>>>>>>>>>>>>> final state.

    I really don't think you have any idea what terms >>>>>>>>>>>>>>>>>>> like 'represent', 'specify', or 'sequence of >>>>>>>>>>>>>>>>>>> configurations' mean. Richard is perfectly correct. >>>>>>>>>>>>>>>>>>> You, as usual, are not.


    The distinction that I make between represent and >>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents >>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the >>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this >>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior >>>>>>>>>>>>>>>>>> specified by P(P).

    A sequence of configurations means a list of x86 >>>>>>>>>>>>>>>>>> program steps executed or emulated in the order that >>>>>>>>>>>>>>>>>> their source-code specifies.

    Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>>
    And this decidedly is *not* what a halt decider is >>>>>>>>>>>>>>>>> given as its input. It is not given a sequence of state >>>>>>>>>>>>>>>>> transitions. It is given a representation of a >>>>>>>>>>>>>>>>> computation.


    No it is not and you know that it is not. A halt decider >>>>>>>>>>>>>>>> is given a finite string TM description that specifies a >>>>>>>>>>>>>>>> sequence of configurations.

    A TM description and a sequence of configurations are >>>>>>>>>>>>>>> entirely different things (and the former certainly does >>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the >>>>>>>>>>>>>>> other. Make up your mind.

    André


    _Infinite_Loop()
    [000012c2](01)  55              push ebp >>>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp >>>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5 >>>>>>>>>>>>>> [000012c7](01)  5d              pop ebp >>>>>>>>>>>>>> [000012c8](01)  c3              ret
    Size in bytes:(0007) [000012c8]

    So then the above x86 code may specify a game of
    tic-tac-toe and there is no possible way to determine that >>>>>>>>>>>>>> it does not because the x86 source code of a function has >>>>>>>>>>>>>> nothing to do with the sequence of steps of its correct >>>>>>>>>>>>>> simulation.


    That is not a sequence of configurations. It is a piece of >>>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>>> something like this:


    Yes that code specifies this sequence.

    No, it does not. What you have above only generates the
    following *only* if you (a) interpret it as representing x86 >>>>>>>>>>> instructions and (b) actually execute it on an x86 or some >>>>>>>>>>> appropriate emulator.


    Because no one in their right mind would think of doing it >>>>>>>>>> otherwise those ridiculously self-evident facts need not be >>>>>>>>>> stated.

    You are the one who constantly makes much ado about nothing
    about the fact that Turing Machines can ONLY accept finite
    strings as their inputs and object to anyone who suggests that >>>>>>>>> something might compute some function which isn't over strings. >>>>>>>>>
    You don't seem to understand exactly what a finite string is. A >>>>>>>>> finite string is simply a sequence of symbols. Given two
    strings, you can ask questions like which is longer or whether >>>>>>>>> one is a substring or permutation of the other, but not much else. >>>>>>>>>
    That's because neither strings nor the symbols they are
    composed of have any meaning whatsoever. They are just
    sequences of uninterpreted tokens. As soon as you start talking >>>>>>>>> about 'sequences of configurations' or 'numerical values' or >>>>>>>>> anything along those lines you are no longer talking about
    finite strings, but about the entities which those strings
    represent to a particular TM/program.

    Part of designing a TM involves specifying exactly how a string >>>>>>>>> is to be interpreted (however 'ridiculously self-evident' it >>>>>>>>> might seem to you) So yes, they need to be stated.


    If it was not for communication context then every single rule >>>>>>>>>> of grammar would have to be repeated with every sentence and >>>>>>>>>> every definition of every work would have to be repeated over >>>>>>>>>> and over.

    You keep claiming that the input to the decider is a sequence >>>>>>>>>>> of configurations, but that's just plain wrong.

    The input to a decider

    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    A sequence of configirations

    Did you notice that I said SPECFIES this time ???

    But you still haven't provided a coherent definition of what >>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage >>>>>>>>> a few posts ago, but nothing which made this clear. Repeating >>>>>>>>> it over and over again doesn't add any clarity.

    The question originally arose when you objected to the claim >>>>>>>>> that the input to a halt decider represents a computation (or >>>>>>>>> TM description/input string pair) and instead insisted that it >>>>>>>>> specifies a sequence of configurations.


    Yes of course as everyone knows x86 source-code is one of the
    ingredients to a milkshake and because there is a standard
    practice for making milkshakes they already know when and how
    the x86 source-code must be applied to make a milkshake.

    Now it seems like you are trying to claim that a representation >>>>>>>>> of a computation specifies a sequence of configurations, but >>>>>>>>> that doesn't explain why you so vehemently objected

    Your brain is welded in rebuttal mode?

    to the claim that the input to a halt decider represents a
    computation. So clearly you mean something else altogether.

    André


    Because your brain is welded in rebuttal mode you will always
    act like you never know.


    No, YOUR brain is welded in stupid mode. You are unable to make a >>>>>>> clear sentence because you misuse the English language to hide
    your lies.

    It is easily provable that the C function H(P,P)==0 is correct on
    the basis of the fact correct execution trace of the x86
    source-code of input to H(P,P) shows that P would never reach its
    "ret" instruction.

    Again, I say HOW, since the CORRECT emulation of the input to
    H(P,P), as shown by UTM(P,P), H1(P,P), or even P(P) shows that it
    Halts, if H is defined to return 0 from H(P,P).

    Richard is one of the two liars.
    *The actual behavior of P when correctly emulated by H is shown below*


    No, it isn't, because it LIES.

    #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()
    [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]

    _main()
    [00001372](01)  55              push ebp
    [00001373](02)  8bec            mov ebp,esp
    [00001375](05)  6852130000      push 00001352 // push P
    [0000137a](05)  6852130000      push 00001352 // push P
    [0000137f](05)  e81efeffff      call 000011a2 // call H
    [00001384](03)  83c408          add esp,+08
    [00001387](01)  50              push eax
    [00001388](05)  6823040000      push 00000423 // "Input_Halts = " >>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
    [00001392](03)  83c408          add esp,+08
    [00001395](02)  33c0            xor eax,eax
    [00001397](01)  5d              pop ebp
    [00001398](01)  c3              ret
    Size in bytes:(0039) [00001398]

         machine   stack     stack     machine    assembly >>>>      address   address   data      code       language >>>>      ========  ========  ========  =========  =============
    ...[00001372][0010229e][00000000] 55         push ebp
    ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
    ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
    ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
    ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

    Begin Local Halt Decider Simulation   Execution Trace Stored at:212352 >>>>
    // H emulates the first seven instructions of P
    ...[00001352][0021233e][00212342] 55         push ebp      // enter P
    ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
    ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
    ...[00001358][0021233a][00001352] 50         push eax      // push P
    ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
    ...[0000135c][00212336][00001352] 51         push ecx      // push P
    ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

    // The emulated H emulates the first seven instructions of P
    So, the following is NOT an emulation of the P that the top level H
    is emulating, and

    Right.

    thus NOT part of a CORRECT x86 emulation of the program.

    Wrong.

    Just like the first invocation of infinite recursion is the root cause
    of the infinite recursion the first invocation of infinitely nested
    x86 emulation is its root cause.


    Except you don't understand the definitions.

    The second emulation is NOT an emulation by the emulator we are looking
    at (At least not if H is how you have defined it), so can't be just
    called part of it.


    The question is: Would the correct x86 emulation of the input to H(P,P)
    ever reach the "ret" instruction of P?

    An answer of "no" conclusively proves that H(P,P)==0 is correct.

    --
    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 Sat May 28 12:54:41 2022
    XPost: comp.theory, sci.logic, sci.math

    On 5/28/22 12:24 PM, olcott wrote:
    On 5/28/2022 11:06 AM, Dennis Bush wrote:
    On Saturday, May 28, 2022 at 11:48:43 AM UTC-4, olcott wrote:
    On 5/28/2022 10:23 AM, Dennis Bush wrote:
    On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:
    On 5/28/2022 8:58 AM, Richard Damon wrote:

    On 5/28/22 6:26 AM, olcott wrote:
    On 5/27/2022 7:33 PM, Richard Damon wrote:
    On 5/27/22 7:33 PM, olcott wrote:
    On 5/27/2022 6:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:42, olcott wrote:
    On 5/27/2022 5:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:13, olcott wrote:
    On 5/27/2022 4:41 PM, André G. Isaak wrote:
    On 2022-05-27 15:31, olcott wrote:
    On 5/27/2022 4:21 PM, André G. Isaak wrote:
    On 2022-05-27 14:38, olcott wrote:
    On 5/27/2022 3:06 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
    On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
    On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>
    The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>>>>
    The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own >>>>>>>>>>>>>>>>>>>>> final
    state.

    I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' >>>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, >>>>>>>>>>>>>>>>>>>> are not.


    The distinction that I make between represent and >>>>>>>>>>>>>>>>>>> specify
    is that the x86 source-code for P represents P(P) >>>>>>>>>>>>>>>>>>> whereas
    the actual correct x86 emulation of the input to H(P,P) >>>>>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not >>>>>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P). >>>>>>>>>>>>>>>>>>>
    A sequence of configurations means a list of x86 program >>>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their >>>>>>>>>>>>>>>>>>> source-code specifies.

    Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>>>
    And this decidedly is *not* what a halt decider is >>>>>>>>>>>>>>>>>> given as
    its input. It is not given a sequence of state >>>>>>>>>>>>>>>>>> transitions.
    It is given a representation of a computation. >>>>>>>>>>>>>>>>>>

    No it is not and you know that it is not. A halt >>>>>>>>>>>>>>>>> decider is
    given a finite string TM description that specifies a >>>>>>>>>>>>>>>>> sequence of configurations.

    A TM description and a sequence of configurations are >>>>>>>>>>>>>>>> entirely different things (and the former certainly does >>>>>>>>>>>>>>>> not
    'specify' the latter). It's given either one or the other. >>>>>>>>>>>>>>>> Make up your mind.

    André


    _Infinite_Loop()
    [000012c2](01) 55 push ebp
    [000012c3](02) 8bec mov ebp,esp
    [000012c5](02) ebfe jmp 000012c5
    [000012c7](01) 5d pop ebp
    [000012c8](01) c3 ret
    Size in bytes:(0007) [000012c8]

    So then the above x86 code may specify a game of tic-tac-toe >>>>>>>>>>>>>>> and there is no possible way to determine that it does not >>>>>>>>>>>>>>> because the x86 source code of a function has nothing to do >>>>>>>>>>>>>>> with the sequence of steps of its correct simulation. >>>>>>>>>>>>>>

    That is not a sequence of configurations. It is a piece of >>>>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>>>> something like this:


    Yes that code specifies this sequence.

    No, it does not. What you have above only generates the >>>>>>>>>>>> following
    *only* if you (a) interpret it as representing x86 instructions >>>>>>>>>>>> and (b) actually execute it on an x86 or some appropriate >>>>>>>>>>>> emulator.


    Because no one in their right mind would think of doing it >>>>>>>>>>> otherwise those ridiculously self-evident facts need not be >>>>>>>>>>> stated.

    You are the one who constantly makes much ado about nothing about >>>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as >>>>>>>>>> their inputs and object to anyone who suggests that something >>>>>>>>>> might
    compute some function which isn't over strings.

    You don't seem to understand exactly what a finite string is. A >>>>>>>>>> finite string is simply a sequence of symbols. Given two strings, >>>>>>>>>> you can ask questions like which is longer or whether one is a >>>>>>>>>> substring or permutation of the other, but not much else.

    That's because neither strings nor the symbols they are
    composed of
    have any meaning whatsoever. They are just sequences of
    uninterpreted tokens. As soon as you start talking about
    'sequences
    of configurations' or 'numerical values' or anything along those >>>>>>>>>> lines you are no longer talking about finite strings, but
    about the
    entities which those strings represent to a particular
    TM/program.

    Part of designing a TM involves specifying exactly how a
    string is
    to be interpreted (however 'ridiculously self-evident' it might >>>>>>>>>> seem to you) So yes, they need to be stated.


    If it was not for communication context then every single >>>>>>>>>>> rule of
    grammar would have to be repeated with every sentence and every >>>>>>>>>>> definition of every work would have to be repeated over and >>>>>>>>>>> over.

    You keep claiming that the input to the decider is a
    sequence of
    configurations, but that's just plain wrong.

    The input to a decider

    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    A sequence of configirations

    Did you notice that I said SPECFIES this time ???

    But you still haven't provided a coherent definition of what >>>>>>>>>> *you*
    mean by 'specify'. You gave a bit of wishy-washy verbiage a few >>>>>>>>>> posts ago, but nothing which made this clear. Repeating it >>>>>>>>>> over and
    over again doesn't add any clarity.

    The question originally arose when you objected to the claim that >>>>>>>>>> the input to a halt decider represents a computation (or TM >>>>>>>>>> description/input string pair) and instead insisted that it >>>>>>>>>> specifies a sequence of configurations.


    Yes of course as everyone knows x86 source-code is one of the >>>>>>>>> ingredients to a milkshake and because there is a standard
    practice
    for making milkshakes they already know when and how the x86 >>>>>>>>> source-code must be applied to make a milkshake.

    Now it seems like you are trying to claim that a
    representation of
    a computation specifies a sequence of configurations, but that >>>>>>>>>> doesn't explain why you so vehemently objected

    Your brain is welded in rebuttal mode?

    to the claim that the input to a halt decider represents a >>>>>>>>>> computation. So clearly you mean something else altogether. >>>>>>>>>>
    André


    Because your brain is welded in rebuttal mode you will always act >>>>>>>>> like you never know.


    No, YOUR brain is welded in stupid mode. You are unable to make a >>>>>>>> clear sentence because you misuse the English language to hide your >>>>>>>> lies.

    It is easily provable that the C function H(P,P)==0 is correct on >>>>>>> the
    basis of the fact correct execution trace of the x86 source-code of >>>>>>> input to H(P,P) shows that P would never reach its "ret"
    instruction.

    Again, I say HOW, since the CORRECT emulation of the input to
    H(P,P), as
    shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is >>>>>> defined to return 0 from H(P,P).
    Richard is one of the two liars.
    *The actual behavior of P when correctly emulated by H is shown below* >>>>>
    #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()
    [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]

    _main()
    [00001372](01) 55 push ebp
    [00001373](02) 8bec mov ebp,esp
    [00001375](05) 6852130000 push 00001352 // push P
    [0000137a](05) 6852130000 push 00001352 // push P
    [0000137f](05) e81efeffff call 000011a2 // call H
    [00001384](03) 83c408 add esp,+08
    [00001387](01) 50 push eax
    [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
    [0000138d](05) e8e0f0ffff call 00000472 // call Output
    [00001392](03) 83c408 add esp,+08
    [00001395](02) 33c0 xor eax,eax
    [00001397](01) 5d pop ebp
    [00001398](01) c3 ret
    Size in bytes:(0039) [00001398]

    machine stack stack machine assembly
    address address data code language
    ======== ======== ======== ========= =============
    ...[00001372][0010229e][00000000] 55 push ebp
    ...[00001373][0010229e][00000000] 8bec mov ebp,esp
    ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P >>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P >>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H >>>>>
    Begin Local Halt Decider Simulation Execution Trace Stored at:212352 >>>>>
    // H emulates the first seven instructions of P
    ...[00001352][0021233e][00212342] 55 push ebp // enter P
    ...[00001353][0021233e][00212342] 8bec mov ebp,esp
    ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
    ...[00001358][0021233a][00001352] 50 push eax // push P
    ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
    ...[0000135c][00212336][00001352] 51 push ecx // push P
    ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

    Starting here is where the trace is incomplete. The emulation of the
    instructions of the inner instance of H are not shown. Also the
    lines below are not emulated by the top level H. They are emulated
    by the inner H called by P. So in between each of these lines is
    multiple instructions of the inner H performing the emulation of them. >>>>

    // The emulated H emulates the first seven instructions of P
    ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
    ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
    ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
    ...[00001358][0025cd62][00001352] 50 push eax // push P
    ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
    ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
    ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H >>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    Here is where H makes its error of aborting too soon. Explanation
    below:

    Several different confusions (see below).

    If the execution trace of function H() called by function P() shows: >>>>> (1) Function H() is called twice in sequence from the same machine
    address of P().
    (2) With the same parameters to H().
    (3) With no conditional branch or indexed jump instructions in P().

    This condition is not met.
    (1) is proven
    (2) is proven // Third column shows TOS value of P's machine address
    (3) is proven //
    There are branches / jumps in the *program* P contained in the
    function H that can abort.
    We are not looking for jumps, we are looking for code that can change
    the behavior of P from one invocation to the next.

    And the conditional code of H that checks if its abort criteria is met
    does *exactly* that.

    It is possible that H can change the behavior of P, yet H does not do
    that until after its input has already correctly matched an infinite
    behavior pattern.

    It is easy to verify that H does not change the behavior of P for the
    first 14 instructions of P.

    The top level H is unable to see that the H called by P will trigger
    that abort condition if allowed to continue, such as when simulated by
    a UTM.

    (a) conditional branch or
    (b) indexed jump instructions (where the index can vary)
    The outer H is unable to detect that the inner H will do exactly
    what the outer H does,
    None of this could possibly show that the simulated P ever reaches its
    "ret" instruction, thus is irrelevant.

    We are not asking:
    [A] Does P stop running?

    We are by the definition of the problem:  does an algorithm exist that
    can detect if *any* arbitrary algorithm will halt when given a
    particular input.

    No not at all this is false.
    A halt decider must only compute the mapping of its input to an accept
    or reject state based on the actual behavior specified by this input.

    Word Salad.

    A Halt Decider H, given input Wm, the representation of machine M, and w
    the input to that machine, needs to compute the Halting property of M
    applied to w.

    If you want to claim that isn't allowed to be asked, you are DEFINING
    the Halting Theorem to be TRUE, as if you are allowed to even ask the
    question, you can't have a decider decide it.

    Thus, for your "word salad", the "actual behavior speicifed by this
    input" means that H(M,w) needs to see as that actual behavior as M(w),
    by DEFINITION.

    You seem to somehow interprete it as something else, but never actualy
    have DEFINED what you mean by that (as is common with most your arguments.

    You claim things are true by the meaning of words, but all you show is
    that words often don't have precise enough meanings to establish that.





    We are asking:
    [B] Does the simulated P reach its "ret" instruction?

    By this definition, any simulator that aborts and returns non-halting
    is necessarily correct, such as Ha3(N,5)==0.


    The answer is no.

    Because the definition of halting means that a computation completed
    normally and reached is final instruction H would correctly abort its
    simulation of P and return 0.

    And since the computation that H(P,P) is deciding on *by definition*
    is P(P), and the computation P(P) completes, H is incorrect to abort
    and return 0.

    A halt decider must only compute the mapping of its input to an accept
    or reject state based on the actual behavior specified by this input.

    WORD SALAD


    It is the case that the correct x86 emulation of the input to H(P,P) by
    H would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
    proved to be correct.



    Nope, the CORRECT x86 emulation of the input th H(P,P) is the emulation
    of P(P) which is shown (even by you) to Halt.

    Unless you want to actually try to define some other reasonable meaning
    for your words, and show that they actually can apply, you are just
    spouting falsehoods.

    It seems your natural language is the Lie.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sat May 28 13:06:05 2022
    XPost: comp.theory, sci.logic

    On 5/28/22 12:49 PM, olcott wrote:
    On 5/28/2022 11:35 AM, Richard Damon wrote:
    On 5/28/22 12:02 PM, olcott wrote:
    On 5/28/2022 10:29 AM, Richard Damon wrote:

    On 5/28/22 11:05 AM, olcott wrote:
    On 5/28/2022 8:58 AM, Richard Damon wrote:

    On 5/28/22 6:26 AM, olcott wrote:
    On 5/27/2022 7:33 PM, Richard Damon wrote:
    On 5/27/22 7:33 PM, olcott wrote:
    On 5/27/2022 6:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:42, olcott wrote:
    On 5/27/2022 5:26 PM, André G. Isaak wrote:
    On 2022-05-27 16:13, olcott wrote:
    On 5/27/2022 4:41 PM, André G. Isaak wrote:
    On 2022-05-27 15:31, olcott wrote:
    On 5/27/2022 4:21 PM, André G. Isaak wrote:
    On 2022-05-27 14:38, olcott wrote:
    On 5/27/2022 3:06 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
    On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
    On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>
    The input to H is NOT a "sequence of >>>>>>>>>>>>>>>>>>>>>> configuratios", but the representation of an >>>>>>>>>>>>>>>>>>>>>> algorithm and its input.

    The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own >>>>>>>>>>>>>>>>>>>>> final state.

    I really don't think you have any idea what terms >>>>>>>>>>>>>>>>>>>> like 'represent', 'specify', or 'sequence of >>>>>>>>>>>>>>>>>>>> configurations' mean. Richard is perfectly correct. >>>>>>>>>>>>>>>>>>>> You, as usual, are not.


    The distinction that I make between represent and >>>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents >>>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the >>>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this >>>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior >>>>>>>>>>>>>>>>>>> specified by P(P).

    A sequence of configurations means a list of x86 >>>>>>>>>>>>>>>>>>> program steps executed or emulated in the order that >>>>>>>>>>>>>>>>>>> their source-code specifies.

    Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>>>
    And this decidedly is *not* what a halt decider is >>>>>>>>>>>>>>>>>> given as its input. It is not given a sequence of >>>>>>>>>>>>>>>>>> state transitions. It is given a representation of a >>>>>>>>>>>>>>>>>> computation.


    No it is not and you know that it is not. A halt >>>>>>>>>>>>>>>>> decider is given a finite string TM description that >>>>>>>>>>>>>>>>> specifies a sequence of configurations.

    A TM description and a sequence of configurations are >>>>>>>>>>>>>>>> entirely different things (and the former certainly does >>>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the >>>>>>>>>>>>>>>> other. Make up your mind.

    André


    _Infinite_Loop()
    [000012c2](01)  55              push ebp >>>>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp >>>>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5 >>>>>>>>>>>>>>> [000012c7](01)  5d              pop ebp >>>>>>>>>>>>>>> [000012c8](01)  c3              ret >>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]

    So then the above x86 code may specify a game of >>>>>>>>>>>>>>> tic-tac-toe and there is no possible way to determine >>>>>>>>>>>>>>> that it does not because the x86 source code of a >>>>>>>>>>>>>>> function has nothing to do with the sequence of steps of >>>>>>>>>>>>>>> its correct simulation.


    That is not a sequence of configurations. It is a piece of >>>>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>>>> something like this:


    Yes that code specifies this sequence.

    No, it does not. What you have above only generates the >>>>>>>>>>>> following *only* if you (a) interpret it as representing x86 >>>>>>>>>>>> instructions and (b) actually execute it on an x86 or some >>>>>>>>>>>> appropriate emulator.


    Because no one in their right mind would think of doing it >>>>>>>>>>> otherwise those ridiculously self-evident facts need not be >>>>>>>>>>> stated.

    You are the one who constantly makes much ado about nothing >>>>>>>>>> about the fact that Turing Machines can ONLY accept finite >>>>>>>>>> strings as their inputs and object to anyone who suggests that >>>>>>>>>> something might compute some function which isn't over strings. >>>>>>>>>>
    You don't seem to understand exactly what a finite string is. >>>>>>>>>> A finite string is simply a sequence of symbols. Given two >>>>>>>>>> strings, you can ask questions like which is longer or whether >>>>>>>>>> one is a substring or permutation of the other, but not much >>>>>>>>>> else.

    That's because neither strings nor the symbols they are
    composed of have any meaning whatsoever. They are just
    sequences of uninterpreted tokens. As soon as you start
    talking about 'sequences of configurations' or 'numerical
    values' or anything along those lines you are no longer
    talking about finite strings, but about the entities which >>>>>>>>>> those strings represent to a particular TM/program.

    Part of designing a TM involves specifying exactly how a
    string is to be interpreted (however 'ridiculously
    self-evident' it might seem to you) So yes, they need to be >>>>>>>>>> stated.


    If it was not for communication context then every single >>>>>>>>>>> rule of grammar would have to be repeated with every sentence >>>>>>>>>>> and every definition of every work would have to be repeated >>>>>>>>>>> over and over.

    You keep claiming that the input to the decider is a
    sequence of configurations, but that's just plain wrong. >>>>>>>>>>>
    The input to a decider

    SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
    A sequence of configirations

    Did you notice that I said SPECFIES this time ???

    But you still haven't provided a coherent definition of what >>>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy
    verbiage a few posts ago, but nothing which made this clear. >>>>>>>>>> Repeating it over and over again doesn't add any clarity.

    The question originally arose when you objected to the claim >>>>>>>>>> that the input to a halt decider represents a computation (or >>>>>>>>>> TM description/input string pair) and instead insisted that it >>>>>>>>>> specifies a sequence of configurations.


    Yes of course as everyone knows x86 source-code is one of the >>>>>>>>> ingredients to a milkshake and because there is a standard
    practice for making milkshakes they already know when and how >>>>>>>>> the x86 source-code must be applied to make a milkshake.

    Now it seems like you are trying to claim that a
    representation of a computation specifies a sequence of
    configurations, but that doesn't explain why you so vehemently >>>>>>>>>> objected

    Your brain is welded in rebuttal mode?

    to the claim that the input to a halt decider represents a >>>>>>>>>> computation. So clearly you mean something else altogether. >>>>>>>>>>
    André


    Because your brain is welded in rebuttal mode you will always >>>>>>>>> act like you never know.


    No, YOUR brain is welded in stupid mode. You are unable to make >>>>>>>> a clear sentence because you misuse the English language to hide >>>>>>>> your lies.

    It is easily provable that the C function H(P,P)==0 is correct on >>>>>>> the basis of the fact correct execution trace of the x86
    source-code of input to H(P,P) shows that P would never reach its >>>>>>> "ret" instruction.

    Again, I say HOW, since the CORRECT emulation of the input to
    H(P,P), as shown by UTM(P,P), H1(P,P), or even P(P) shows that it
    Halts, if H is defined to return 0 from H(P,P).

    Richard is one of the two liars.
    *The actual behavior of P when correctly emulated by H is shown below* >>>>

    No, it isn't, because it LIES.

    #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()
    [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]

    _main()
    [00001372](01)  55              push ebp
    [00001373](02)  8bec            mov ebp,esp
    [00001375](05)  6852130000      push 00001352 // push P
    [0000137a](05)  6852130000      push 00001352 // push P
    [0000137f](05)  e81efeffff      call 000011a2 // call H
    [00001384](03)  83c408          add esp,+08
    [00001387](01)  50              push eax
    [00001388](05)  6823040000      push 00000423 // "Input_Halts = " >>>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
    [00001392](03)  83c408          add esp,+08
    [00001395](02)  33c0            xor eax,eax
    [00001397](01)  5d              pop ebp
    [00001398](01)  c3              ret
    Size in bytes:(0039) [00001398]

         machine   stack     stack     machine    assembly >>>>>      address   address   data      code       language >>>>>      ========  ========  ========  =========  =============
    ...[00001372][0010229e][00000000] 55         push ebp
    ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
    ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P >>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P >>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H >>>>>
    Begin Local Halt Decider Simulation   Execution Trace Stored at:212352 >>>>>
    // H emulates the first seven instructions of P
    ...[00001352][0021233e][00212342] 55         push ebp      // enter P
    ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
    ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
    ...[00001358][0021233a][00001352] 50         push eax      // push P
    ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
    ...[0000135c][00212336][00001352] 51         push ecx      // push P
    ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H >>>>>
    // The emulated H emulates the first seven instructions of P
    So, the following is NOT an emulation of the P that the top level H
    is emulating, and

    Right.

    thus NOT part of a CORRECT x86 emulation of the program.

    Wrong.

    Just like the first invocation of infinite recursion is the root
    cause of the infinite recursion the first invocation of infinitely
    nested x86 emulation is its root cause.


    Except you don't understand the definitions.

    The second emulation is NOT an emulation by the emulator we are
    looking at (At least not if H is how you have defined it), so can't be
    just called part of it.


    The question is: Would the correct x86 emulation of the input to H(P,P)
    ever reach the "ret" instruction of P?

    An answer of "no" conclusively proves that H(P,P)==0 is correct.


    Change in wording again.

    Yes, the CORRECT Question is "Would the correct x86 emulation of the
    inptu to H(P,P) ever reach the "ret" intstuction of P?"

    And the anwer is YES, if H(P,P) aborts its simulation and returns the
    value 0.

    Thus, the answer H(P,P) == 0 can NOT be correct.


    Remember, H is NOT the defintion of the CORRECT simulation. Correct
    simulation is what reproduces the exact behavior of the program the
    input represents. That is something that does the same as P(P).

    Since we are asking what it the corrrect answer if H(P,P) == 0, to see
    if it is correct, it is trivial to analyse P(P) to see that it will halt.

    We can also emulate it, as you have provided below, and see that a
    CORRECT emulation will halt.

    The ONLY way this argument fails is if H(P,P) doesn't always return the
    same value, but then H fails to meet the requirements to be a decider,
    namely that of being an actual computation, so, since it has been
    stipulated that H meets the requirements, we don't need to worry about
    that case.



    On 4/27/21 12:55 AM, olcott wrote:
    Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
    void H_Hat(u32 P)
    {
    u32 Input_Halts = Halts(P, P);
    if (Input_Halts)
    HERE: goto HERE;
    }


    int main()
    {
    H_Hat((u32)H_Hat);
    }


    _H_Hat()
    [00000b98](01) 55 push ebp
    [00000b99](02) 8bec mov ebp,esp

    [00000b9b](01) 51 push ecx
    [00000b9c](03) 8b4508 mov eax,[ebp+08]
    [00000b9f](01) 50 push eax
    [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
    [00000ba3](01) 51 push ecx
    [00000ba4](05) e88ffdffff call 00000938
    [00000ba9](03) 83c408 add esp,+08
    [00000bac](03) 8945fc mov [ebp-04],eax
    [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
    [00000bb3](02) 7402 jz 00000bb7
    [00000bb5](02) ebfe jmp 00000bb5
    [00000bb7](02) 8be5 mov esp,ebp
    [00000bb9](01) 5d pop ebp
    [00000bba](01) c3 ret
    Size in bytes:(0035) [00000bba]

    _main()
    [00000bc8](01) 55 push ebp
    [00000bc9](02) 8bec mov ebp,esp
    [00000bcb](05) 68980b0000 push 00000b98
    [00000bd0](05) e8c3ffffff call 00000b98
    [00000bd5](03) 83c404 add esp,+04
    [00000bd8](02) 33c0 xor eax,eax
    [00000bda](01) 5d pop ebp
    [00000bdb](01) c3 ret
    Size in bytes:(0020) [00000bdb]

    ===============================
    ...[00000bc8][001015d4][00000000](01) 55 push ebp ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98 ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98 ...[00000b98][001015c8][001015d4](01) 55 push ebp ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp ...[00000b9b][001015c4][00000000](01) 51 push ecx ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][001015c0][00000b98](01) 50 push eax ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][001015bc][00000b98](01) 51 push ecx ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
    Begin Local Halt Decider Simulation at Machine Address:b98 ...[00000b98][00211674][00211678](01) 55 push ebp ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp ...[00000b9b][00211670][00201644](01) 51 push ecx ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][0021166c][00000b98](01) 50 push eax ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][00211668][00000b98](01) 51 push ecx ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938 ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp ...[00000b9b][0025c098][0024c06c](01) 51 push ecx ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][0025c094][00000b98](01) 50 push eax ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][0025c090][00000b98](01) 51 push ecx ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    Above decision was from the call the Halts inside H_Hat, deciding that H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is processed below:

    ...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08 ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00 ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7 ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp ...[00000bba][001015d0][00000b98](01) c3 ret ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04 ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax ...[00000bda][001015d8][00100000](01) 5d pop ebp ...[00000bdb][001015dc][00000098](01) c3 ret

    SEE IT HALTED!

    Number_of_User_Instructions(39)
    Number of Instructions Executed(26567)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to All on Sat May 28 13:26:25 2022
    XPost: comp.theory, sci.logic, sci.math

    On 5/28/2022 1:10 PM, André G. Isaak wrote:
    On 2022-05-28 10:24, olcott wrote:
    On 5/28/2022 11:06 AM, Dennis Bush wrote:

    And since the computation that H(P,P) is deciding on *by definition*
    is P(P), and the computation P(P) completes, H is incorrect to abort
    and return 0.

    A halt decider must only compute the mapping of its input to an accept
    or reject state based on the actual behavior specified by this input.

    And what exactly is the above supposed to mean? You still haven't
    provided a coherent definition of what you mean by 'specified'. What
    does it mean for an input string to specify a behaviour?

    André


    In other words when I prove what I mean by "specified" 100 times the
    fact that you always make sure to ignore what I said is equivalent to me
    having never said anything about it.

    The behavior specified by an input is the execution trace derived by the correct x86 emulation of this input by its simulating halt decider.

    This proves that H(P,P)==0 and H1(P,P)==1.

    --
    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 All on Sat May 28 14:27:59 2022
    XPost: comp.theory, sci.logic, sci.math

    On 5/28/2022 2:21 PM, André G. Isaak wrote:
    On 2022-05-28 12:52, olcott wrote:
    On 5/28/2022 1:38 PM, André G. Isaak wrote:
    On 2022-05-28 12:26, olcott wrote:
    On 5/28/2022 1:10 PM, André G. Isaak wrote:
    On 2022-05-28 10:24, olcott wrote:
    On 5/28/2022 11:06 AM, Dennis Bush wrote:

    And since the computation that H(P,P) is deciding on *by
    definition* is P(P), and the computation P(P) completes, H is
    incorrect to abort and return 0.

    A halt decider must only compute the mapping of its input to an
    accept or reject state based on the actual behavior specified by
    this input.

    And what exactly is the above supposed to mean? You still haven't
    provided a coherent definition of what you mean by 'specified'.
    What does it mean for an input string to specify a behaviour?

    André


    In other words when I prove what I mean by "specified" 100 times the
    fact that you always make sure to ignore what I said is equivalent
    to me having never said anything about it.

    You can't "prove" what you mean by something. You define what
    something is intended to mean. And so far you haven't provided a
    definition for 'specify'. When asked you've either hurled insults or
    given strange analogies involving milkshakes.

    The behavior specified by an input is the execution trace derived by
    the correct x86 emulation of this input by its simulating halt decider. >>>
    And how exactly do you define 'correct x86 emulation'?

    I have told you this many times. Why do you persistently ignore what I
    say and then claim that I said nothing?

    No, you have not. When asked in the past you've given vaguely worded 'explanations' or unclear examples, but you've never provided anything resembling a definition. A definition would take the form:

    A program S correctly emulates an input M, I if and only if ...
    *THIS IS THE CORRECT WAY TO ANALYZE IT*
    The sequence of instructions that program S emulates is the same
    sequence that the x86 machine language input M specifies when it is
    being emulated by S.

    *THIS IS THE LYING CHEATING WAY TO ANALYZE IT*
    The sequence of instructions that program S emulates is the same
    sequence that the x86 machine language input M specifies when it is
    being emulated by R.




    --
    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 Sat May 28 16:53:00 2022
    XPost: comp.theory, sci.logic, sci.math

    On 5/28/22 3:27 PM, olcott wrote:
    On 5/28/2022 2:21 PM, André G. Isaak wrote:
    On 2022-05-28 12:52, olcott wrote:
    On 5/28/2022 1:38 PM, André G. Isaak wrote:
    On 2022-05-28 12:26, olcott wrote:
    On 5/28/2022 1:10 PM, André G. Isaak wrote:
    On 2022-05-28 10:24, olcott wrote:
    On 5/28/2022 11:06 AM, Dennis Bush wrote:

    And since the computation that H(P,P) is deciding on *by
    definition* is P(P), and the computation P(P) completes, H is
    incorrect to abort and return 0.

    A halt decider must only compute the mapping of its input to an
    accept or reject state based on the actual behavior specified by >>>>>>> this input.

    And what exactly is the above supposed to mean? You still haven't
    provided a coherent definition of what you mean by 'specified'.
    What does it mean for an input string to specify a behaviour?

    André


    In other words when I prove what I mean by "specified" 100 times
    the fact that you always make sure to ignore what I said is
    equivalent to me having never said anything about it.

    You can't "prove" what you mean by something. You define what
    something is intended to mean. And so far you haven't provided a
    definition for 'specify'. When asked you've either hurled insults or
    given strange analogies involving milkshakes.

    The behavior specified by an input is the execution trace derived
    by the correct x86 emulation of this input by its simulating halt
    decider.

    And how exactly do you define 'correct x86 emulation'?

    I have told you this many times. Why do you persistently ignore what
    I say and then claim that I said nothing?

    No, you have not. When asked in the past you've given vaguely worded
    'explanations' or unclear examples, but you've never provided anything
    resembling a definition. A definition would take the form:

    A program S correctly emulates an input M, I if and only if ...
    *THIS IS THE CORRECT WAY TO ANALYZE IT*
    The sequence of instructions that program S emulates is the same
    sequence that the x86 machine language input M specifies when it is
    being emulated by S.

    *THIS IS THE LYING CHEATING WAY TO ANALYZE IT*
    The sequence of instructions that program S emulates is the same
    sequence that the x86 machine language input M specifies when it is
    being emulated by R.



    So CORRECTNESS is relative to the one doing it?

    The ACTUAL correct answer the sequence of instructions that would occur
    from a simulator that doesn't stop until the program ends. Yes, this
    means that the correct simulation of a non-halting computation is
    non-halting and generates an infinite sequence.


    So, If S decided to stop after one step, its simulation would still be
    correct?

    That seems to be what you mean.

    That means almost ALL programs can be correctly decided as "Non-Halting"
    by a dumb enough.

    That definition makes your definition of the halting problem incorrect,
    as the Halting behavior of a Compuation is NOT a funciton of the decider
    that is deciding it.

    Thus you are not working on the halting problem but just your POOP.

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