1. Forum
  2. Usenet
  3. COMP.THEORY

  • Re: behavior and description --- Richard still only has pure bluster

    From olcott@21:1/5 to Richard Damon on Tue Aug 6 22:47:08 2024
    On 8/6/2024 10:21 PM, Richard Damon wrote:
    On 8/6/24 11:10 PM, olcott wrote:
    On 8/6/2024 10:00 PM, Richard Damon wrote:
    On 8/6/24 10:49 PM, olcott wrote:
    On 8/6/2024 9:27 PM, Richard Damon wrote:
    On 8/6/24 9:48 PM, olcott wrote:
    On 8/6/2024 8:38 PM, Richard Damon wrote:
    On 8/6/24 1:16 PM, olcott wrote:
    On 8/6/2024 12:02 PM, joes wrote:
    Am Tue, 06 Aug 2024 09:43:30 -0500 schrieb olcott:
    Understanding that DDD correctly simulated by HHH cannot
    possibly reach
    its own "return" instruction is a mandatory prerequisite to >>>>>>>>>> further
    discussion.

    There is nothing to discuss after agreeing with your conclusion. >>>>>>>>>
    Everyone remains convinced that HHH must report on the
    behavior of the
    computation that itself is contained within and not the
    behavior that
    its finite string input specifies.

    The construction is not recursive if the description does not >>>>>>>>> describe
    the surrounding computation. And that behaviour cannot depend >>>>>>>>> on the
    decider, as they should all give the same answer.


    That is far too vague.

    DDD correctly emulated by HHH according to the semantics
    of the x86 programming language specifies a single exact
    sequence of state changes. None of these state changes
    ends up at the x86 machine language address of the "ret"
    instruction of DDD.


    Which would be meaningful if HHH actual did a correct emulation
    of the

    HHH does emulate the exact sequence that the machine code
    of DDD specifies. This has been conclusively proven by
    the execution traces that the two instances of HHH provide.

    Nope, because it didn't emulate the call instruction properly.


    It is proved that it does emulate the call instruction
    properly by the correct execution trace of the second
    DDD derived by the second HHH.

    Nope, just proves you don't know what you are talking about.


    Because your rebuttals have always been pure bluster

    No, YOUR rebuttal have been pure bluster that have avoided answering my challenges, thus effectively ADMITTING that you arte just a liar.

    you have only used double-talk and misdirection to dodge
    pointing out any mistake in the following:

    How about the trace that HHH generates shouldn't start with the code of
    main, since that isn't what HHH starts simulating, thus your claims
    about the trace generate by HHH can not be supported by something elses trace.


    That is a very ignorant thing to say.

    Second, the CORRECT emulation of a "call" instruciton should show the instruction of the routine called.


    The extra 200 pages prove to be too confusing. The
    fact that after DDD calls HHH we do get the correct
    execution trace that would be derived from this call
    proves that the second HHH was called.

    I will highlight all of the code so that you
    can see the each instruction both HHH are shown
    and both DDD are shown. I will use four different
    colors.

    It really have already been 100% totally proven in
    that after DDD calls HHH we to get the correct
    execution trace of DDD emulated by this second HHH

    Thus, a "Call 000015d2" *MUST* be followed by the instruction AT
    000015d2, and not "Begin Local Halt Decider Simulation"

    Since you have just been repeating this smae ERROR over and over, you
    are just proving that you just don't care about the truth, but are just repeating your same LIES over and over and over, securing your place in Gehenna.

    _DDD()
    [00002172] 55         push ebp      ; housekeeping
    [00002173] 8bec       mov ebp,esp   ; housekeeping
    [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]

    _main()
    [00002192] 55         push ebp
    [00002193] 8bec       mov ebp,esp
    [00002195] 6872210000 push 00002172 ; push DDD
    [0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
    [0000219f] 83c404     add esp,+04
    [000021a2] 50         push eax
    [000021a3] 6843070000 push 00000743
    [000021a8] e8b5e5ffff call 00000762
    [000021ad] 83c408     add esp,+08
    [000021b0] 33c0       xor eax,eax
    [000021b2] 5d         pop ebp
    [000021b3] c3         ret
    Size in bytes:(0034) [000021b3]

      machine   stack     stack     machine    assembly
      address   address   data      code       language
      ========  ========  ========  =========  =============
    [00002192][00103820][00000000] 55         push ebp
    [00002193][00103820][00000000] 8bec       mov ebp,esp
    [00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD
    [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)
    New slave_stack at:1038c4

    Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc
    [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
    [00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
    [00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
    [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
    New slave_stack at:14e2ec

    This execution trace proves that the second HHH did
    emulate the second DDD correctly:

    [00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
    [00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
    [00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
    [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    [0000219f][00103820][00000000] 83c404     add esp,+04
    [000021a2][0010381c][00000000] 50         push eax
    [000021a3][00103818][00000743] 6843070000 push 00000743
    [000021a8][00103818][00000743] e8b5e5ffff call 00000762
    Input_Halts = 0
    [000021ad][00103820][00000000] 83c408     add esp,+08
    [000021b0][00103820][00000000] 33c0       xor eax,eax
    [000021b2][00103824][00000018] 5d         pop ebp
    [000021b3][00103828][00000000] c3         ret
    Number of Instructions Executed(10069) == 150 Pages

    *I had no idea that Mike was doing this same thing*

    The former editor in chief of CASM did acknowledge
    this to me. He said that was why he couldn't understand
    what I was saying after many email exchanges.


    My guess is he couldn't believe someone could be so stupid.

    Not at all he sponsored me on https://arxiv.org/


    --
    Copyright 2024 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 Wed Aug 7 07:25:50 2024
    On 8/6/24 11:47 PM, olcott wrote:
    On 8/6/2024 10:21 PM, Richard Damon wrote:
    On 8/6/24 11:10 PM, olcott wrote:
    On 8/6/2024 10:00 PM, Richard Damon wrote:
    On 8/6/24 10:49 PM, olcott wrote:
    On 8/6/2024 9:27 PM, Richard Damon wrote:
    On 8/6/24 9:48 PM, olcott wrote:
    On 8/6/2024 8:38 PM, Richard Damon wrote:
    On 8/6/24 1:16 PM, olcott wrote:
    On 8/6/2024 12:02 PM, joes wrote:
    Am Tue, 06 Aug 2024 09:43:30 -0500 schrieb olcott:
    Understanding that DDD correctly simulated by HHH cannot >>>>>>>>>>> possibly reach
    its own "return" instruction is a mandatory prerequisite to >>>>>>>>>>> further
    discussion.

    There is nothing to discuss after agreeing with your conclusion. >>>>>>>>>>
    Everyone remains convinced that HHH must report on the
    behavior of the
    computation that itself is contained within and not the
    behavior that
    its finite string input specifies.

    The construction is not recursive if the description does not >>>>>>>>>> describe
    the surrounding computation. And that behaviour cannot depend >>>>>>>>>> on the
    decider, as they should all give the same answer.


    That is far too vague.

    DDD correctly emulated by HHH according to the semantics
    of the x86 programming language specifies a single exact
    sequence of state changes. None of these state changes
    ends up at the x86 machine language address of the "ret"
    instruction of DDD.


    Which would be meaningful if HHH actual did a correct emulation >>>>>>>> of the

    HHH does emulate the exact sequence that the machine code
    of DDD specifies. This has been conclusively proven by
    the execution traces that the two instances of HHH provide.

    Nope, because it didn't emulate the call instruction properly.


    It is proved that it does emulate the call instruction
    properly by the correct execution trace of the second
    DDD derived by the second HHH.

    Nope, just proves you don't know what you are talking about.


    Because your rebuttals have always been pure bluster

    No, YOUR rebuttal have been pure bluster that have avoided answering
    my challenges, thus effectively ADMITTING that you arte just a liar.

    you have only used double-talk and misdirection to dodge
    pointing out any mistake in the following:

    How about the trace that HHH generates shouldn't start with the code
    of main, since that isn't what HHH starts simulating, thus your claims
    about the trace generate by HHH can not be supported by something
    elses trace.


    That is a very ignorant thing to say.

    NO, it is the truth.


    Second, the CORRECT emulation of a "call" instruciton should show the
    instruction of the routine called.


    The extra 200 pages prove to be too confusing. The
    fact that after DDD calls HHH we do get the correct
    execution trace that would be derived from this call
    proves that the second HHH was called.

    Nope, they show you wrong.

    HOW can the emulation that HHH is doing show code that HHH doesn't look at?

    Your failure to answer (may times from the past) just prove that you
    KNOW that you have been lying, but don't want to face it.

    Sorry, you are just proving your stupidity


    I will highlight all of the code so that you
    can see the each instruction both HHH are shown
    and both DDD are shown. I will use four different
    colors.

    Since the trace isn't the right trace, that doesn't mean anything.

    And, where are the colors, you said there would be colors.

    Did you not know that this group is text only?


    It really have already been 100% totally proven in
    that after DDD calls HHH we to get the correct
    execution trace of DDD emulated by this second HHH

    Thus, a "Call 000015d2" *MUST* be followed by the instruction AT
    000015d2, and not "Begin Local Halt Decider Simulation"

    Since you have just been repeating this smae ERROR over and over, you
    are just proving that you just don't care about the truth, but are
    just repeating your same LIES over and over and over, securing your
    place in Gehenna.

    _DDD()
    [00002172] 55         push ebp      ; housekeeping
    [00002173] 8bec       mov ebp,esp   ; housekeeping
    [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]

    _main()
    [00002192] 55         push ebp
    [00002193] 8bec       mov ebp,esp
    [00002195] 6872210000 push 00002172 ; push DDD
    [0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
    [0000219f] 83c404     add esp,+04
    [000021a2] 50         push eax
    [000021a3] 6843070000 push 00000743
    [000021a8] e8b5e5ffff call 00000762
    [000021ad] 83c408     add esp,+08
    [000021b0] 33c0       xor eax,eax
    [000021b2] 5d         pop ebp
    [000021b3] c3         ret
    Size in bytes:(0034) [000021b3]

      machine   stack     stack     machine    assembly
      address   address   data      code       language
      ========  ========  ========  =========  =============
    [00002192][00103820][00000000] 55         push ebp
    [00002193][00103820][00000000] 8bec       mov ebp,esp
    [00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD
    [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)
    New slave_stack at:1038c4

    Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc >>> [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
    [00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
    [00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
    [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
    New slave_stack at:14e2ec

    This execution trace proves that the second HHH did
    emulate the second DDD correctly:


    Nope, where is the fact that that either HHH has the power to stop any
    of this from happening by aborting there simulation of it?

    Omitting that conditionality makes the trace just an incorrect emulation
    by any defintion.

    The fact that it doesn't show the code of HHH, makes it clearly
    incorrect by the definition of emulation per the x86 langugage, which
    means higher abstractions are not allowed.

    Sorry you are just proving your stupidity.


    [00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
    [00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
    [00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
    [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    And is incorrect in its conclusion because is shows that the HHH that it
    is emulating WILL doe the same thing, and thus the inut will be HALTING


    [0000219f][00103820][00000000] 83c404     add esp,+04
    [000021a2][0010381c][00000000] 50         push eax
    [000021a3][00103818][00000743] 6843070000 push 00000743
    [000021a8][00103818][00000743] e8b5e5ffff call 00000762
    Input_Halts = 0
    [000021ad][00103820][00000000] 83c408     add esp,+08
    [000021b0][00103820][00000000] 33c0       xor eax,eax
    [000021b2][00103824][00000018] 5d         pop ebp
    [000021b3][00103828][00000000] c3         ret
    Number of Instructions Executed(10069) == 150 Pages

    *I had no idea that Mike was doing this same thing*

    The former editor in chief of CASM did acknowledge
    this to me. He said that was why he couldn't understand
    what I was saying after many email exchanges.


    My guess is he couldn't believe someone could be so stupid.

    Not at all he sponsored me on https://arxiv.org/



    So? You don't understand how little that means.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Wed Aug 7 07:59:06 2024
    On 8/7/2024 6:25 AM, Richard Damon wrote:
    On 8/6/24 11:47 PM, olcott wrote:
    On 8/6/2024 10:21 PM, Richard Damon wrote:
    On 8/6/24 11:10 PM, olcott wrote:
    On 8/6/2024 10:00 PM, Richard Damon wrote:
    On 8/6/24 10:49 PM, olcott wrote:
    On 8/6/2024 9:27 PM, Richard Damon wrote:
    On 8/6/24 9:48 PM, olcott wrote:
    On 8/6/2024 8:38 PM, Richard Damon wrote:
    On 8/6/24 1:16 PM, olcott wrote:
    On 8/6/2024 12:02 PM, joes wrote:
    Am Tue, 06 Aug 2024 09:43:30 -0500 schrieb olcott:
    Understanding that DDD correctly simulated by HHH cannot >>>>>>>>>>>> possibly reach
    its own "return" instruction is a mandatory prerequisite to >>>>>>>>>>>> further
    discussion.

    There is nothing to discuss after agreeing with your conclusion. >>>>>>>>>>>
    Everyone remains convinced that HHH must report on the >>>>>>>>>>>> behavior of the
    computation that itself is contained within and not the >>>>>>>>>>>> behavior that
    its finite string input specifies.

    The construction is not recursive if the description does not >>>>>>>>>>> describe
    the surrounding computation. And that behaviour cannot depend >>>>>>>>>>> on the
    decider, as they should all give the same answer.


    That is far too vague.

    DDD correctly emulated by HHH according to the semantics
    of the x86 programming language specifies a single exact
    sequence of state changes. None of these state changes
    ends up at the x86 machine language address of the "ret"
    instruction of DDD.


    Which would be meaningful if HHH actual did a correct emulation >>>>>>>>> of the

    HHH does emulate the exact sequence that the machine code
    of DDD specifies. This has been conclusively proven by
    the execution traces that the two instances of HHH provide.

    Nope, because it didn't emulate the call instruction properly.


    It is proved that it does emulate the call instruction
    properly by the correct execution trace of the second
    DDD derived by the second HHH.

    Nope, just proves you don't know what you are talking about.


    Because your rebuttals have always been pure bluster

    No, YOUR rebuttal have been pure bluster that have avoided answering
    my challenges, thus effectively ADMITTING that you arte just a liar.

    you have only used double-talk and misdirection to dodge
    pointing out any mistake in the following:

    How about the trace that HHH generates shouldn't start with the code
    of main, since that isn't what HHH starts simulating, thus your
    claims about the trace generate by HHH can not be supported by
    something elses trace.


    That is a very ignorant thing to say.

    NO, it is the truth.


    Second, the CORRECT emulation of a "call" instruciton should show the
    instruction of the routine called.


    The extra 200 pages prove to be too confusing. The
    fact that after DDD calls HHH we do get the correct
    execution trace that would be derived from this call
    proves that the second HHH was called.

    Nope, they show you wrong.

    HOW can the emulation that HHH is doing show code that HHH doesn't look at?

    Your failure to answer (may times from the past) just prove that you
    KNOW that you have been lying, but don't want to face it.

    Sorry, you are just proving your stupidity


    I will highlight all of the code so that you
    can see the each instruction both HHH are shown
    and both DDD are shown. I will use four different
    colors.

    Since the trace isn't the right trace, that doesn't mean anything.

    And, where are the colors, you said there would be colors.

    Did you not know that this group is text only?


    It really have already been 100% totally proven in
    that after DDD calls HHH we to get the correct
    execution trace of DDD emulated by this second HHH

    Thus, a "Call 000015d2" *MUST* be followed by the instruction AT
    000015d2, and not "Begin Local Halt Decider Simulation"

    Since you have just been repeating this smae ERROR over and over, you
    are just proving that you just don't care about the truth, but are
    just repeating your same LIES over and over and over, securing your
    place in Gehenna.

    _DDD()
    [00002172] 55         push ebp      ; housekeeping
    [00002173] 8bec       mov ebp,esp   ; housekeeping
    [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]

    _main()
    [00002192] 55         push ebp
    [00002193] 8bec       mov ebp,esp
    [00002195] 6872210000 push 00002172 ; push DDD
    [0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
    [0000219f] 83c404     add esp,+04
    [000021a2] 50         push eax
    [000021a3] 6843070000 push 00000743
    [000021a8] e8b5e5ffff call 00000762
    [000021ad] 83c408     add esp,+08
    [000021b0] 33c0       xor eax,eax
    [000021b2] 5d         pop ebp
    [000021b3] c3         ret
    Size in bytes:(0034) [000021b3]

      machine   stack     stack     machine    assembly
      address   address   data      code       language
      ========  ========  ========  =========  =============
    [00002192][00103820][00000000] 55         push ebp
    [00002193][00103820][00000000] 8bec       mov ebp,esp
    [00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD
    [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD) >>>> New slave_stack at:1038c4

    Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc >>>> [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
    [00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
    [00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
    [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>> New slave_stack at:14e2ec

    This execution trace proves that the second HHH did
    emulate the second DDD correctly:


    Nope, where is the fact that that either HHH has the power to stop any
    of this from happening by aborting there simulation of it?


    I am going to stop right here because you
    seem to fail to understand this point:

    On 8/2/2024 11:32 PM, Jeff Barnett wrote:
    ...In some formulations, there are specific states
    defined as "halting states" and the machine only
    halts if either the start state is a halt state...

    ...these and many other definitions all have
    equivalent computing prowess...

    https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

    Omitting that conditionality makes the trace just
    an incorrect emulation by any defintion.


    void Infinite_Recursion()
    {
    Infinite_Recursion();
    return;
    }

    It does not.
    *If we did not divide the tester from the test subject*
    then Infinite_Recursion() would be determined to halt
    on the basis that HHH halts.

    Instead of that we define reaching the "return"
    halt state of Infinite_Recursion() as halting.


    --
    Copyright 2024 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 Wed Aug 7 21:03:08 2024
    On 8/7/24 8:59 AM, olcott wrote:
    On 8/7/2024 6:25 AM, Richard Damon wrote:
    On 8/6/24 11:47 PM, olcott wrote:
    On 8/6/2024 10:21 PM, Richard Damon wrote:
    On 8/6/24 11:10 PM, olcott wrote:
    On 8/6/2024 10:00 PM, Richard Damon wrote:
    On 8/6/24 10:49 PM, olcott wrote:
    On 8/6/2024 9:27 PM, Richard Damon wrote:
    On 8/6/24 9:48 PM, olcott wrote:
    On 8/6/2024 8:38 PM, Richard Damon wrote:
    On 8/6/24 1:16 PM, olcott wrote:
    On 8/6/2024 12:02 PM, joes wrote:
    Am Tue, 06 Aug 2024 09:43:30 -0500 schrieb olcott:
    Understanding that DDD correctly simulated by HHH cannot >>>>>>>>>>>>> possibly reach
    its own "return" instruction is a mandatory prerequisite to >>>>>>>>>>>>> further
    discussion.

    There is nothing to discuss after agreeing with your
    conclusion.

    Everyone remains convinced that HHH must report on the >>>>>>>>>>>>> behavior of the
    computation that itself is contained within and not the >>>>>>>>>>>>> behavior that
    its finite string input specifies.

    The construction is not recursive if the description does >>>>>>>>>>>> not describe
    the surrounding computation. And that behaviour cannot >>>>>>>>>>>> depend on the
    decider, as they should all give the same answer.


    That is far too vague.

    DDD correctly emulated by HHH according to the semantics >>>>>>>>>>> of the x86 programming language specifies a single exact >>>>>>>>>>> sequence of state changes. None of these state changes
    ends up at the x86 machine language address of the "ret" >>>>>>>>>>> instruction of DDD.


    Which would be meaningful if HHH actual did a correct
    emulation of the

    HHH does emulate the exact sequence that the machine code
    of DDD specifies. This has been conclusively proven by
    the execution traces that the two instances of HHH provide.

    Nope, because it didn't emulate the call instruction properly. >>>>>>>>

    It is proved that it does emulate the call instruction
    properly by the correct execution trace of the second
    DDD derived by the second HHH.

    Nope, just proves you don't know what you are talking about.


    Because your rebuttals have always been pure bluster

    No, YOUR rebuttal have been pure bluster that have avoided answering
    my challenges, thus effectively ADMITTING that you arte just a liar.

    you have only used double-talk and misdirection to dodge
    pointing out any mistake in the following:

    How about the trace that HHH generates shouldn't start with the code
    of main, since that isn't what HHH starts simulating, thus your
    claims about the trace generate by HHH can not be supported by
    something elses trace.


    That is a very ignorant thing to say.

    NO, it is the truth.


    Second, the CORRECT emulation of a "call" instruciton should show
    the instruction of the routine called.


    The extra 200 pages prove to be too confusing. The
    fact that after DDD calls HHH we do get the correct
    execution trace that would be derived from this call
    proves that the second HHH was called.

    Nope, they show you wrong.

    HOW can the emulation that HHH is doing show code that HHH doesn't
    look at?

    Your failure to answer (may times from the past) just prove that you
    KNOW that you have been lying, but don't want to face it.

    Sorry, you are just proving your stupidity


    I will highlight all of the code so that you
    can see the each instruction both HHH are shown
    and both DDD are shown. I will use four different
    colors.

    Since the trace isn't the right trace, that doesn't mean anything.

    And, where are the colors, you said there would be colors.

    Did you not know that this group is text only?


    It really have already been 100% totally proven in
    that after DDD calls HHH we to get the correct
    execution trace of DDD emulated by this second HHH

    Thus, a "Call 000015d2" *MUST* be followed by the instruction AT
    000015d2, and not "Begin Local Halt Decider Simulation"

    Since you have just been repeating this smae ERROR over and over,
    you are just proving that you just don't care about the truth, but
    are just repeating your same LIES over and over and over, securing
    your place in Gehenna.

    _DDD()
    [00002172] 55         push ebp      ; housekeeping
    [00002173] 8bec       mov ebp,esp   ; housekeeping
    [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]

    _main()
    [00002192] 55         push ebp
    [00002193] 8bec       mov ebp,esp
    [00002195] 6872210000 push 00002172 ; push DDD
    [0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
    [0000219f] 83c404     add esp,+04
    [000021a2] 50         push eax
    [000021a3] 6843070000 push 00000743
    [000021a8] e8b5e5ffff call 00000762
    [000021ad] 83c408     add esp,+08
    [000021b0] 33c0       xor eax,eax
    [000021b2] 5d         pop ebp
    [000021b3] c3         ret
    Size in bytes:(0034) [000021b3]

      machine   stack     stack     machine    assembly
      address   address   data      code       language >>>>>   ========  ========  ========  =========  =============
    [00002192][00103820][00000000] 55         push ebp
    [00002193][00103820][00000000] 8bec       mov ebp,esp
    [00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD
    [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call
    HHH(DDD)
    New slave_stack at:1038c4

    Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc >>>>> [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
    [00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
    [00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
    [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
    HHH(DDD)
    New slave_stack at:14e2ec

    This execution trace proves that the second HHH did
    emulate the second DDD correctly:


    Nope, where is the fact that that either HHH has the power to stop any
    of this from happening by aborting there simulation of it?


    I am going to stop right here because you
    seem to fail to understand this point:

    So, what you do think I don't understand about those?

    Those rules are talking about the EXECUTION of PROGRAMs.

    To be a PROGRAM, DDD needs to include the HHH that it calls, or none of
    that applies, as it isn't a program.

    A


    On 8/2/2024 11:32 PM, Jeff Barnett wrote:
    ...In some formulations, there are specific states
        defined as "halting states" and the machine only
        halts if either the start state is a halt state...

    ...these and many other definitions all have
        equivalent computing prowess...

    https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

    Omitting that conditionality makes the trace just an incorrect
    emulation by any defintion.


    void Infinite_Recursion()
    {
      Infinite_Recursion();
      return;
    }

    It does not.

    Sure it does.

    Or are you saying that HHH doesn't CONDITIONALLY emulate its input, and
    thus it can't ever abort it??

    *If we did not divide the tester from the test subject*
    then Infinite_Recursion() would be determined to halt
    on the basis that HHH halts.


    No, because the tester has no effect on the behavior of that program.

    When it decides on a program that calls itself, it needs to look at the
    actual code it was given, even if it includes ITSELF, or the programmer
    is just a LIAR,.

    Instead of that we define reaching the "return"
    halt state of Infinite_Recursion() as halting.

    Right, and you can prove from a partial emualtion of that
    Infinite_Recursion, that if you gave the exact same input, to a
    different emulator, like a real UTM, that said emulator would never
    reach a final state.


    You can't do that with DDD and HHH, as the input DDD, INCLUDEES the HHH
    that it was pair with, and if you give that DDD/HHH pairing to a UTM, it
    will trace DDD calling HHH(DDD) then HHH emulating that copy of DDD for
    a bit, then it deciding to abort, and returning to DDD and then DDD
    reaching that FINAL STATE of the return instuction.

    Since we have this as the actual correct emulation of the input if HHH
    EVER aborts as returns, if its code does that, it is just wrong.

    It is just incorrect to argue about a DDD that calls some other HHH,
    that it doesn't, as that is just a lIE.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Thu Aug 8 10:21:24 2024
    On 2024-08-07 03:47:08 +0000, olcott said:

    On 8/6/2024 10:21 PM, Richard Damon wrote:
    On 8/6/24 11:10 PM, olcott wrote:
    On 8/6/2024 10:00 PM, Richard Damon wrote:
    On 8/6/24 10:49 PM, olcott wrote:
    On 8/6/2024 9:27 PM, Richard Damon wrote:
    On 8/6/24 9:48 PM, olcott wrote:
    On 8/6/2024 8:38 PM, Richard Damon wrote:
    On 8/6/24 1:16 PM, olcott wrote:
    On 8/6/2024 12:02 PM, joes wrote:
    Am Tue, 06 Aug 2024 09:43:30 -0500 schrieb olcott:
    Understanding that DDD correctly simulated by HHH cannot possibly reach
    its own "return" instruction is a mandatory prerequisite to further >>>>>>>>>>> discussion.

    There is nothing to discuss after agreeing with your conclusion. >>>>>>>>>>
    Everyone remains convinced that HHH must report on the behavior of the
    computation that itself is contained within and not the behavior that
    its finite string input specifies.

    The construction is not recursive if the description does not describe
    the surrounding computation. And that behaviour cannot depend on the >>>>>>>>>> decider, as they should all give the same answer.


    That is far too vague.

    DDD correctly emulated by HHH according to the semantics
    of the x86 programming language specifies a single exact
    sequence of state changes. None of these state changes
    ends up at the x86 machine language address of the "ret"
    instruction of DDD.


    Which would be meaningful if HHH actual did a correct emulation of the >>>>>>>
    HHH does emulate the exact sequence that the machine code
    of DDD specifies. This has been conclusively proven by
    the execution traces that the two instances of HHH provide.

    Nope, because it didn't emulate the call instruction properly.


    It is proved that it does emulate the call instruction
    properly by the correct execution trace of the second
    DDD derived by the second HHH.

    Nope, just proves you don't know what you are talking about.


    Because your rebuttals have always been pure bluster

    No, YOUR rebuttal have been pure bluster that have avoided answering my
    challenges, thus effectively ADMITTING that you arte just a liar.

    you have only used double-talk and misdirection to dodge
    pointing out any mistake in the following:

    How about the trace that HHH generates shouldn't start with the code of
    main, since that isn't what HHH starts simulating, thus your claims
    about the trace generate by HHH can not be supported by something elses
    trace.

    That is a very ignorant thing to say.

    If it were you wouldn't say so. Instead you could say what is wrong
    in it. But you can't so you choose to lie.

    --
    Mikko

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