• The essence of my halting problem work

    From olcott@3:633/280.2 to All on Wed Dec 11 15:52:07 2024
    On 12/10/2024 8:01 PM, Richard Damon wrote:
    On 12/10/24 9:22 AM, olcott wrote:
    On 12/10/2024 1:35 AM, Mikko wrote:
    On 2024-12-09 13:46:16 +0000, olcott said:

    On 12/9/2024 4:54 AM, Mikko wrote:
    On 2024-12-08 19:34:19 +0000, olcott said:

    On 12/8/2024 4:55 AM, Mikko wrote:
    On 2024-12-05 04:20:50 +0000, olcott said:

    There is an 80% chance that I will be alive in one month.
    There may be an extended pause in my comments.
    I will try to bring a computer to the out of town hospital.

    On 12/4/2024 8:16 PM, Richard Damon wrote:
    On 12/4/24 8:50 PM, olcott wrote:
    On 12/4/2024 7:45 PM, Richard Damon wrote:
    On 12/4/24 8:41 PM, olcott wrote:
    On 12/4/2024 7:31 PM, Richard Damon wrote:
    On 12/4/24 8:06 PM, olcott wrote:
    On 12/4/2024 6:11 PM, Richard Damon wrote:
    On 12/4/24 9:27 AM, olcott wrote:
    On 12/3/2024 5:39 PM, Richard Damon wrote:
    On 12/3/24 6:08 PM, olcott wrote:
    On 12/3/2024 3:03 AM, joes wrote:
    Am Mon, 02 Dec 2024 20:48:49 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>> On 11/28/2024 1:48 PM, joes wrote:

    You said:
    ÿ >>> HHH can't simulate itself.
    That is WRONG !!!
    HHH DOES EMULATE ITSELF PROVING THAT IT CAN EMULATE >>>>>>>>>>>>>>>>>>>> ITSELF.
    We know that HHH halts. It doesn't simulate itself >>>>>>>>>>>>>>>>>>> halting.


    Please try and explain how you are not dishonest what you >>>>>>>>>>>>>>>>>> try to change the subject from my rebuttal of your >>>>>>>>>>>>>>>>>> statement:

    HHH can't simulate itself.

    That HHH does emulate itself emulating DDD proves >>>>>>>>>>>>>>>>>> THAT IT CAN DO THIS.


    But only if your think that wrong answer can be right. >>>>>>>>>>>>>>>>
    I did not mention anything about answers my entire >>>>>>>>>>>>>>>> scope is that HHH does emulate itself emulating DDD >>>>>>>>>>>>>>>> thus conclusively proving that HHH can emulated itself >>>>>>>>>>>>>>>> emulating DDD.

    Whenever you go out-of-scope like this it surely >>>>>>>>>>>>>>>> seems dishonest to me.


    But the behaivor that HHH shows that it has *IS* an >>>>>>>>>>>>>>> "answer",

    DDD emulated by any HHH according to the semantics of >>>>>>>>>>>>>> the x86 language cannot possibly reach its "ret" instruction >>>>>>>>>>>>>> whether HHH aborts this emulation after N steps or never >>>>>>>>>>>>>> aborts.



    Just a nonsense sentence, since HHH can't emulate HHH as it >>>>>>>>>>>>> isn't given it,

    Why do you have to keep fucking lying about this?
    I could die on the operating table in two weeks!


    What's the lie?

    Can you point to what I say that is wrong, and a reliable >>>>>>>>>>> reference that show it?

    All you have is your own lies to call it a lie.

    And yes, you might die in two weeks, and the only thing you >>>>>>>>>>> will have left behind is all your lies.

    Yes you fucking jackass this conclusively proves that
    HHH does emulate itself emulating DDD.

    https://github.com/plolcott/x86utm/blob/master/Halt7.c



    Nope.

    It proves that your HHH fails to meet its requirement to be >>>>>>>>> pure function

    It proves that HHH does emulate itself emulating DDD.

    Once we get through this point then we know that DDD
    does not halt:

    DDD emulated by any HHH according to the semantics of
    the x86 language cannot possibly reach its "ret" instruction
    whether HHH aborts this emulation after N steps or never aborts. >>>>>>>> *This tells us that DDD emulated by HHH DOES NOT HALT*

    We do not begin to examine whether or not HHH found this
    answer as a pure function until after we agree with the
    prior point.

    *In all of the history of the halting problem there*
    *have never been a correct return value for this*

    typedef void (*ptr)();
    int HHH(ptr P);

    int DD()
    {
    ÿÿ int Halt_Status = HHH(DD);
    ÿÿ if (Halt_Status)
    ÿÿÿÿ HERE: goto HERE;
    ÿÿ return Halt_Status;
    }

    int main()
    {
    ÿÿ HHH(DD);
    }

    This is not a useful main. It is sufficient to determine whether HHH >>>>>>> returns but not to determine whther it returns the correct value. >>>>>>>
    When we understand that the first point is correct
    then we know that HHH returning 0 is correct.
    *This has much has never ever been done before*

    This is one of the well known methods to prove that the value HHH >>>>>>> returns
    is incorrect. If HHH returns 0 then DD returns 0 but the meaning >>>>>>> of 0 in
    this context is that DD does not halt. THerefore the value
    returned by
    HHH is incorrect.

    Every expert in the C programming language has agreed that DD
    simulated by HHH cannot possibly return.

    No, they not. They have agreed that DD returns only if HHH returns
    0 and that HHH is not able to simulated DD to that point.

    Everyone disagreeing with this has dishonestly used to strawman
    deception to refer to different behavior than DD simulated by HHH.

    The topic as specified on the subject line is the behaviour of DD and >>>>> what HHH should report. Simulation is not mentioned there.

    I can't put more than a sentence on the subject line.

    What you did put there specifies that the halting problem is on topic
    and therefore is not "strawman".


    In the specific aspect of the "do the opposite of whatever HHH says"
    halting problem input DD, HHH does correctly reject DD as non-halting
    on the basis that DD emulated by any HHH cannot possibly reach its
    own final state.


    Nope, sincr the program DD will halt and the program HHH says it will not.


    typedef void (*ptr)();
    int HHH(ptr P);

    int DD()
    {
    int Halt_Status = HHH(DD);
    if (Halt_Status)
    HERE: goto HERE;
    return Halt_Status;
    }

    int main()
    {
    HHH(DD);
    }

    You may be indoctrinated against these essential truths
    yet they remain true just the same.

    (1) Halt Deciders / Termination analyzers compute the
    mapping from their input finite string to the actual
    behavior that it specifies. NON-INPUTS ARE NOT ALLOWED.

    (2) DD simulated/emulated by any HHH according to the
    semantics of the C/x86 language cannot possibly reach
    it own final halt state.

    Your tactic of "rebutting" these truths is to change the
    subject entirely. You never assess the exact words that
    I actually said.

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

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Richard Damon@3:633/280.2 to All on Wed Dec 11 22:56:37 2024
    On 12/10/24 11:52 PM, olcott wrote:
    On 12/10/2024 8:01 PM, Richard Damon wrote:
    On 12/10/24 9:22 AM, olcott wrote:
    On 12/10/2024 1:35 AM, Mikko wrote:
    On 2024-12-09 13:46:16 +0000, olcott said:

    On 12/9/2024 4:54 AM, Mikko wrote:
    On 2024-12-08 19:34:19 +0000, olcott said:

    On 12/8/2024 4:55 AM, Mikko wrote:
    On 2024-12-05 04:20:50 +0000, olcott said:

    There is an 80% chance that I will be alive in one month.
    There may be an extended pause in my comments.
    I will try to bring a computer to the out of town hospital.

    On 12/4/2024 8:16 PM, Richard Damon wrote:
    On 12/4/24 8:50 PM, olcott wrote:
    On 12/4/2024 7:45 PM, Richard Damon wrote:
    On 12/4/24 8:41 PM, olcott wrote:
    On 12/4/2024 7:31 PM, Richard Damon wrote:
    On 12/4/24 8:06 PM, olcott wrote:
    On 12/4/2024 6:11 PM, Richard Damon wrote:
    On 12/4/24 9:27 AM, olcott wrote:
    On 12/3/2024 5:39 PM, Richard Damon wrote:
    On 12/3/24 6:08 PM, olcott wrote:
    On 12/3/2024 3:03 AM, joes wrote:
    Am Mon, 02 Dec 2024 20:48:49 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>>> On 11/28/2024 1:48 PM, joes wrote:

    You said:
    ÿ >>> HHH can't simulate itself.
    That is WRONG !!!
    HHH DOES EMULATE ITSELF PROVING THAT IT CAN EMULATE >>>>>>>>>>>>>>>>>>>>> ITSELF.
    We know that HHH halts. It doesn't simulate itself >>>>>>>>>>>>>>>>>>>> halting.


    Please try and explain how you are not dishonest what >>>>>>>>>>>>>>>>>>> you
    try to change the subject from my rebuttal of your >>>>>>>>>>>>>>>>>>> statement:

    HHH can't simulate itself.

    That HHH does emulate itself emulating DDD proves >>>>>>>>>>>>>>>>>>> THAT IT CAN DO THIS.


    But only if your think that wrong answer can be right. >>>>>>>>>>>>>>>>>
    I did not mention anything about answers my entire >>>>>>>>>>>>>>>>> scope is that HHH does emulate itself emulating DDD >>>>>>>>>>>>>>>>> thus conclusively proving that HHH can emulated itself >>>>>>>>>>>>>>>>> emulating DDD.

    Whenever you go out-of-scope like this it surely >>>>>>>>>>>>>>>>> seems dishonest to me.


    But the behaivor that HHH shows that it has *IS* an >>>>>>>>>>>>>>>> "answer",

    DDD emulated by any HHH according to the semantics of >>>>>>>>>>>>>>> the x86 language cannot possibly reach its "ret" instruction >>>>>>>>>>>>>>> whether HHH aborts this emulation after N steps or never >>>>>>>>>>>>>>> aborts.



    Just a nonsense sentence, since HHH can't emulate HHH as >>>>>>>>>>>>>> it isn't given it,

    Why do you have to keep fucking lying about this?
    I could die on the operating table in two weeks!


    What's the lie?

    Can you point to what I say that is wrong, and a reliable >>>>>>>>>>>> reference that show it?

    All you have is your own lies to call it a lie.

    And yes, you might die in two weeks, and the only thing you >>>>>>>>>>>> will have left behind is all your lies.

    Yes you fucking jackass this conclusively proves that
    HHH does emulate itself emulating DDD.

    https://github.com/plolcott/x86utm/blob/master/Halt7.c



    Nope.

    It proves that your HHH fails to meet its requirement to be >>>>>>>>>> pure function

    It proves that HHH does emulate itself emulating DDD.

    Once we get through this point then we know that DDD
    does not halt:

    DDD emulated by any HHH according to the semantics of
    the x86 language cannot possibly reach its "ret" instruction >>>>>>>>> whether HHH aborts this emulation after N steps or never aborts. >>>>>>>>> *This tells us that DDD emulated by HHH DOES NOT HALT*

    We do not begin to examine whether or not HHH found this
    answer as a pure function until after we agree with the
    prior point.

    *In all of the history of the halting problem there*
    *have never been a correct return value for this*

    typedef void (*ptr)();
    int HHH(ptr P);

    int DD()
    {
    ÿÿ int Halt_Status = HHH(DD);
    ÿÿ if (Halt_Status)
    ÿÿÿÿ HERE: goto HERE;
    ÿÿ return Halt_Status;
    }

    int main()
    {
    ÿÿ HHH(DD);
    }

    This is not a useful main. It is sufficient to determine whether >>>>>>>> HHH
    returns but not to determine whther it returns the correct value. >>>>>>>>
    When we understand that the first point is correct
    then we know that HHH returning 0 is correct.
    *This has much has never ever been done before*

    This is one of the well known methods to prove that the value >>>>>>>> HHH returns
    is incorrect. If HHH returns 0 then DD returns 0 but the meaning >>>>>>>> of 0 in
    this context is that DD does not halt. THerefore the value
    returned by
    HHH is incorrect.

    Every expert in the C programming language has agreed that DD
    simulated by HHH cannot possibly return.

    No, they not. They have agreed that DD returns only if HHH returns >>>>>> 0 and that HHH is not able to simulated DD to that point.

    Everyone disagreeing with this has dishonestly used to strawman
    deception to refer to different behavior than DD simulated by HHH. >>>>>>
    The topic as specified on the subject line is the behaviour of DD and >>>>>> what HHH should report. Simulation is not mentioned there.

    I can't put more than a sentence on the subject line.

    What you did put there specifies that the halting problem is on topic
    and therefore is not "strawman".


    In the specific aspect of the "do the opposite of whatever HHH says"
    halting problem input DD, HHH does correctly reject DD as non-halting
    on the basis that DD emulated by any HHH cannot possibly reach its
    own final state.


    Nope, sincr the program DD will halt and the program HHH says it will
    not.


    typedef void (*ptr)();
    int HHH(ptr P);

    int DD()
    {
    ÿ int Halt_Status = HHH(DD);
    ÿ if (Halt_Status)
    ÿÿÿ HERE: goto HERE;
    ÿ return Halt_Status;
    }

    int main()
    {
    ÿ HHH(DD);
    }

    You may be indoctrinated against these essential truths
    yet they remain true just the same.

    (1) Halt Deciders / Termination analyzers compute the
    mapping from their input finite string to the actual
    behavior that it specifies. NON-INPUTS ARE NOT ALLOWED.

    And the Actual Behavior that it specifies s *DEFINED* as the behavior of running the *PROGRAM* that the input describes.

    Note, *PROGRAM*, so the input *MUST* describe a FULL program, meaning
    *ALL* the code, so for DD *MUST* include the code for the HHH that it calls.

    Thus, and "finite string" input that doesn't, just isn't a valid input.

    That is like asking for the sum of 1 and?


    Tou are just showing you don't undetstand the meaning of the fundamental
    term "program" or "input"


    (2) DD simulated/emulated by any HHH according to the
    semantics of the C/x86 language cannot possibly reach
    it own final halt state.

    But "behavior" is defined by the direct running, or the FULL simulation/emulation of that input, which needs to be a full program,
    *NOT* just a partial emulation.

    Since the HHH that DD calls *DOES* abort (as you say it does), that
    means HHH's emulation is *NOT* what defines the "behavior" of the input.

    The behavior of the above input, when we include the needed code for
    HHH, shows that DD will halt, as that is what DD does when run, since
    you have specified that your final HHH will return 0, since you claim it
    is correct to do so, so thus you are asserting that is its behavior, or
    you are just stupid liar,


    Your tactic of "rebutting" these truths is to change the
    subject entirely. You never assess the exact words that
    I actually said.


    No, you "tactic" of using incorrect definitions just proves you are
    nothing but a stupid liar.

    The problem is your "exact words" are just non-sense lies based on
    incorrect definitions.


    Sorry, but you are just proving your stupidity, and the fact that you
    just keep repeating your incorrect statements and never even try to
    answer the errors pointed out show that either you know you are wrong,
    or are too stupid to understand what you are talking about, or more
    likely both, ie you know your statements are wrong, but want to beleive
    them, and are too stupid to understand that wrong is wrong.

    This is going to be your final reputation, that Peter Olcott never
    understood the basics of the logic he was trying to use, but kept
    himself in his imaginary, and self-contradictory world.

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: i2pn2 (i2pn.org) (3:633/280.2@fidonet)