1. Forum
  2. Usenet
  3. COMP.THEORY

  • Re: THREE DIFFERENT QUESTIONS

    From Richard Damon@21:1/5 to olcott on Fri Oct 18 22:49:07 2024
    XPost: sci.logic

    On 10/18/24 8:52 PM, olcott wrote:
    On 10/18/2024 6:06 PM, Richard Damon wrote:
    On 10/18/24 10:10 AM, olcott wrote:
    On 10/18/2024 6:17 AM, Richard Damon wrote:
    On 10/17/24 11:47 PM, olcott wrote:
    On 10/17/2024 10:27 PM, Richard Damon wrote:
    On 10/17/24 9:47 PM, olcott wrote:
    On 10/17/2024 8:13 PM, Richard Damon wrote:
    On 10/17/24 7:31 PM, olcott wrote:
    _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]

    When DDD is correctly emulated by HHH according
    to the semantics of the x86 language DDD cannot
    possibly reach its own machine address [00002183]
    no matter what HHH does.

    [00002172]-->[00002173]-->[00002175]-->[0000217a]--+
    +------------------------------------------------------+

    That may not line up that same way when view




    https://en.wikipedia.org/wiki/State_diagram



    Except that 0000217a doesn't go to 00002172, but to 000015d2


    IS THIS OVER YOUR HEAD?
    What is the first machine address of DDD that HHH
    emulating itself emulating DDD would reach?


    Yes, HHH EMULATES the code at that address,

    Which HHH emulates what code at which address?


    Everyone, just once, which you should know, but ignore.

    The Emulating HHH sees those addresses at its begining and then
    never again.

    Then the HHH that it is emulating will see those addresses, but not
    the outer one that is doing that emulation of HHH.

    Then the HHH that the second HHH is emulating will, but neither of
    the outer 2 HHH.

    And so on.

    Which HHH do you think EVER gets back to 00002172?

    What instruction do you think that it emulates that would tell it to
    do so?

    It isn't the call instruction at 0000217a, as that tells it to go
    into HHH.

    At best the trace is:

    00002172
    00002173
    00002175
    0000217a
    conditional emulation of 00002172
    conditional emulation of 00002173
    conditional emulation of 00002175
    conditional emulation of 0000217a
    CE of CE of 00002172
    ...


    OK great this is finally good progress.

    The "state" never repeats, it is alway a new state,

    Every emulated DDD has an identical process state at every point
    in its emulation trace when adjusting for different top of stack values.


    Nope, remember, each of those levels are CONDITIONAL,

    *There are THREE different questions here*
    (1) Can DDD emulated by HHH according to the semantics
        of the x86 language possibly reach its machine address
        [00002183] no matter what HHH does?


    Ambiguouse question, as pointed out previously.

    A) Do you mean the behavior of the PROGRAM DDD, that HHH has emulated a
    copy of.

    In that case, the answer is, if HHH aborts its emulation and return,
    YES, if HHH never aborts its emulation, and thus doesn't ever return an
    answer to anyone NO.

    B) If you mean, does the emulation done by HHH ever reach that place, no.


    (2) Does HHH correctly detect and report the above?

    No, because that isn't what you claim HHH is doing, so it can't be
    correct about that.

    We need to look at the two possible interpreations to question 1.

    If you means A, then since HHH says no but the correct answer is yes, it
    is wrong.

    If you mean B, and you mean your question is can HHH predict that it
    can't reach the final state, but only needs to be right for this one
    input, then the problem is the question has become trivial, if it
    doesn't need to actually know anything about the input, it can just be programmed to say no.

    Also, we can make a trivial HHH, that just does the absolute minimum,
    then aborts and returns no unconditionally to be correct, showing your
    problem isn't interesting.

    Or, your "problem" has left the domain of Program Theory, becuause you
    don't consider DDD to be an actual program, at which point it also
    becomes much less interesting.


    (3) Does HHH do (2) it as a Turing computable function?


    No, because the method your HHH uses isn't possible to be expressed as a
    Turing Machine with a seperate input tape with the full representatation
    of the program DDD.

    This assumes that you implied intent is that DDD is given as a
    description of the equivalent Turing Machine, and not just a text string
    that doesn't represent a full program, or that HHH doesn't need to

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sat Oct 19 07:21:06 2024
    On 10/18/24 11:19 PM, olcott wrote:
    On 10/18/2024 9:49 PM, Richard Damon wrote:
    On 10/18/24 8:52 PM, olcott wrote:
    On 10/18/2024 6:06 PM, Richard Damon wrote:
    On 10/18/24 10:10 AM, olcott wrote:
    On 10/18/2024 6:17 AM, Richard Damon wrote:
    On 10/17/24 11:47 PM, olcott wrote:
    On 10/17/2024 10:27 PM, Richard Damon wrote:
    On 10/17/24 9:47 PM, olcott wrote:
    On 10/17/2024 8:13 PM, Richard Damon wrote:
    On 10/17/24 7:31 PM, olcott wrote:
    _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]

    When DDD is correctly emulated by HHH according
    to the semantics of the x86 language DDD cannot
    possibly reach its own machine address [00002183]
    no matter what HHH does.

    [00002172]-->[00002173]-->[00002175]-->[0000217a]--+ >>>>>>>>>>> +------------------------------------------------------+ >>>>>>>>>>>
    That may not line up that same way when view




    https://en.wikipedia.org/wiki/State_diagram



    Except that 0000217a doesn't go to 00002172, but to 000015d2 >>>>>>>>>>

    IS THIS OVER YOUR HEAD?
    What is the first machine address of DDD that HHH
    emulating itself emulating DDD would reach?


    Yes, HHH EMULATES the code at that address,

    Which HHH emulates what code at which address?


    Everyone, just once, which you should know, but ignore.

    The Emulating HHH sees those addresses at its begining and then
    never again.

    Then the HHH that it is emulating will see those addresses, but
    not the outer one that is doing that emulation of HHH.

    Then the HHH that the second HHH is emulating will, but neither of >>>>>> the outer 2 HHH.

    And so on.

    Which HHH do you think EVER gets back to 00002172?

    What instruction do you think that it emulates that would tell it
    to do so?

    It isn't the call instruction at 0000217a, as that tells it to go
    into HHH.

    At best the trace is:

    00002172
    00002173
    00002175
    0000217a
    conditional emulation of 00002172
    conditional emulation of 00002173
    conditional emulation of 00002175
    conditional emulation of 0000217a
    CE of CE of 00002172
    ...


    OK great this is finally good progress.

    The "state" never repeats, it is alway a new state,

    Every emulated DDD has an identical process state at every point
    in its emulation trace when adjusting for different top of stack
    values.


    Nope, remember, each of those levels are CONDITIONAL,

    *There are THREE different questions here*
    (1) Can DDD emulated by HHH according to the semantics
         of the x86 language possibly reach its machine address
         [00002183] no matter what HHH does?


    Ambiguouse question, as pointed out previously.

    A) Do you mean the behavior of the PROGRAM DDD, that HHH has emulated
    a copy of.

    In that case, the answer is, if HHH aborts its emulation and return,
    YES, if HHH never aborts its emulation, and thus doesn't ever return
    an answer to anyone NO.

    B) If you mean, does the emulation done by HHH ever reach that place, no.


    We are not asking if the code of HHH reaches inside
    the code of DDD. Of course it doesn't this is stupid.

    We are asking does any DDD of any DDD/HHH pair of the
    infinite set of pairs such that DDD is emulated by HHH
    according to the semantics of the x86 language reach its
    own return instruction?


    (2) Does HHH correctly detect and report the above?

    No, because that isn't what you claim HHH is doing, so it can't be
    correct about that.


    In other words you fail to comprehend that DDD failing
    to reach its "return" instruction is isomorphic to:

    On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
    ... PO really /has/ an H
    (it's trivial to do for this one case) that correctly determines
    that P(P) *would* never stop running *unless* aborted.

    We need to look at the two possible interpreations to question 1.

    If you means A, then since HHH says no but the correct answer is yes,
    it is wrong.

    If you mean B, and you mean your question is can HHH predict that it
    can't reach the final state, but only needs to be right for this one
    input, then the problem is the question has become trivial, if it
    doesn't need to actually know anything about the input, it can just be
    programmed to say no.


    I mean that the execution trace of DDD proves that HHH is correct
    to reject DDD as impossibly reaching its own "return" instruction
    even if it just guesses.

    Also, we can make a trivial HHH, that just does the absolute minimum,
    then aborts and returns no unconditionally to be correct, showing your
    problem isn't interesting.

    Or, your "problem" has left the domain of Program Theory, becuause you
    don't consider DDD to be an actual program, at which point it also
    becomes much less interesting.


    (3) Does HHH do (2) it as a Turing computable function?


    No, because the method your HHH uses isn't possible to be expressed as
    a Turing Machine with a seperate input tape with the full
    representatation of the program DDD.


    Yet again you are not answering the question that
    was asked. This must be your ADD.

    The summation is the DDD does not halt and HHH
    does correctly report this even if HHH as it is
    currently implemented is not a Turing computable
    function.

    But the Program DDD DOES halt, because the copy of HHH that it calls
    WILL abort at the apointed time and return.

    "Turing Computable" isn't about implementation, but about what is
    computed. Your problem setup is naturally unable to handle a Turing
    Complete set of inputs, because of its intermixture of program to decide
    and program deciding.

    The fact that you stated that DDD wasn't allowed to use its own copy of
    HHH because we couldn't make a correct copy of HHH just proves that fact.


    This assumes that you implied intent is that DDD is given as a
    description of the equivalent Turing Machine, and not just a text
    string that doesn't represent a full program, or that HHH doesn't need to



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sat Oct 19 17:53:49 2024
    On 10/19/24 7:26 AM, olcott wrote:
    On 10/19/2024 6:21 AM, Richard Damon wrote:
    On 10/18/24 11:19 PM, olcott wrote:
    On 10/18/2024 9:49 PM, Richard Damon wrote:
    On 10/18/24 8:52 PM, olcott wrote:
    On 10/18/2024 6:06 PM, Richard Damon wrote:
    On 10/18/24 10:10 AM, olcott wrote:
    On 10/18/2024 6:17 AM, Richard Damon wrote:
    On 10/17/24 11:47 PM, olcott wrote:
    On 10/17/2024 10:27 PM, Richard Damon wrote:
    On 10/17/24 9:47 PM, olcott wrote:
    On 10/17/2024 8:13 PM, Richard Damon wrote:
    On 10/17/24 7:31 PM, olcott wrote:
    _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]

    When DDD is correctly emulated by HHH according
    to the semantics of the x86 language DDD cannot
    possibly reach its own machine address [00002183]
    no matter what HHH does.

    [00002172]-->[00002173]-->[00002175]-->[0000217a]--+ >>>>>>>>>>>>> +------------------------------------------------------+ >>>>>>>>>>>>>
    That may not line up that same way when view




    https://en.wikipedia.org/wiki/State_diagram



    Except that 0000217a doesn't go to 00002172, but to 000015d2 >>>>>>>>>>>>

    IS THIS OVER YOUR HEAD?
    What is the first machine address of DDD that HHH
    emulating itself emulating DDD would reach?


    Yes, HHH EMULATES the code at that address,

    Which HHH emulates what code at which address?


    Everyone, just once, which you should know, but ignore.

    The Emulating HHH sees those addresses at its begining and then >>>>>>>> never again.

    Then the HHH that it is emulating will see those addresses, but >>>>>>>> not the outer one that is doing that emulation of HHH.

    Then the HHH that the second HHH is emulating will, but neither >>>>>>>> of the outer 2 HHH.

    And so on.

    Which HHH do you think EVER gets back to 00002172?

    What instruction do you think that it emulates that would tell >>>>>>>> it to do so?

    It isn't the call instruction at 0000217a, as that tells it to >>>>>>>> go into HHH.

    At best the trace is:

    00002172
    00002173
    00002175
    0000217a
    conditional emulation of 00002172
    conditional emulation of 00002173
    conditional emulation of 00002175
    conditional emulation of 0000217a
    CE of CE of 00002172
    ...


    OK great this is finally good progress.

    The "state" never repeats, it is alway a new state,

    Every emulated DDD has an identical process state at every point >>>>>>> in its emulation trace when adjusting for different top of stack >>>>>>> values.


    Nope, remember, each of those levels are CONDITIONAL,

    *There are THREE different questions here*
    (1) Can DDD emulated by HHH according to the semantics
         of the x86 language possibly reach its machine address
         [00002183] no matter what HHH does?


    Ambiguouse question, as pointed out previously.

    A) Do you mean the behavior of the PROGRAM DDD, that HHH has
    emulated a copy of.

    In that case, the answer is, if HHH aborts its emulation and return,
    YES, if HHH never aborts its emulation, and thus doesn't ever return
    an answer to anyone NO.

    B) If you mean, does the emulation done by HHH ever reach that
    place, no.


    We are not asking if the code of HHH reaches inside
    the code of DDD. Of course it doesn't this is stupid.

    We are asking does any DDD of any DDD/HHH pair of the
    infinite set of pairs such that DDD is emulated by HHH
    according to the semantics of the x86 language reach its
    own return instruction?


    (2) Does HHH correctly detect and report the above?

    No, because that isn't what you claim HHH is doing, so it can't be
    correct about that.


    In other words you fail to comprehend that DDD failing
    to reach its "return" instruction is isomorphic to:

    On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
    ... PO really /has/ an H
    (it's trivial to do for this one case) that correctly determines
    that P(P) *would* never stop running *unless* aborted.

    We need to look at the two possible interpreations to question 1.

    If you means A, then since HHH says no but the correct answer is
    yes, it is wrong.

    If you mean B, and you mean your question is can HHH predict that it
    can't reach the final state, but only needs to be right for this one
    input, then the problem is the question has become trivial, if it
    doesn't need to actually know anything about the input, it can just
    be programmed to say no.


    I mean that the execution trace of DDD proves that HHH is correct
    to reject DDD as impossibly reaching its own "return" instruction
    even if it just guesses.

    Also, we can make a trivial HHH, that just does the absolute
    minimum, then aborts and returns no unconditionally to be correct,
    showing your problem isn't interesting.

    Or, your "problem" has left the domain of Program Theory, becuause
    you don't consider DDD to be an actual program, at which point it
    also becomes much less interesting.


    (3) Does HHH do (2) it as a Turing computable function?


    No, because the method your HHH uses isn't possible to be expressed
    as a Turing Machine with a seperate input tape with the full
    representatation of the program DDD.


    Yet again you are not answering the question that
    was asked. This must be your ADD.

    The summation is the DDD does not halt and HHH
    does correctly report this even if HHH as it is
    currently implemented is not a Turing computable
    function.

    But the Program DDD DOES halt,

    *Try and tell that to ChatGPT and it will make a fool of you* https://chatgpt.com/share/6709e046-4794-8011-98b7-27066fb49f3e


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


    Ignore any false information about the definiton of a termination
    analyzer, and recall that the correct answer to a question given to a termination analyzer is that it must report about the actual behavior of
    the program that it has been given, and that program includes ALL the
    code that program uses, so the DDD that you have been given includes the
    code of the HHH that it calls, and that code has been claimed to
    "correctly" return 0, and thus the actual behavior of DDD, is to reach
    its final instruction and halt. Thus, the actual correct answer that HHH
    must give to be correct would be to return 1 to say the input halts.


    ChatGPT said:

    ChatGPT
    You raise an important point about how a termination analyzer should
    operate in relation to the complete program it analyzes, including any
    code that is called. Let’s clarify this with your criteria in mind.

    Correct Understanding of Termination Analysis:

    Complete Program Behavior:

    A termination analyzer should assess the behavior of the entire program, including any functions that it calls.
    In this context, DDD() includes the behavior of HHH(DDD) that it calls. Function HHH:
    HHH is supposed to simulate the behavior of the program it's analyzing
    (in this case, DDD()).
    According to your description, HHH detects that DDD() has the potential
    for non-termination but is also capable of returning 0 when it finds
    that DDD() calls HHH(DDD).
    Actual Behavior of DDD():
    When DDD() is invoked in main(), the execution flow leads to HHH(DDD).
    If HHH detects the recursive structure but also acknowledges that it can
    return 0, which means that it is effectively halting the infinite
    recursion and allowing DDD() to reach its return; instruction.

    Conclusion:
    Given this understanding:

    If HHH correctly evaluates the behavior of the entire program and
    recognizes that DDD() ultimately halts after HHH returns, then it should
    report that the input halts by returning 1.
    Thus, under the framework you provided, the correct response from HHH
    would indeed be to return 1, indicating that the actual behavior of
    DDD() is to reach its final instruction and halt.

    Summary:

    You are correct in asserting that the termination analyzer should report
    the actual behavior of the entire program. If HHH allows DDD() to reach
    its return statement, then the correct behavior is indeed to report that
    DDD() halts by returning 1. Thank you for clarifying this important aspect!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sat Oct 19 22:27:49 2024
    On 10/19/24 8:13 PM, olcott wrote:
    On 10/19/2024 4:53 PM, Richard Damon wrote:
    On 10/19/24 7:26 AM, olcott wrote:
    On 10/19/2024 6:21 AM, Richard Damon wrote:
    On 10/18/24 11:19 PM, olcott wrote:
    On 10/18/2024 9:49 PM, Richard Damon wrote:
    On 10/18/24 8:52 PM, olcott wrote:
    On 10/18/2024 6:06 PM, Richard Damon wrote:
    On 10/18/24 10:10 AM, olcott wrote:
    On 10/18/2024 6:17 AM, Richard Damon wrote:
    On 10/17/24 11:47 PM, olcott wrote:
    On 10/17/2024 10:27 PM, Richard Damon wrote:
    On 10/17/24 9:47 PM, olcott wrote:
    On 10/17/2024 8:13 PM, Richard Damon wrote:
    On 10/17/24 7:31 PM, olcott wrote:
    _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]

    When DDD is correctly emulated by HHH according
    to the semantics of the x86 language DDD cannot
    possibly reach its own machine address [00002183] >>>>>>>>>>>>>>> no matter what HHH does.

    [00002172]-->[00002173]-->[00002175]-->[0000217a]--+ >>>>>>>>>>>>>>> +------------------------------------------------------+ >>>>>>>>>>>>>>>
    That may not line up that same way when view




    https://en.wikipedia.org/wiki/State_diagram



    Except that 0000217a doesn't go to 00002172, but to 000015d2 >>>>>>>>>>>>>>

    IS THIS OVER YOUR HEAD?
    What is the first machine address of DDD that HHH
    emulating itself emulating DDD would reach?


    Yes, HHH EMULATES the code at that address,

    Which HHH emulates what code at which address?


    Everyone, just once, which you should know, but ignore.

    The Emulating HHH sees those addresses at its begining and >>>>>>>>>> then never again.

    Then the HHH that it is emulating will see those addresses, >>>>>>>>>> but not the outer one that is doing that emulation of HHH. >>>>>>>>>>
    Then the HHH that the second HHH is emulating will, but
    neither of the outer 2 HHH.

    And so on.

    Which HHH do you think EVER gets back to 00002172?

    What instruction do you think that it emulates that would tell >>>>>>>>>> it to do so?

    It isn't the call instruction at 0000217a, as that tells it to >>>>>>>>>> go into HHH.

    At best the trace is:

    00002172
    00002173
    00002175
    0000217a
    conditional emulation of 00002172
    conditional emulation of 00002173
    conditional emulation of 00002175
    conditional emulation of 0000217a
    CE of CE of 00002172
    ...


    OK great this is finally good progress.

    The "state" never repeats, it is alway a new state,

    Every emulated DDD has an identical process state at every point >>>>>>>>> in its emulation trace when adjusting for different top of
    stack values.


    Nope, remember, each of those levels are CONDITIONAL,

    *There are THREE different questions here*
    (1) Can DDD emulated by HHH according to the semantics
         of the x86 language possibly reach its machine address
         [00002183] no matter what HHH does?


    Ambiguouse question, as pointed out previously.

    A) Do you mean the behavior of the PROGRAM DDD, that HHH has
    emulated a copy of.

    In that case, the answer is, if HHH aborts its emulation and
    return, YES, if HHH never aborts its emulation, and thus doesn't
    ever return an answer to anyone NO.

    B) If you mean, does the emulation done by HHH ever reach that
    place, no.


    We are not asking if the code of HHH reaches inside
    the code of DDD. Of course it doesn't this is stupid.

    We are asking does any DDD of any DDD/HHH pair of the
    infinite set of pairs such that DDD is emulated by HHH
    according to the semantics of the x86 language reach its
    own return instruction?


    (2) Does HHH correctly detect and report the above?

    No, because that isn't what you claim HHH is doing, so it can't be >>>>>> correct about that.


    In other words you fail to comprehend that DDD failing
    to reach its "return" instruction is isomorphic to:

    On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
    ... PO really /has/ an H
    (it's trivial to do for this one case) that correctly determines >>>>>  > that P(P) *would* never stop running *unless* aborted.

    We need to look at the two possible interpreations to question 1.

    If you means A, then since HHH says no but the correct answer is
    yes, it is wrong.

    If you mean B, and you mean your question is can HHH predict that
    it can't reach the final state, but only needs to be right for
    this one input, then the problem is the question has become
    trivial, if it doesn't need to actually know anything about the
    input, it can just be programmed to say no.


    I mean that the execution trace of DDD proves that HHH is correct
    to reject DDD as impossibly reaching its own "return" instruction
    even if it just guesses.

    Also, we can make a trivial HHH, that just does the absolute
    minimum, then aborts and returns no unconditionally to be correct, >>>>>> showing your problem isn't interesting.

    Or, your "problem" has left the domain of Program Theory, becuause >>>>>> you don't consider DDD to be an actual program, at which point it
    also becomes much less interesting.


    (3) Does HHH do (2) it as a Turing computable function?


    No, because the method your HHH uses isn't possible to be
    expressed as a Turing Machine with a seperate input tape with the
    full representatation of the program DDD.


    Yet again you are not answering the question that
    was asked. This must be your ADD.

    The summation is the DDD does not halt and HHH
    does correctly report this even if HHH as it is
    currently implemented is not a Turing computable
    function.

    But the Program DDD DOES halt,

    *Try and tell that to ChatGPT and it will make a fool of you*
    https://chatgpt.com/share/6709e046-4794-8011-98b7-27066fb49f3e


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


    Ignore any false information about the definiton of a termination
    analyzer, and recall that the correct answer to a question given to a
    termination analyzer is that it must report about the actual behavior
    of the program that it has been given,

    You are directly contradicting the verified fact that DDD
    emulated by HHH according to the semantics of the x86 language
    cannot possibly reach its own "return" instruction and halt.


    But that isn't what the question being asked is, it is (or you claim it
    to be) about Termination, which is about the behavior of the PROGRAM /
    FUNCITON (with all its used code) not about a partial emulation of it.

    Your statement is just an equivocation trying to confuse the idea of
    comnplete correct emulations showing actual behavior, while a partial,
    but correct, only shows partial behavior, not final behavior.

    The VERIFIED FACT, is that what is defined as the BEHAVIOR of DDD, which
    is what a termination analyser (or Halt Decider) has been determined to
    be halting for the actual HHH you have provided.

    Your claim tries to refer to the behavior of an only partial emuation
    and claim that it shows non-termination, which it doesn't.

    You are just proving that you are nothing but a stupid liar.

    Your "Verified Fact" is just your LIE based on equivocation, as you have
    been told, but don't seem to be able to understand it.

    Sorry, you claimed no one could persuade the AI that you were wrong, and
    I did it with ONE try.

    How many attempts did it take you to get the answer you wanted out of
    Chat GPT?

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