• Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key

    From olcott@21:1/5 to Ben Bacarisse on Wed Apr 6 20:01:50 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/6/2022 7:34 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/6/2022 6:35 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/6/2022 4:36 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/6/2022 9:19 AM, Ben Bacarisse wrote:

    As for the main mistake, I know enough about cranks to aim for only one >>>>>>> of two things: can they be persuaded to say enough to show others that >>>>>>> they are wrong (for example PO admission that H(P,P) == false is correct
    despite the fact that P(P) halts),

    If it is the case that the simulated input to H cannot possibly reach >>>>>> its own final state under any condition what-so-ever then H correctly >>>>>> maps this finite string input to its reject state and nothing in the >>>>>> universe can correctly contradict that H is correct.

    If you have a white dog in your living room and everyone in the
    universe disagrees, you still have a white dog in your living room. >>>>>
    Good to see that you are still asserting that false is the correct
    result from a halt decider for at least one halting computation.

    If the input to the halt decider specifies a non-halting sequence of
    configurations then any damn thing anywhere else is totally
    irrelevant.
    If P(P) halts, H(P,P) should be true.

    Like I said any damn thing else is actually 100% perfectly totally
    irrelevant.

    Yes! The only thing that matters is whether the "input", (P,P),
    specifies a halting computation or not.

    The "input" to H is two
    parameters that specify the halting computation P(P).

    A halting computation that cannot possibly reach its own final state
    under any condition what-so-ever?

    Either P(P) halts or it does not. Did you tell a fib when you said it
    does? Since it halts, H(P,P) == false is wrong.

    The input to H(P,P) cannot possibly reach its own final state under
    any condition what-so-ever, thus if God and all his angels and every
    being great and small said that the input to H specifies a halting
    computation they would all be liars.

    You told that us P(P) halts. Until you retract that, I will take it to
    be true. You also told us that H(P,P) == false. Do you need to correct
    one or other of these statements?


    As long as the input to H(P,P) never reaches its final state under any condition what-so-ever then no matter what P(P) does H was still correct because P(P) is not an input and H is only accountable for getting its
    inputs correctly.

    If a guard is assigned to watch the front door and no one comes in the
    front door and thousands of people come in the back door the guard is
    correct to say that no one came in the front door.

    The input to H is its front door that it must guard. What P(P) does when
    it is not an input is all back door stuff and none of the business of
    any decider.



    --
    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 Thu Apr 7 17:57:41 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/7/2022 5:51 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 6:46:37 PM UTC-4, olcott wrote:
    On 4/7/2022 5:18 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 5:51:41 PM UTC-4, olcott wrote:
    On 4/7/2022 4:37 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 5:17:44 PM UTC-4, olcott wrote:
    On 4/7/2022 3:21 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 4:04:48 PM UTC-4, olcott wrote:
    On 4/7/2022 3:00 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 3:58:03 PM UTC-4, olcott wrote: >>>>>>>>>> On 4/7/2022 2:38 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 3:19:03 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 4/7/2022 2:07 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 2:54:57 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 4/7/2022 1:51 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 2:47:53 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>> On 4/7/2022 1:45 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 2:24:01 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>>>> On 4/7/2022 1:08 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 2:04:41 PM UTC-4, olcott wrote:
    On 4/7/2022 1:00 PM, olcott wrote:
    On 4/7/2022 12:59 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 1:37:20 PM UTC-4, olcott wrote:
    On 4/7/2022 12:09 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 1:02:27 PM UTC-4, olcott wrote:
    On 4/7/2022 11:52 AM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 12:16:56 PM UTC-4, olcott wrote:
    On 4/7/2022 9:45 AM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 10:35:31 AM UTC-4, olcott wrote:
    On 4/7/2022 5:58 AM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 4/6/2022 8:49 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 4/6/2022 7:34 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 4/6/2022 6:35 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 4/6/2022 4:36 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 4/6/2022 9:19 AM, Ben Bacarisse wrote:

    As for the main mistake, I know enough about cranks
    to aim for only one >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of two things: can they be persuaded to say enough
    to show others that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> they are wrong (for example PO admission that H(P,P)
    == false is correct >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> despite the fact that P(P) halts), >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    If it is the case that the simulated input to H
    cannot possibly reach >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its own final state under any condition what-so-ever
    then H correctly >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maps this finite string input to its reject state and
    nothing in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> universe can correctly contradict that H is correct.

    If you have a white dog in your living room and
    everyone in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> universe disagrees, you still have a white dog in
    your living room. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Good to see that you are still asserting that false is
    the correct >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> result from a halt decider for at least one halting
    computation. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    If the input to the halt decider specifies a
    non-halting sequence of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations then any damn thing anywhere else is
    totally >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevant. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If P(P) halts, H(P,P) should be true. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Like I said any damn thing else is actually 100%
    perfectly totally >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevant. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes! The only thing that matters is whether the "input",
    (P,P),
    specifies a halting computation or not. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    The "input" to H is two >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> parameters that specify the halting computation P(P).

    A halting computation that cannot possibly reach its own
    final state >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> under any condition what-so-ever? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Either P(P) halts or it does not. Did you tell a fib when
    you said it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does? Since it halts, H(P,P) == false is wrong.

    The input to H(P,P) cannot possibly reach its own final
    state under >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any condition what-so-ever, thus if God and all his
    angels and every >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> being great and small said that the input to H specifies
    a halting >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation they would all be liars. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You told that us P(P) halts. Until you retract that, I
    will take it to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be true. You also told us that H(P,P) == false. Do you
    need to correct >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one or other of these statements? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    As long as the input to H(P,P) never reaches its final
    state under any >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> condition what-so-ever then no matter what P(P) does H was
    still
    correct because P(P) is not an input and H is only
    accountable for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> getting its inputs correctly. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    So what two arguments must be passed to H to get H to tell
    us whether
    P(P) halts or not? (Already asked, of course, but you a
    dodging this
    issue for obvious reasons.) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    You won't understand what I am saying until you first
    understand that
    your question has nothing to do with the correctness of the
    rejection
    of the input.

    I am referring to a point that is so subtle that no one ever
    noticed
    this subtle point for 90 years. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    I WILL KEEP REPEATING THIS UNTIL YOU RESPOND >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Of course you will. You can't answer the question without being
    obviously wrong,
    THIS PROVES THAT I AM CORRECT >>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to embedded_H
    can
    never possibly reach its own final state under any condition at
    all.
    Therefore embedded_H is necessarily correct to reject its input.
    I will not talk to you about anything besides that.

    The input to UTM applied to <H^><H^> >>>>>>>>>>>>>>>>>>>>>>>>>>> Is not what I am talking about. >>>>>>>>>>>>>>>>>>>>>>>>>>>

    You said "under any condition at all", >>>>>>>>>>>>>>>>>>>>>>>>> Within the scope of embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
    Should I just ignore your next 20 replies? >>>>>>>>>>>>>>>>>>>>>>>>
    So embedded_H, and therefore H, is the sole source of truth for if
    it's input reaches a final state? >>>>>>>>>>>>>>>>>>>>>>> The scope only includes embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ and explicitly
    excludes everything else in the whole universe. >>>>>>>>>>>>>>>>>>>>>>
    So you're saying and embedded_H and H give different output for the
    same input?

    I am saying that H is off topic bitch. >>>>>>>>>>>>>>>>>>>>>
    STFU about it.

    In other words,
    I absolutely positively will not tolerate the most microscopic
    divergence from: embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>>>>>>>>>>>>
    Any replies with microscopic divergences will simply be ignored.

    So you've implicitly agreed that embedded_H and H are the same,
    I have done no such thing.

    Until you provide an example of H and embedded_H giving different results from the same input, yes you have.
    Liar !!!

    This is when everyone watching sees that you know you don't have a case.
    If I tolerate the slightest microscopic divergence from the point at
    hand you will never understand what I am saying in a million years.

    STFU about H !!!
    It is the case that the correctly simulated input to embedded_H can
    never possibly reach its own final state under any condition at all.
    Therefore embedded_H is necessarily correct to reject its input. >>>>>>>>>>>
    Because embedded_H is the same as H
    Because the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H specifies a non-halting
    sequence of configurations

    It does not:

    So the simulated input can possibly reach its own final state?

    Yep.
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

    Show exactly where in this execution trace that the simulated ⟨Ĥ0⟩ would
    transition to ⟨Ĥ0.y⟩ or ⟨Ĥ0.n⟩.

    Ĥ is applied to ⟨Ĥ0⟩
    (a) Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
    (b) H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
    Then these steps would keep repeating:
    (c) Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
    (d) Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩

    Now you're talking about Hn which never aborts.
    All that I am saying is that if the simulated ⟨Ĥ0⟩ cannot possibly reach
    its own final state of ⟨Ĥ0.y⟩ or ⟨Ĥ0.n⟩ then that proves that it is not
    a halting computation.

    You are saying know I must be wrong because that goes against your
    intuition.

    SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
    SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
    SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
    SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
    SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩

    ⟨Ĥn0⟩ never does transition to a final state. And yes Ĥn applies to ⟨Ĥn⟩ does not halt. But Hn is unable to report that fact because it can't abort its simulation and is therefore wrong by default.
    The fact that the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H cannot possibly reach its
    final state under any condition what-so-ever conclusively proves that it
    is not a halting computation.

    Yes, we agree that ⟨Ĥn⟩ ⟨Ĥn⟩ is non-halting. But Hn can't report that.

    When embedded_H rejects its input it is necessary 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 Ben Bacarisse on Thu Apr 7 18:45:27 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    THIS PROVES THAT I AM CORRECT
    It is the case that the correctly simulated input to embedded_H can
    never possibly reach its own final state under any condition at all.
    Therefore embedded_H is necessarily correct to reject its input.

    Yet you won't answer two simple questions! Why?

    Because I absolutely positively will not tolerate divergence from
    validating my 17 years worth of work.

    But you have no choice but to tolerate it. If someone wants to talk
    about why you are wrong, they will do so.

    You are wrong (for the C version of H) because H(P,P) == false but P(P) halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
    qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
    any of these facts if the mood takes you.)


    If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩ reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ then you must show how this occurs.

    Ĥ is applied to ⟨Ĥ0⟩
    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
    H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
    Then these steps would keep repeating:
    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩

    From these four steps we can see that the simulated ⟨Ĥ0⟩ never reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ thus never halts.



    --
    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 Thu Apr 7 18:23:09 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/7/2022 6:16 PM, André G. Isaak wrote:
    On 2022-04-07 17:04, olcott wrote:
    On 4/7/2022 6:00 PM, André G. Isaak wrote:
    On 2022-04-07 16:55, olcott wrote:
    On 4/7/2022 5:36 PM, André G. Isaak wrote:
    On 2022-04-07 15:17, olcott wrote:

    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

    Show exactly where in this execution trace that the simulated ⟨Ĥ0⟩ >>>>>> would transition to ⟨Ĥ0.y⟩ or ⟨Ĥ0.n⟩.

    That isn't an 'execution trace'. It's a bare-bones outline of what
    happens. Moreover, it is not an *accurate* outline of what happens.

    Ĥ is applied to ⟨Ĥ0⟩
        (a) Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
        (b) H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩

    Your (b) should read H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩ until either Ĥ0 ⟨Ĥ1⟩ is
    completed (in which case the computation goes to H.qy) or until H
    decides to discontinue the simulation (in which case the
    computation goes to H.qn and halts)

    Then these steps would keep repeating:
        (c) Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Again, your (c) should read Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then
    H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩ until either Ĥ1 ⟨Ĥ2⟩ is completed (in which
    case the computation goes to H0.qy) or until H0 decides to abort
    the simulation. (in which case the computation goes to H0.qn and
    halts)

        (d) Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩

    And again, this is inaccurate. I'll leave fixing it as an exercise
    for you.


    Your "corrections" are totally incorrect.

    How so? They are based entirely on *your* description of how your
    alleged halt decider works.

    André


    These are the actual first four steps.

    Ĥ is applied to ⟨Ĥ0⟩
        Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
        H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
    Then these steps would keep repeating:
        Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
        Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩

     From these four steps we can see that ⟨Ĥ0⟩ never reaches its final
    state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ thus never halts.

    If those are the actual steps, then how on earth does the topmost H
    manage to "correctly" decide that its input is non-halting?

    According to what you write above the topmost H simply simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩ which, according to you, never ends, meaning the topmost H also never ends.

    The "trace" you give above is what you would get if H were an actual
    UTM. But H *isn't* a UTM, it is a simulating halt decider. Ergo its
    behaviour won't match that of a UTM.

    André


    The whole point here is that the simulated ⟨Ĥ0⟩ never reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ thus never halts.

    All of the other things that you bring up are mere distractions away
    from this actual point.


    --
    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 Fri Apr 8 11:09:01 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/7/2022 5:51 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 6:46:37 PM UTC-4, olcott wrote:
    On 4/7/2022 5:18 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 5:51:41 PM UTC-4, olcott wrote:
    On 4/7/2022 4:37 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 5:17:44 PM UTC-4, olcott wrote:
    On 4/7/2022 3:21 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 4:04:48 PM UTC-4, olcott wrote:
    On 4/7/2022 3:00 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 3:58:03 PM UTC-4, olcott wrote: >>>>>>>>>> On 4/7/2022 2:38 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 3:19:03 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 4/7/2022 2:07 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 2:54:57 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 4/7/2022 1:51 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 2:47:53 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>> On 4/7/2022 1:45 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 2:24:01 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>>>> On 4/7/2022 1:08 PM, Dennis Bush wrote:
    On Thursday, April 7, 2022 at 2:04:41 PM UTC-4, olcott wrote:
    On 4/7/2022 1:00 PM, olcott wrote:
    On 4/7/2022 12:59 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 1:37:20 PM UTC-4, olcott wrote:
    On 4/7/2022 12:09 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 1:02:27 PM UTC-4, olcott wrote:
    On 4/7/2022 11:52 AM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 12:16:56 PM UTC-4, olcott wrote:
    On 4/7/2022 9:45 AM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 10:35:31 AM UTC-4, olcott wrote:
    On 4/7/2022 5:58 AM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 4/6/2022 8:49 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 4/6/2022 7:34 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 4/6/2022 6:35 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 4/6/2022 4:36 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 4/6/2022 9:19 AM, Ben Bacarisse wrote:

    As for the main mistake, I know enough about cranks
    to aim for only one >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of two things: can they be persuaded to say enough
    to show others that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> they are wrong (for example PO admission that H(P,P)
    == false is correct >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> despite the fact that P(P) halts), >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    If it is the case that the simulated input to H
    cannot possibly reach >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its own final state under any condition what-so-ever
    then H correctly >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maps this finite string input to its reject state and
    nothing in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> universe can correctly contradict that H is correct.

    If you have a white dog in your living room and
    everyone in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> universe disagrees, you still have a white dog in
    your living room. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Good to see that you are still asserting that false is
    the correct >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> result from a halt decider for at least one halting
    computation. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    If the input to the halt decider specifies a
    non-halting sequence of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations then any damn thing anywhere else is
    totally >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevant. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If P(P) halts, H(P,P) should be true. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Like I said any damn thing else is actually 100%
    perfectly totally >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevant. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes! The only thing that matters is whether the "input",
    (P,P),
    specifies a halting computation or not. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    The "input" to H is two >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> parameters that specify the halting computation P(P).

    A halting computation that cannot possibly reach its own
    final state >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> under any condition what-so-ever? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Either P(P) halts or it does not. Did you tell a fib when
    you said it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does? Since it halts, H(P,P) == false is wrong.

    The input to H(P,P) cannot possibly reach its own final
    state under >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any condition what-so-ever, thus if God and all his
    angels and every >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> being great and small said that the input to H specifies
    a halting >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation they would all be liars. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You told that us P(P) halts. Until you retract that, I
    will take it to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be true. You also told us that H(P,P) == false. Do you
    need to correct >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one or other of these statements? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    As long as the input to H(P,P) never reaches its final
    state under any >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> condition what-so-ever then no matter what P(P) does H was
    still
    correct because P(P) is not an input and H is only
    accountable for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> getting its inputs correctly. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    So what two arguments must be passed to H to get H to tell
    us whether
    P(P) halts or not? (Already asked, of course, but you a
    dodging this
    issue for obvious reasons.) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    You won't understand what I am saying until you first
    understand that
    your question has nothing to do with the correctness of the
    rejection
    of the input.

    I am referring to a point that is so subtle that no one ever
    noticed
    this subtle point for 90 years. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    I WILL KEEP REPEATING THIS UNTIL YOU RESPOND >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Of course you will. You can't answer the question without being
    obviously wrong,
    THIS PROVES THAT I AM CORRECT >>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to embedded_H
    can
    never possibly reach its own final state under any condition at
    all.
    Therefore embedded_H is necessarily correct to reject its input.
    I will not talk to you about anything besides that.

    The input to UTM applied to <H^><H^> >>>>>>>>>>>>>>>>>>>>>>>>>>> Is not what I am talking about. >>>>>>>>>>>>>>>>>>>>>>>>>>>

    You said "under any condition at all", >>>>>>>>>>>>>>>>>>>>>>>>> Within the scope of embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
    Should I just ignore your next 20 replies? >>>>>>>>>>>>>>>>>>>>>>>>
    So embedded_H, and therefore H, is the sole source of truth for if
    it's input reaches a final state? >>>>>>>>>>>>>>>>>>>>>>> The scope only includes embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ and explicitly
    excludes everything else in the whole universe. >>>>>>>>>>>>>>>>>>>>>>
    So you're saying and embedded_H and H give different output for the
    same input?

    I am saying that H is off topic bitch. >>>>>>>>>>>>>>>>>>>>>
    STFU about it.

    In other words,
    I absolutely positively will not tolerate the most microscopic
    divergence from: embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>>>>>>>>>>>>
    Any replies with microscopic divergences will simply be ignored.

    So you've implicitly agreed that embedded_H and H are the same,
    I have done no such thing.

    Until you provide an example of H and embedded_H giving different results from the same input, yes you have.
    Liar !!!

    This is when everyone watching sees that you know you don't have a case.
    If I tolerate the slightest microscopic divergence from the point at
    hand you will never understand what I am saying in a million years.

    STFU about H !!!
    It is the case that the correctly simulated input to embedded_H can
    never possibly reach its own final state under any condition at all.
    Therefore embedded_H is necessarily correct to reject its input. >>>>>>>>>>>
    Because embedded_H is the same as H
    Because the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H specifies a non-halting
    sequence of configurations

    It does not:

    So the simulated input can possibly reach its own final state?

    Yep.
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

    Show exactly where in this execution trace that the simulated ⟨Ĥ0⟩ would
    transition to ⟨Ĥ0.y⟩ or ⟨Ĥ0.n⟩.

    Ĥ is applied to ⟨Ĥ0⟩
    (a) Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
    (b) H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
    Then these steps would keep repeating:
    (c) Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
    (d) Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩

    Now you're talking about Hn which never aborts.
    All that I am saying is that if the simulated ⟨Ĥ0⟩ cannot possibly reach
    its own final state of ⟨Ĥ0.y⟩ or ⟨Ĥ0.n⟩ then that proves that it is not
    a halting computation.

    You are saying know I must be wrong because that goes against your
    intuition.

    SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
    SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
    SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
    SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
    SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩

    ⟨Ĥn0⟩ never does transition to a final state. And yes Ĥn applies to ⟨Ĥn⟩ does not halt. But Hn is unable to report that fact because it can't abort its simulation and is therefore wrong by default.
    The fact that the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H cannot possibly reach its
    final state under any condition what-so-ever conclusively proves that it
    is not a halting computation.

    Yes, we agree that ⟨Ĥn⟩ ⟨Ĥn⟩ is non-halting.

    Conclusively proving that embedded_H would be correct when it rejects
    its input.

    If {an X is a Y} then when {Z says} that {an X is a Y} Z is necessarily correct.

    {an X is a Y} = "the input to embedded_H is non-halting."
    {Z says} = "embedded_H rejects its input."

    --
    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 Fri Apr 8 13:04:59 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/8/2022 12:44 PM, André G. Isaak wrote:
    On 2022-04-08 11:02, olcott wrote:

    I asked about Ĥ0 and you answered with Ĥn which includes Ĥ[0...n].

    You need to go back to the point where Dennis defined his Ha and Hn.
    They don't mean what you seem to think they mean.

    André


    The fact that they do not mean embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is enough
    to know that they must be utterly rejected out-of-hand.

    That the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H is non-halting is the only thing
    that is relevant to the correctness of embedded_H rejecting this input.

    Everything else is the God damned lie of a God damned liar.

    When I say "God damned" I mean in the sense of being eternally
    incinerated in actual Hell.

    Revelation 21:8 King James Version
    ...all liars, shall have their part in the lake which burneth with fire
    and brimstone: which is the second death.


    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Fri Apr 8 13:49:26 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/8/2022 1:29 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    Linz makes this difficult to understand because he simply erases key
    elements of the definition of Ĥ:

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    You have erased them. Linz specifies Ĥ properly based on what H is
    supposed to do:

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.

    You have spent an inordinate amount of time over the years copying out
    those lines and dishonestly removing the key conditions. We all know
    why.


    <Linz:1990:320>
    Now Ĥ is a Turing machine, so that it will have some description in
    Σ*, say ŵ. This string, in addition to being the description of Ĥ can
    also be used as input string. We can therefore legitimately ask what
    would happen if Ĥ is applied to ŵ.

    q0ŵ ⊢* Ĥ ∞
    if Ĥ applied to ŵ halts, and

    q0ŵ ⊢* Ĥy1qny2
    if Ĥ applied to ŵ does not halt. This is clearly nonsense. The
    contradiction tells us that...
    </Linz:1990:320>

    In other words the copy of H embedded within Ĥ is incorrect to either
    reject or accept its input.

    When I show that embedded_H correctly rejects its input ⟨Ĥ⟩ ⟨Ĥ⟩ I have
    correctly refuted Linz.

    Because the simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H is non-halting when embedded_H rejects this input as non-halting it is necessarily 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 Dennis Bush on Fri Apr 8 14:51:29 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/8/2022 2:38 PM, Dennis Bush wrote:
    On Friday, April 8, 2022 at 3:20:35 PM UTC-4, olcott wrote:
    On 4/8/2022 2:16 PM, Dennis Bush wrote:
    On Friday, April 8, 2022 at 2:49:36 PM UTC-4, olcott wrote:
    On 4/8/2022 1:29 PM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    Linz makes this difficult to understand because he simply erases key >>>>>> elements of the definition of Ĥ:

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    You have erased them. Linz specifies Ĥ properly based on what H is
    supposed to do:

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.

    You have spent an inordinate amount of time over the years copying out >>>>> those lines and dishonestly removing the key conditions. We all know >>>>> why.

    <Linz:1990:320>
    Now Ĥ is a Turing machine, so that it will have some description in
    Σ*, say ŵ. This string, in addition to being the description of Ĥ can >>>> also be used as input string. We can therefore legitimately ask what
    would happen if Ĥ is applied to ŵ.

    q0ŵ ⊢* Ĥ ∞
    if Ĥ applied to ŵ halts, and

    q0ŵ ⊢* Ĥy1qny2
    if Ĥ applied to ŵ does not halt. This is clearly nonsense. The
    contradiction tells us that...
    </Linz:1990:320>

    In other words the copy of H embedded within Ĥ is incorrect to either >>>> reject or accept its input.

    What you fail to notice is that there is more than one H and H^ in play. For example:

    A: an H that always accepts
    R: an H that always rejects

    What the above is saying is that R / embedded_R rejecting <R^><R^> is incorrect and that A / embedded_A accepting <A^><A^> is incorrect. So not a *single* H but two *different* H's. This also means that A accepting <R^><R^> is correct and R rejecting
    <A^><A^> is correct.

    In other words, no H can give a correct halting/non-halting answer for an H^ built from it (even though some other H could).
    So when I show that the H embedded within Ĥ does correctly decide its
    input ⟨Ĥ⟩ ⟨Ĥ⟩, Linz has been refuted.


    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

    When Ĥ is applied to ⟨Ĥ0⟩
    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
    H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
    Then these steps would keep repeating:
    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩

    Since we can see that the simulated input: ⟨Ĥ0⟩ to embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ we know that it is non-halting.


    --
    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 Fri Apr 8 20:01:13 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/8/2022 7:44 PM, Richard Damon wrote:
    On 4/8/22 7:34 PM, olcott wrote:
    On 4/8/2022 6:31 PM, Richard Damon wrote:

    On 4/8/22 6:51 PM, olcott wrote:
    On 4/8/2022 4:49 PM, Dennis Bush wrote:
    On Friday, April 8, 2022 at 5:40:42 PM UTC-4, olcott wrote:
    On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    THIS PROVES THAT I AM CORRECT
    It is the case that the correctly simulated input to >>>>>>>>>>>>>> embedded_H can
    never possibly reach its own final state under any >>>>>>>>>>>>>> condition at all.
    Therefore embedded_H is necessarily correct to reject its >>>>>>>>>>>>>> input.

    Yet you won't answer two simple questions! Why?

    Because I absolutely positively will not tolerate divergence >>>>>>>>>>>> from
    validating my 17 years worth of work.

    But you have no choice but to tolerate it. If someone wants >>>>>>>>>>> to talk
    about why you are wrong, they will do so.

    You are wrong (for the C version of H) because H(P,P) == >>>>>>>>>>> false but P(P)
    halts. You are wrong about your TM H because H <Ĥ> <Ĥ> >>>>>>>>>>> transitions to
    qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free >>>>>>>>>>> to deny
    any of these facts if the mood takes you.)

    If you believe (against the verified facts) that the simulated >>>>>>>>>> ⟨Ĥ0⟩
    reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...

    I believe what you've told me: that you claim that
    H(P,P)==false is
    correct despite the fact that P(P) halts. That's wrong.

    If the input to H(P,P) cannot possibly reach its final state
    then this
    input is correctly rejected and nothing in the universe can
    possibly
    contradict this.

    Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute >>>>>>> either (indeed they come from you).

    Your new line in waffle is just an attempt to distract attention >>>>>>> from a
    very simple claim: that the wrong answer is the right one.

    Even Linz got this wrong because it is counter-intuitive.

    A halt decider must compute the mapping from its inputs (not any damn >>>>>> thing else in the universe) to its own final state on the basis of >>>>>>
    the behavior specified by these inputs

    Which is stipulated to be H^ applied to <H^>


    When Ĥ is applied to ⟨Ĥ0⟩
        Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
        H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
    Then these steps would keep repeating:
        Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
        Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩

    Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H >>>> reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.



    If that IS the proper trace, then it doesn't, but H and embedded_H
    have also failed to decide, because they will NEVER 'abort' their
    simulation and return an answer.
    That is a proper trace and in the next step embedded_H aborts the
    simulation of its input and transitions to its reject state.



    Then the words "Keep on Repeating" are a LIE.


    I needed my readers to get one single point from the above sequence that
    the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its own final
    state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.

    It has taken you about three months to get this one single point.

    Now that you have gotten this point we move on to the next step,
    embedded_H aborts its simulation and transitions to its own reject state.


    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben on Mon Apr 11 19:07:55 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/11/2022 6:55 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/10/2022 7:05 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/10/2022 4:18 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/10/2022 10:52 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/7/2022 10:51 AM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:

    THIS PROVES THAT I AM CORRECT
    It is the case that the correctly simulated input to embedded_H can
    never possibly reach its own final state under any condition at all.
    Therefore embedded_H is necessarily correct to reject its input.

    Yet you won't answer two simple questions! Why? >>>>>>>>>>>>>>>>>>
    Because I absolutely positively will not tolerate divergence from
    validating my 17 years worth of work.

    But you have no choice but to tolerate it. If someone wants to talk
    about why you are wrong, they will do so.

    You are wrong (for the C version of H) because H(P,P) == false but P(P)
    halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
    qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
    any of these facts if the mood takes you.)

    If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
    reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩... >>>>>>>>>>>>>>>
    I believe what you've told me: that you claim that H(P,P)==false is
    correct despite the fact that P(P) halts. That's wrong. >>>>>>>>>>>>>>
    If the input to H(P,P) cannot possibly reach its final state then this
    input is correctly rejected and nothing in the universe can possibly
    contradict this.

    Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
    either (indeed they come from you).
    At least you don't contend these facts.

    Your new line in waffle is just an attempt to distract attention from a
    very simple claim: that the wrong answer is the right one. >>>>>>>>>>>>
    Even Linz got this wrong because it is counter-intuitive. >>>>>>>>>>>>
    A halt decider must compute the mapping from its inputs (not any damn
    thing else in the universe) to its own final state on the basis of the
    behavior specified by these inputs

    That's not counter intuitive, it's basic. Everyone knows this, though
    it took you a while to get round to it. A halt decider accepts or >>>>>>>>>>> rejects a string based on the behaviour of the computation specified by
    that string. Of course, you never got as far in my exercises as >>>>>>>>>>> specifying any TM that decides something on the basis of behaviour, so
    you really don't know how it's actually done. That was, I thought, the
    whole point of the exercises -- to see how TMs are specified to decide
    properties of computations.

    You have to actually pay attention to this,

    Flip, flop! Back to being wrong about TMs rather than being wrong about
    your old C junk. These uncontested facts: (1) H(P,P) == false, (2) P(P)
    halts are why your H and P are wrong.

    If you are able to break the problem down to it micro component parts >>>>>>>> and carefully analyze each of these separately instead of simply >>>>>>>> slipping down the slide of intuition then you can see that I am >>>>>>>> correct.

    If it is true that the correct simulation input to H(P,P) cannot >>>>>>>> possibly reach its own final state then

    The input to H(P,P) is non-halting then
    There is no "input to H(P,P)".

    The correct simulation of the input to H
    Better. I still would not call it "input" (since these are C functions) >>>>> but you've got the hang of what am saying. Well done.

    cannot possibly ever reach it final state thus is a non-halting
    sequence of configurations even if everyone and everything in the
    universe disagrees.

    The truth is not determined by who does or does not agree with
    something. But to find the truth of the matter you must first stop
    talking literal nonsense. The arguments to H (what you call the
    "input") are two pointers. What does simulating two pointers mean?
    What you mean, I hope, is simulating calling the first pointer with the >>>>> second as it's argument. That simulation, according to you, will halt >>>>> (or "reach it's final state" in your flamboyant, sciencey, language). >>>>> It will halt because the direct call P(P) halts. Everything here halts >>>>> (according to you). That's why H is wrong.

    You simply are ignoring the actual execution trace that conclusively
    proves that the simulated input to H cannot possibly reach its final
    own state.
    The traces that matter are the one of P(P) halting (you made the mistake >>> of posting it once), and the one of H(P,P) return false (you posted that >>> as well). You a free to retract any of these at any time, but until you >>> do, your H is wrong by your own supplied traces.


    It is never the case that the simulated input to H(P,P) ever reaches
    its own final state.

    Waffle. HP(P) halts so (P,P) == false is wrong. You can retract these
    facts (since they come from you in the first place). Until then, you've
    told us that your H is wrong.


    It is the case that the simulated input never reaches its [00000970]
    machine address, no waffle there merely an easily verified fact.

    _P()
    [00000956](01) 55 push ebp
    [00000957](02) 8bec mov ebp,esp
    [00000959](03) 8b4508 mov eax,[ebp+08]
    [0000095c](01) 50 push eax
    [0000095d](03) 8b4d08 mov ecx,[ebp+08]
    [00000960](01) 51 push ecx
    [00000961](05) e8c0feffff call 00000826 // H(P,P)

    // The above (as simulated input) keeps repeating until aborted.

    [00000966](03) 83c408 add esp,+08
    [00000969](02) 85c0 test eax,eax
    [0000096b](02) 7402 jz 0000096f
    [0000096d](02) ebfe jmp 0000096d
    [0000096f](01) 5d pop ebp
    [00000970](01) c3 ret
    Size in bytes:(0027) [00000970]

    It is self-evident that the actual behavior of the actual simulated
    input is the ULTIMATE MEASURE of the correctness of any halt decider.


    --
    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 Mon Apr 11 21:03:11 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/11/2022 8:36 PM, Dennis Bush wrote:
    On Monday, April 11, 2022 at 9:21:59 PM UTC-4, olcott wrote:
    On 4/11/2022 8:17 PM, Ben wrote:
    olcott <No...@NoWhere.com> writes:

    On 4/11/2022 6:52 PM, Ben wrote:
    olcott <No...@NoWhere.com> writes:

    On 4/10/2022 7:00 PM, Ben wrote:
    olcott <No...@NoWhere.com> writes:

    On 4/10/2022 4:41 PM, Ben wrote:
    olcott <No...@NoWhere.com> writes:

    The above means this:
    Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
    Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
    That's funny! You really have no idea what this notation means, do you?

    embedded_H is a simulating halt decider that has a full UTM embedded >>>>>>>>>> within it. As soon as it sees that the pure UTM simulation of its >>>>>>>>>> input would never reach the final state of this input it aborts this >>>>>>>>>> simulation and rejects this non-halting input.

    So you had no business writing those two junk lines, did you? Or do you
    really think that they are in some way compatible with that last >>>>>>>>> paragraph? Probably neither. I really think you see it much like >>>>>>>>> poetry. Meanings are supposed to be intuited from unusual, often >>>>>>>>> metaphorical, juxtapositions of symbols.

    Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
    Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
    Still junk.


    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
    If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would reach its
    own final state.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
    If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would never
    reach its own final state.
    Still junk. Mixing embedded_H and H. Also H.qy is a final state so
    this is not the hat construction form Linz. Also uses triger word
    "would". What matters is what is the case, not what would be the case. >>>>> But, much like a poem, I can a feeling for what you might mean -- it's >>>>> the same old reject is correct because of what would happen if H (and >>>>> it's embedded copy) where not the TMs that actually are.
    To see why you are clearly wrong, just say what state H ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>> transitions to, and what string must be passed to H for H to tell us >>>>> whether Ĥ applied to ⟨Ĥ⟩ halts or not.

    The fact that I do not express myself perfectly does not freaking mean >>>> that the key essence of all my ideas is not exactly correct.

    Absolutely right. The reason the key essence of all my ideas is known
    to be wrong is because you have, occasionally, been clear.
    I addressed this in my other reply to you.

    I am only talking about H(P,P) now because if someone imagines that it
    does differently that it does an actual execution trace proves that they
    are incorrect as a matter of objective fact with zero room for debate.

    Translation:

    "People are finding so many holes in my logic on Turing machines

    There is an inherent hole the the logic specified by Linz
    Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
    Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qn

    The Linz text basically says "magic happens here" ⊢*
    at the second wild card state transition shown above: https://www.liarparadox.org/Linz_Proof.pdf

    With H(P,P) we see exactly what the x86 emulator sees and both what H
    should do and why it does it.

    Pages 4-5 https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation


    that I don't know how to respond them all without admitting I'm wrong, so I'm going to change the way I talk about the problem in hopes I can hide my errors better."


    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben on Mon Apr 11 20:17:44 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/11/2022 8:02 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/11/2022 6:55 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/10/2022 7:05 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/10/2022 4:18 PM, Ben wrote:

    The truth is not determined by who does or does not agree with
    something. But to find the truth of the matter you must first stop >>>>>>> talking literal nonsense. The arguments to H (what you call the >>>>>>> "input") are two pointers. What does simulating two pointers mean? >>>>>>> What you mean, I hope, is simulating calling the first pointer with the >>>>>>> second as it's argument. That simulation, according to you, will halt >>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language). >>>>>>> It will halt because the direct call P(P) halts. Everything here halts >>>>>>> (according to you). That's why H is wrong.

    You simply are ignoring the actual execution trace that conclusively >>>>>> proves that the simulated input to H cannot possibly reach its final >>>>>> own state.
    The traces that matter are the one of P(P) halting (you made the mistake >>>>> of posting it once), and the one of H(P,P) return false (you posted that >>>>> as well). You a free to retract any of these at any time, but until you >>>>> do, your H is wrong by your own supplied traces.

    It is never the case that the simulated input to H(P,P) ever reaches
    its own final state.

    Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
    typo: "so H(P,P) == false is wrong"
    these facts (since they come from you in the first place). Until
    then, you've told us that your H is wrong.

    It is the case that the simulated input never reaches its [00000970]
    machine address, no waffle there merely an easily verified fact.

    You can verify a thousand more irrelevant facts. The facts that matter
    are already known: that P(P) halts and that H(P,P) == false. Are you presenting any verified facts that corrects this mistake? If so, just
    say and I'll stop quoting it.


    The sequence of configurations specified by P(P) intuitively seems like
    it must be identical to the correct simulation of the input to H(P,P).
    It turns out that intuition is incorrect.

    It is the case that the input to H(P,P) never halts and it is the case
    the P(P) halts because these are different computations they need not
    have the same behavior.

    When you actually examine the actual behavior of the correctly simulated
    input to H(P,P) then we can see that it is an easily verified fact that
    this input would never halt: AKA reach machine address [00000970].

    _P()
    [00000956](01) 55 push ebp
    [00000957](02) 8bec mov ebp,esp
    [00000959](03) 8b4508 mov eax,[ebp+08]
    [0000095c](01) 50 push eax // push P
    [0000095d](03) 8b4d08 mov ecx,[ebp+08]
    [00000960](01) 51 push ecx // push P
    [00000961](05) e8c0feffff call 00000826 // call H(P,P)

    The above keeps repeating until aborted

    [00000966](03) 83c408 add esp,+08
    [00000969](02) 85c0 test eax,eax
    [0000096b](02) 7402 jz 0000096f
    [0000096d](02) ebfe jmp 0000096d
    [0000096f](01) 5d pop ebp
    [00000970](01) c3 ret // final state.
    Size in bytes:(0027) [00000970]




    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben on Tue Apr 12 21:49:23 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/12/2022 9:29 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/12/2022 9:02 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/12/2022 7:49 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/12/2022 8:06 AM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/11/2022 8:02 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/11/2022 6:55 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/10/2022 7:05 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/10/2022 4:18 PM, Ben wrote:

    The truth is not determined by who does or does not agree with >>>>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
    talking literal nonsense. The arguments to H (what you call the
    "input") are two pointers. What does simulating two pointers mean?
    What you mean, I hope, is simulating calling the first pointer with the
    second as it's argument. That simulation, according to you, will halt
    (or "reach it's final state" in your flamboyant, sciencey, language).
    It will halt because the direct call P(P) halts. Everything here halts
    (according to you). That's why H is wrong.

    You simply are ignoring the actual execution trace that conclusively
    proves that the simulated input to H cannot possibly reach its final
    own state.
    The traces that matter are the one of P(P) halting (you made the mistake
    of posting it once), and the one of H(P,P) return false (you posted that
    as well). You a free to retract any of these at any time, but until you
    do, your H is wrong by your own supplied traces.

    It is never the case that the simulated input to H(P,P) ever reaches
    its own final state.

    Waffle. HP(P) halts so (P,P) == false is wrong. You can retract >>>>>>>>> typo: "so H(P,P) == false is wrong"
    these facts (since they come from you in the first place). Until >>>>>>>>>>> then, you've told us that your H is wrong.

    It is the case that the simulated input never reaches its [00000970] >>>>>>>>>> machine address, no waffle there merely an easily verified fact. >>>>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
    are already known: that P(P) halts and that H(P,P) == false. Are you >>>>>>>>> presenting any verified facts that corrects this mistake? If so, just
    say and I'll stop quoting it.

    The sequence of configurations specified by P(P) intuitively seems >>>>>>>> like it must be identical to the correct simulation of the input to >>>>>>>> H(P,P). It turns out that intuition is incorrect.

    So which fact are you retracting? That P(P) halts or that H(P,P) == >>>>>>> false?

    As long as the correctly simulated input to H(P,P) cannot possibly >>>>>> reach the final state of this input then we know that it never halts >>>>>> even if everyone in the universe disagrees.

    So you plan to keep posting the same sentence in an attempt to take
    the focus off the fact that H is obviously wrong?

    Then you must mean
    WHOOP! WHOOP! WHOOP! Danger Will Robinson.
    You should avoid trying to paraphrase other people. Your replies
    suggest you don't often understand the various points being put to you,
    so when you try to re-word them the results are usually bogus.

    that a correctly simulated input that would never reaches its own
    final state is still a computation that halts.

    I meant what I said. If you are not sure that I meant, asking
    well-chosen questions about it is the way to go.

    We know [by definition] that a correctly simulated input that would
    never reach its own final state is not a halting computation.

    Deception alert: "would" rather than "does".

    A simulating halt decider cannot wait for an otherwise infinite sequence
    of configurations to end, so "would" is correct.

    Also, delete "correctly".

    Without the word "correctly" People simply stick to the view that it
    must be incorrect. I would use a different language for academia.

    You only need an adverb in the exceptional case: "incorrectly
    simulated", "partially simulated". Also the "input" to H are it's parameters. The parameters are both C pointers. What does it mean to simulate two pointers?

    We can't actually pass a finite string to a "C" function so we have to
    use pointers to strings.

    And "final state" is a term from Turing machines
    but H and P are C functions.


    I mean in in a perfectly analogous way.

    I'd re-word it in a sane way, but you'd reject my re-wording (I know
    because I did in a few years ago). This is all old hat.

    Are you saying that the definition of halting is incorrect?

    No. You don't know what it is, but it's not incorrect. You could try
    to say what it is, but I doubt you can without the long list of category errors above.


    I have already quoted this very many dozens of times:

    Are you saying that the correctly simulated input to H(P,P) does reach
    its own final state?

    Simulating P(P) and calling P(P) have the same halting status. They
    both halt or neither halts.


    I never bring this up because it always causes a short-circuit in your
    brain: The execution of P(P) is not computationally equivalent to the
    correct simulation of the input to H(P,P).

    That is why I focus on the X proves Y

    (X) We can verify that the simulated input to H(P,P) fails to meet the
    Linz definition of

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

    (Y) When H(P,P) returns false it is correct.

    I CAN'T POSSIBLE BE WRONG UNLESS THERE IS AN ESSENTIAL MISTAKE IN X OR Y.

    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben on Wed Apr 13 15:15:09 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/13/2022 2:38 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/13/2022 10:44 AM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/12/2022 9:37 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/12/2022 8:55 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/12/2022 7:47 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/12/2022 8:09 AM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/11/2022 8:17 PM, Ben wrote:
    I am only talking about H(P,P) now because if someone imagines that it
    does differently that it does an actual execution trace proves that
    they are incorrect as a matter of objective fact with zero room for
    debate.

    That's good because you have been 100% clear about H. It's wrong >>>>>>>>>>> because P(P) halts (according to you) and H(P,P) == false (according to
    you).

    Why do you insist that a halt decider must compute the mapping from >>>>>>>>>> non-inputs: P(P) when you know that it only computes the mapping from
    inputs H(P,P) ?

    I don't. H takes arguments (what you insist on calling inputs) and maps
    them to a result. The correct result is defined by people who know what
    the halting problem is -- you don't get to decide. You may never >>>>>>>>> understand the specification, but you only need to know one fact about
    it: mapping the "inputs" P and P to false is wrong.

    So in other words you are saying that mere opinions carry more weight >>>>>>>> than the following verified fact:

    The facts that (a) H(P,P) == false and (b) P(P) halts are not in dispute
    (so far as I know). That H mapping P and P to false is wrong is a >>>>>>> matter of definition. There are no opinions being expressed here at >>>>>>> all.

    So you agree that an input that never halts is a halting computation. >>>>> Don't be silly. As the culmination of 17 years of work, this looks
    pathetic. Either retract one of your previously asserted facts (that >>>>> P(P) halts or that H(P,P) == false) or say that your H is not deciding >>>>> halting, but something else.


    That is why I focus on the X proves Y
    You don't know what a proof is, remember? You still think that if
    {A,B,C} ⊦ X then {A,B,C,~X} ⊬ X.

    (X) We can verify that the simulated input to H(P,P) fails to meet the >>>> Linz definition of computation that halts … the Turing machine will
    halt whenever it enters a final state. (Linz:1990:234)
    No.

    (Y) When H(P,P) returns false it is correct.
    No.

    I CAN'T POSSIBLY BE WRONG UNLESS THERE IS AN ESSENTIAL MISTAKE IN X OR >>>> Y.
    Both. I give more detail (if you are interested) in another reply.


    Since what I said is true by logical necessity correct rebuttals are
    logically impossible.

    Why are you posting then? Time to publish your halt decider H that has H(P,P) == false and P(P) halting. Try the JACM. Make sure you put
    those undisputed facts at the top of the abstract.

    The simulated input to H(P,P) is non halting.

    Then you are either (a) doing it wrong, or (b) wrong to have said that
    P(P) halts. Oh, there is a third (c) you are using poetic license, and simulating the input means something silly. It's literal nonsense to
    there's a lot of scope for you make up some silly meaning.


    When mere rhetoric goes against easily verified facts rhetoric loses:
    (perhaps you don't have the slightest clue how the x86 language works)

    The simulated input to H(P,P) cannot possibly reach its own final state
    it keeps repeating [00000956] to [00000961] until aborted.

    _P()
    [00000956](01) 55 push ebp
    [00000957](02) 8bec mov ebp,esp
    [00000959](03) 8b4508 mov eax,[ebp+08]
    [0000095c](01) 50 push eax // push P
    [0000095d](03) 8b4d08 mov ecx,[ebp+08]
    [00000960](01) 51 push ecx // push P
    [00000961](05) e8c0feffff call 00000826 // call H(P,P)
    The above keeps repeating until aborted


    [00000966](03) 83c408 add esp,+08
    [00000969](02) 85c0 test eax,eax
    [0000096b](02) 7402 jz 0000096f
    [0000096d](02) ebfe jmp 0000096d
    [0000096f](01) 5d pop ebp
    [00000970](01) c3 ret // final state.
    Size in bytes:(0027) [00000970]



    --
    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 Malcolm McLean on Thu Apr 14 09:36:33 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/14/2022 3:56 AM, Malcolm McLean wrote:
    On Thursday, 14 April 2022 at 01:37:11 UTC+1, olcott wrote:
    On 4/13/2022 6:02 PM, Ben wrote:
    olcott <No...@NoWhere.com> writes:

    On 4/13/2022 2:38 PM, Ben wrote:
    olcott <No...@NoWhere.com> writes:

    The simulated input to H(P,P) is non halting.

    Then you are either (a) doing it wrong, or (b) wrong to have said that >>>>> P(P) halts. Oh, there is a third (c) you are using poetic license, and >>>>> simulating the input means something silly. It's literal nonsense to >>>>> there's a lot of scope for you make up some silly meaning.

    When mere rhetoric goes against easily verified facts rhetoric loses:

    Your own claim: H(P,P) == false is "correct" even though P(P) halts.
    That's not rhetoric. You've been too clear about this attempt. You
    need to try a new ruse.

    Because the input to H(P,P) is non-halting then nothing in the universe
    can possibly contradict the fact that it is non-halting.
    The simulated input to H(P,P) cannot possibly reach its own final state
    it keeps repeating [00000956] to [00000961] until aborted.

    _P()
    [00000956](01) 55 push ebp
    [00000957](02) 8bec mov ebp,esp
    [00000959](03) 8b4508 mov eax,[ebp+08]
    [0000095c](01) 50 push eax // push P
    [0000095d](03) 8b4d08 mov ecx,[ebp+08]
    [00000960](01) 51 push ecx // push P
    [00000961](05) e8c0feffff call 00000826 // call H(P,P)
    The above keeps repeating until aborted


    [00000966](03) 83c408 add esp,+08
    [00000969](02) 85c0 test eax,eax
    [0000096b](02) 7402 jz 0000096f
    [0000096d](02) ebfe jmp 0000096d
    [0000096f](01) 5d pop ebp
    [00000970](01) c3 ret // final state.
    Size in bytes:(0027) [00000970]

    A simulator is a machine code program. When you examine its "execution
    trace" it looks nothing like the program it is simulating. You wouldn't
    know that it was a simulator or which program it was simulating, except by
    a most exhaustive analysis.

    So it's not clear what you have done. However, in posts many months ago, you mentioned removing the simulator code itself from the execution traces.

    Since if you use a simulating halt decider and apply the H_Hat, H_Hat construction to it, you get a nested series of simulations of simulations, which
    are eventually halted by the simulator, removing the simulator code itself from
    the execution traces makes it looks as though the code is caught in an infinite
    loop, when in fact it isn't.

    The simulated input does not need to be caught in an infinite loop, as
    long as it would never reach is own final state in an unlimited number
    of steps of simulation it fails to meet the Linz definition:

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

    thus making it a non-halting sequence of configurations.

    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben on Thu Apr 14 09:54:44 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/14/2022 9:30 AM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/13/2022 6:02 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 4/13/2022 2:38 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:

    The simulated input to H(P,P) is non halting.

    Then you are either (a) doing it wrong, or (b) wrong to have said that >>>>> P(P) halts. Oh, there is a third (c) you are using poetic license, and >>>>> simulating the input means something silly. It's literal nonsense to >>>>> there's a lot of scope for you make up some silly meaning.

    When mere rhetoric goes against easily verified facts rhetoric loses:

    Your own claim: H(P,P) == false is "correct" even though P(P) halts.
    That's not rhetoric. You've been too clear about this attempt. You
    need to try a new ruse.

    Because the input to H(P,P) is non-halting then nothing in the
    universe can possibly contradict the fact that it is non-halting.

    Being generous, the "input" to H in the call H(P,P) is just two
    pointers. They are neither halting nor non-halting -- they are just pointers.

    Up until, now I was prepared to take your words metaphorically, but
    since you duck the key question of what "the input to H(P,P) is
    non-halting" means,

    Sure when I make to to explain ever details many hundreds of times
    damned liars will say that I never mentioned any of this.

    The input to H is the only way that finite strings can be passed to a
    "C" function and points to the finite string of the machine code of P.

    The simulating halt decider H uses an x86 emulator to simulate its input
    (P,P) and finds that it would never reach its own final state in an
    unlimited number of simulated steps.

    This conclusively proves that this simulated input fails to match the
    Linz definition: computation that halts … the Turing machine will halt whenever it enters a final state. (Linz:1990:234)

    I will have start to take you are your word, though
    I have still guessed what you mean by "input to H(P,P)". I may have to
    start replying that "H does no I/O" if you keep using the silly term
    input.

    What we do know, for sure, is that H(P,P) == false even though P(P)
    halts. And that's wrong. And I can keep saying that even if you never explain your poetic use of language.



    As long as the correctly simulated input to H(P,P) would never halt then
    we know it is non-halting.

    Anyone that disagrees with this is a liar by definition.
    Anyone that disagrees with this is a liar by definition.
    Anyone that disagrees with this is a liar by definition.
    Anyone that disagrees with this is a liar by definition.
    Anyone that disagrees with this is a liar by definition.

    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben on Thu Apr 14 15:41:57 2022
    XPost: comp.theory, sci.logic, sci.math

    On 4/14/2022 3:28 PM, Ben wrote:
    olcott <NoOne@NoWhere.com> writes:
    As long as the correctly simulated input to H(P,P) would never halt
    then we know it is non-halting.

    Readers beware! Ask yourselves why PO does not say the simpler "never halts", but instead says "/would/ never halt". Why the implied
    subjunctive mood?

    A simulating halt decider must correctly predict the future behavior of
    of its simulated input. Many of my readers get confused and believe that
    an aborted simulation means that the simulated input has halted.

    To an academic audience of computer scientists I would simply say that
    the behavior of the simulated input to H(P,P) conclusively proves that
    it is non-halting.

    They would recognize the functional notation of H(P,P) indicating its
    input as is standard functional notation for all functions.

    _P()
    [00000956](01) 55 push ebp
    [00000957](02) 8bec mov ebp,esp
    [00000959](03) 8b4508 mov eax,[ebp+08]
    [0000095c](01) 50 push eax // push P
    [0000095d](03) 8b4d08 mov ecx,[ebp+08]
    [00000960](01) 51 push ecx // push P
    [00000961](05) e8c0feffff call 00000826 // call H(P,P)
    The above keeps repeating until aborted

    [00000966](03) 83c408 add esp,+08
    [00000969](02) 85c0 test eax,eax
    [0000096b](02) 7402 jz 0000096f
    [0000096d](02) ebfe jmp 0000096d
    [0000096f](01) 5d pop ebp
    [00000970](01) c3 ret // final state.
    Size in bytes:(0027) [00000970]


    --
    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)