On 3/8/22 8:00 AM, olcott wrote:
> On 3/7/2022 9:57 PM, Richard Damon wrote:
>> On 3/7/22 10:29 PM, olcott wrote:
>>> On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/7/2022 4:13 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 3/7/2022 1:16 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 3/7/2022 10:53 AM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> I'm getting bored so I will skip to the chase at the end..
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>>>> As long as the Linz Ĥ relationship to its halt determiner is
>>>>>>>>>>>>>>> maintained any damn thing that correctly determines that
>>>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ never
>>>>>>>>>>>>>>> halts defeats the Linz proof.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not "any damn thing", no.  It must be the supposed halt
>>>>>>>>>>>>>> determiner, H,
>>>>>>>>>>>>>> that correctly determines it.  Now that might be what you
>>>>>>>>>>>>>> are trying to
>>>>>>>>>>>>>> so say with the mysterious "its", but then putting in "any
>>>>>>>>>>>>>> damn thing"
>>>>>>>>>>>>>> is just daft.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> More clearly, if you have an TM H such that either
>>>>>>>>>>>>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on
>>>>>>>>>>>>>> input ⟨Ĥ⟩,
>>>>>>>>>>>>>> then you will have done the impossible thing what you
>>>>>>>>>>>>>> claimed to have
>>>>>>>>>>>>>> done more than three years ago.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>>        Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H
>>>>>>>>>>>>> simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>>>>        Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H
>>>>>>>>>>>>> simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>>>>        Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H
>>>>>>>>>>>>> simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>>>>>>>>>>        Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H
>>>>>>>>>>>>> simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>>>>>>>>>>
>>>>>>>>>>>> So, just to be 100% clear, you are /not/ claiming to have an
>>>>>>>>>>>> TM that
>>>>>>>>>>>> does either
>>>>>>>>>>>
>>>>>>>>>>> What I am claiming is that the above shows that if embedded_H
>>>>>>>>>>> rejected
>>>>>>>>>>> its input it would be correct.
>>>>>>>>>>
>>>>>>>>>> So what?  We are interested in the halting problem and your
>>>>>>>>>> claim to
>>>>>>>>>> have addressed the key case: to have an H such that either
>>>>>>>>>
>>>>>>>>> The copy of Linz H embedded at Ĥ.qx would correctly decide that
>>>>>>>>> its
>>>>>>>>> input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that
>>>>>>>>> says this
>>>>>>>>> is impossible.
>>>>>>>> No.  Linz's H is such that neither
>>>>>>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
>>>>>>>> nor
>>>>>>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on input ⟨Ĥ⟩,
>>>>>>>> is possible.
>>>>>>>
>>>>>>> Like I said I am not talking about H.
>>>>>>> I have not been talking about H for many months.
>>>>>> There's no need to keep repeating that.  I understand 100% that
>>>>>> you are
>>>>>> not talking about, and don't want to talk about, your H.
>>>>>> If you really don't want to talk about your H, don't reply.  I'll say
>>>>>> what I like about it in peace.  But you can't offer any response
>>>>>> to my
>>>>>> posts about it if you won't talk about it.
>>>>>
>>>>> I am only talking about the simulating halt decider that is embedded
>>>>> in the middle of the Linz Ĥ at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>
>>>> Oh, you are talking about Linz's H and Ĥ.  OK.  To "refute the proof"
>>>> (as you put it) you'd need a TM that that does either
>>>>
>>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
>>>> or
>>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on input ⟨Ĥ⟩
>>>>
>>>> But you don't (though you once said you did).  Unsurprisingly, the
>>>> proof
>>>> is solid.  Such an H is impossible.
>>>>
>>>>>>> Also the key thing that you make sure to ignore is that it is never
>>>>>>> the case that any decider reports on the behavior of the computation
>>>>>>> that contains itself. Decider's are not capable of reporting on the
>>>>>>> behavior of Turing machines they can only accept or reject finite
>>>>>>> string inputs.
>>>>>>
>>>>>> I don't ignore it, I tell you that you are wrong -- every time you
>>>>>> bring
>>>>>> it up.  What's more, I have, on multiple occasions, said that I can
>>>>>> offer you a series of exercises that, if you were to take them
>>>>>> seriously, might lead you to see why you are wrong.
>>>>>> This is one of your favourite themes.  You accuse people of ignoring
>>>>>> something that they have answered every time you bring it up.  But,
>>>>>> unlike a crank, I will answer it every time you ask: you are
>>>>>> wrong.  Of
>>>>>> course deciders are capable of reporting on the behaviour of Turing
>>>>>> machines.
>>>>
>>>> So are you not interested in this fundamental error anymore?  I suppose
>>>> you need to wait a bit before saying I'm ignoring this point again!
>>>>
>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>> if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its own
>>>>>>>>> final state
>>>>>>>>> in a finite number of steps.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>> if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
>>>>>>>>> own final
>>>>>>>>> state in any finite number of steps.
>>>>>>>>
>>>>>>>> Still don't care about this H of yours.  You hooked people in
>>>>>>>> with a lie
>>>>>>>> that you kept repeating: your H is Linz's H.  At least you've
>>>>>>>> come clean
>>>>>>>> now and are attempting a hand-waving definition of your H.
>>>>>> So the situation is
>>>>>
>>>>> That you cannot pay attention to the fact that when the simulating
>>>>> halt decider embedded within Linz Ĥ at Ĥ.qx would reject its input it
>>>>> would be correct and refute the Linz proof.
>>>>
>>>> No.  To "refute the proof" you need an H that does either
>>>>
>>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
>>>> or
>>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on input ⟨Ĥ⟩
>>>>
>>>> but you won't even talk about H!
>>>>
>>>> Anyway, with cranks, silence is often the only answer one can get, so I
>>>> can do no more than take your silence on this point as consent: you
>>>> have
>>>> no such TM and never did.
>>>>
>>>> After all, you've spent years walking back this claim, to the extent
>>>> that you were recently touting a decider for some made up problem of
>>>> your own that is not the halting problem.
>>>>
>>>>>> that no one cares about your H and you dare not talk
>>>>>> about it!  There is nothing substantive to discuss if you won't talk
>>>>>> about the big mistakes.
>>>>>>
>>>>>
>>>>> This is verbatim Linz except it has been adapted to my clearer
>>>>> notational conventions:
>>>>>
>>>>> <Linz quote>
>>>>>      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 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>
>>>>> if Ĥ applied to  ⟨Ĥ⟩ halts, and
>>>>>
>>>>>                   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
>>>>> contradiction tells us that our assumption of the existence of H, and
>>>>> hence the assumption of the decidability of the halting problem, must
>>>>> be false.
>>>>> </Linz quote>
>>>>>
>>>>> The copy of Linz H embedded at Ĥ.qx will be referred to as embedded_H
>>>>>
>>>>> Linz is confused into believing that embedded_H is reporting on the
>>>>> behavior of the computation that contains itself Ĥ applied to ⟨Ĥ⟩,
>>>>> rather than the behavior specified by its input: ⟨Ĥ⟩, ⟨Ĥ⟩.
>>>>
>>>> No he is not.  No mention at all is made of what embedded_H reports.
>>>> The nonsense is simply that
>>>>
>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* ∞     if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn  if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>
>>>> Your only hope of removing this contradiction is to change the
>>>> conditions on those lines.  That's the ruse you've been trying to pull
>>>> for months with your pompous "Halt status criterion measure", but I
>>>> suppose you've realised that won't wash so, at least for today, we are
>>>> back to Linz's H and his correct criterion: halting.
>>>>
>>>> But there was a time you made a bolder claim: to have an H that gave
>>>> the
>>>> correct answer for this one case -- a TM that does either
>>>>
>>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
>>>> or
>>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on input ⟨Ĥ⟩.
>>>>
>>>> But you no longer make that (impossible) claim.
>>>>
>>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>>
>>>> That you act like an over-tired six year old?  I do try to ignore that.
>>>>
>>>>> It is never the case that any decider reports on the behavior of the
>>>>> computation that contains itself. Deciders are not capable of
>>>>> reporting on the behavior of Turing machines they can only accept or
>>>>> reject finite string inputs.
>>>>
>>>> I keep addressing this.  Again: you are wrong, Deciders /are/
>>>> capable of
>>>> reporting on the behavior of Turing machines.
>>>
>>> Deciders only compute the mapping from input finite strings to accept
>>> or reject states. If you disagree please provide a link that proves
>>> that deciders compute mappings from non-input non-strings.
>>>
>>> If you don't disagree then you know that embedded_H does not compute
>>> the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and
>>> does compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite
>>> strings).
>>>
>>>
>>
>> You do like your Herring Red don't you.
>>
>> NO ONE says that the decider maps something that isn't its input.
>>
>> H applied to <H^> <H^> needs to figure out what its input maps to.
>
> I keep telling you and you keep forgetting that I have not been talking
> about H for many months. The copy of H at embedded at Ĥ.qx is not the
> same as H.

On 3/8/22 8:06 AM, olcott wrote:
> On 3/8/2022 5:36 AM, Ben Bacarisse wrote:
>> Mikko <mikko.levanto@iki.fi> writes:
>>
>>> On 2022-03-05 11:53:50 +0000, Ben Bacarisse said:
>>>
>>>> Mikko <mikko.levanto@iki.fi> writes:
>>>>
>>>>> On 2022-03-04 21:07:30 +0000, Ben Bacarisse said:
>>>>>
>>>>>> The words used don't alter the facts -- that there is no TM
>>>>>> satisfying Linz's 12.1 can be, loosely, stated as "there is no
>>>>>> decider for the strings that represent halting computations".
>>>>> Words can be (and often are) used to hide facts.
>>>> But not, as far as I can see, in this case.  The meaning of
>>>> "decider" --
>>>> a TM whose language is decidable -- is not causing any confusion.  OK,
>>>> PO lies about what other people say and/or know about "deciders", but
>>>> the fault there is in the lying, not in the words used.
>>>
>>> In this case the probable intent was to argue about an irrelevance in
>>> order to draw attention from the fact that the presented soulution does
>>> not satisfy the definitiopn (21.1) of a solution to the halting
>>> problem.
>>
>> That's possible.
>>
>
> I conclusively proved that the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> never reaches its final state of ⟨Ĥ⟩.qn thus proving that embedded_H
> would be correct to reject its input. This refutes the Linz proof that
> concludes this is impossible.
>

No, you haven't. All you have done is proved that embedded_H can not
prove that <H^> <H^> represents the Halting Computation it is if
embedded_H (incorrectly) says it is a Non-Halting Computation.

If embedded_H fails to answer, it fails to be a decider.

FAIL.

olcott <NoOne@NoWhere.com> writes:

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

>>> It is never the case that any decider reports on the behavior of the
>>> computation that contains itself. Deciders are not capable of
>>> reporting on the behavior of Turing machines they can only accept or
>>> reject finite string inputs.
>>
>> I keep addressing this. Again: you are wrong, Deciders /are/ capable of
>> reporting on the behavior of Turing machines.
>
> Deciders only compute the mapping from input finite strings to accept
> or reject states.

Of course. No one has ever disputed this obvious fact. (You only
discovered it recently since you used to reject any talk on string
encoding as an "extraneous detail", but now this "extraneous detail"
gets top billing.)

I will repeat my offer: if you would like to learn how "deciders compute
only a function from input strings to accept/reject states" and
"deciders /are/ capable of reporting on the behavior of Turing machines"
are not contradictory, nor even in conflict, I can take you through some
exercises that will help.

> If you disagree please provide a link that proves that
> deciders compute mappings from non-input non-strings.
>
> If you don't disagree then you know that embedded_H does not compute
> the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does
> compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).

(1) embedded_H is not a decider. It does not "compute the mapping from
input finite strings to accept or reject states" because it has no
accept state. You will, eventually, have to talk about H because that's
where your big mistake is, and the only TM around that have accept and
reject states.

(2) Which strings a decider accepts and which it rejects is often
determined by what the strings encode. H must accept those strings of
the form <M> I such that TM M accepts input I. I.e. is accepts those
strings that encode halting computations and rejects all others.

(3) Even if all you want is a TM the "refutes the proof" (i.e. one that
is right only about that one impossible case), you must show a TM that
does either this:

H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,

or this:

H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.

(4) You don't have such a TM. You have nothing.

--
Ben.

On 3/8/2022 7:14 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>
>>>> It is never the case that any decider reports on the behavior of the
>>>> computation that contains itself. Deciders are not capable of
>>>> reporting on the behavior of Turing machines they can only accept or
>>>> reject finite string inputs.
>>>
>>> I keep addressing this. Again: you are wrong, Deciders /are/ capable of
>>> reporting on the behavior of Turing machines.
>>
>> Deciders only compute the mapping from input finite strings to accept
>> or reject states.
>
> Of course. No one has ever disputed this obvious fact. (You only
> discovered it recently since you used to reject any talk on string
> encoding as an "extraneous detail", but now this "extraneous detail"
> gets top billing.)
>
> I will repeat my offer: if you would like to learn how "deciders compute
> only a function from input strings to accept/reject states" and
> "deciders /are/ capable of reporting on the behavior of Turing machines"
> are not contradictory, nor even in conflict, I can take you through some
> exercises that will help.
>
>> If you disagree please provide a link that proves that
>> deciders compute mappings from non-input non-strings.
>>
>> If you don't disagree then you know that embedded_H does not compute
>> the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does
>> compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).
>
> (1) embedded_H is not a decider. It does not "compute the mapping from
> input finite strings to accept or reject states" because it has no
> accept state. You will, eventually, have to talk about H because that's
> where your big mistake is, and the only TM around that have accept and
> reject states.
>

It is OK that you force me to use much more accurate language because
this improves my professionalism. I count this as valid mentoring and
appreciate your effort.

It is certainly technically correct to say that embedded_H is not a
decider because it lacks a final accept state. The key point that I make
is that if embedded_H would reject its input ⟨Ĥ⟩ ⟨Ĥ⟩ it would be correct.

The Linz claim to have proven that embedded_H cannot possibly determine
the correct halt status of its input is refuted.

> (2) Which strings a decider accepts and which it rejects is often
> determined by what the strings encode. H must accept those strings of
> the form <M> I such that TM M accepts input I. I.e. is accepts those
> strings that encode halting computations and rejects all others.
>
> (3) Even if all you want is a TM the "refutes the proof" (i.e. one that
> is right only about that one impossible case), you must show a TM that
> does either this:
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>
> or this:
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.
>
> (4) You don't have such a TM. You have nothing.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
is correct as I have proven many many times.

You (and Linz) continue to be under the mistaken notion that a halt
decider must determine the halt status of the computation that contains
itself. This mistake would require a decider to base its accept or
reject decision on a non-string, non-input.

--
Copyright 2021 Pete Olcott

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

On 3/8/22 9:51 PM, olcott wrote:
> On 3/8/2022 7:14 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>>>> It is never the case that any decider reports on the behavior of the
>>>>> computation that contains itself. Deciders are not capable of
>>>>> reporting on the behavior of Turing machines they can only accept or
>>>>> reject finite string inputs.
>>>>
>>>> I keep addressing this.  Again: you are wrong, Deciders /are/
>>>> capable of
>>>> reporting on the behavior of Turing machines.
>>>
>>> Deciders only compute the mapping from input finite strings to accept
>>> or reject states.
>>
>> Of course.  No one has ever disputed this obvious fact.  (You only
>> discovered it recently since you used to reject any talk on string
>> encoding as an "extraneous detail", but now this "extraneous detail"
>> gets top billing.)
>>
>> I will repeat my offer: if you would like to learn how "deciders compute
>> only a function from input strings to accept/reject states" and
>> "deciders /are/ capable of reporting on the behavior of Turing machines"
>> are not contradictory, nor even in conflict, I can take you through some
>> exercises that will help.
>>
>>> If you disagree please provide a link that proves that
>>> deciders compute mappings from non-input non-strings.
>>>
>>> If you don't disagree then you know that embedded_H does not compute
>>> the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does
>>> compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).
>>
>> (1) embedded_H is not a decider.  It does not "compute the mapping from
>> input finite strings to accept or reject states" because it has no
>> accept state.  You will, eventually, have to talk about H because that's
>> where your big mistake is, and the only TM around that have accept and
>> reject states.
>>
>
> It is OK that you force me to use much more accurate language because
> this improves my professionalism. I count this as valid mentoring and
> appreciate your effort.
>
> It is certainly technically correct to say that embedded_H is not a
> decider because it lacks a final accept state. The key point that I make
> is that if embedded_H would reject its input ⟨Ĥ⟩ ⟨Ĥ⟩ it would be correct.

Excep[t for that fact that if embedded_H reject the input <H^> <H^> and
goes to the state Qn, then H^ applied to <H^> also goes to H^.Qn and
Halt, so embedded_H can not be correct about that input BY DEFINITION.

>
> The Linz claim to have proven that embedded_H cannot possibly determine
> the correct halt status of its input is refuted.

Except embedded_H didn't CORRECTED determine the halting status of its
input, since it rejected a Halting Computation.

>
>> (2) Which strings a decider accepts and which it rejects is often
>> determined by what the strings encode.  H must accept those strings of
>> the form <M> I such that TM M accepts input I.  I.e. is accepts those
>> strings that encode halting computations and rejects all others.
>>
>> (3) Even if all you want is a TM the "refutes the proof" (i.e. one that
>> is right only about that one impossible case), you must show a TM that
>> does either this:
>>
>>             H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
>> or this:
>>
>>             H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on input ⟨Ĥ⟩.
>>
>> (4) You don't have such a TM.  You have nothing.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> is correct as I have proven many many times.

HOW is it correct, since the DEFINITION of the correct answer for H, and
thus for embedded_H is that if M applied to w Halts, then H / embedded_H
applied to <M> w needs to go to Qy and ACCEPT that input.

Since H^ applied to <H^> goes to H^.Qn and Halt if embedded_H <H^> <H^>
goes to Qn, that answer CAN'T be right.

>
> You (and Linz) continue to be under the mistaken notion that a halt
> decider must determine the halt status of the computation that contains
> itself. This mistake would require a decider to base its accept or
> reject decision on a non-string, non-input.
>
>

Because there is no exception for the input containing a copy of the
decider, it must decide based on the ACTUAL behavior of the machine that
the input represents, NO MATTER WHAT. Since H^ applied to <H^> will Halt
if H applied to <H^> <H^> goes to H.Qn, that answer is NOT correct.

You have been asked to SHOW proof of this, and have not done so, so this
is PROOF that you are just being a LYING HYPOCRITE about this 'fact'

It isn't true.

You can't prove it.

It is just a figment of your tiny mind because you don't understand what
truth actually is.

YOU HAVE FAILED, and are DOOMED to the legacy of being a crank.

olcott <NoOne@NoWhere.com> writes:

> On 3/8/2022 7:14 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>>>> It is never the case that any decider reports on the behavior of the
>>>>> computation that contains itself. Deciders are not capable of
>>>>> reporting on the behavior of Turing machines they can only accept or
>>>>> reject finite string inputs.
>>>>
>>>> I keep addressing this. Again: you are wrong, Deciders /are/ capable of
>>>> reporting on the behavior of Turing machines.
>>>
>>> Deciders only compute the mapping from input finite strings to accept
>>> or reject states.
>>
>> Of course. No one has ever disputed this obvious fact. (You only
>> discovered it recently since you used to reject any talk on string
>> encoding as an "extraneous detail", but now this "extraneous detail"
>> gets top billing.)
>>
>> I will repeat my offer: if you would like to learn how "deciders compute
>> only a function from input strings to accept/reject states" and
>> "deciders /are/ capable of reporting on the behavior of Turing machines"
>> are not contradictory, nor even in conflict, I can take you through some
>> exercises that will help.

So you now know that everyone accepts that "deciders compute only a
function from input strings to accept/reject states" and you also also
now know that "deciders /are/ capable of reporting on the behavior of
Turing machines".

You should acknowledge when you're agreed that you have been wrong about
something.

>>> If you disagree please provide a link that proves that
>>> deciders compute mappings from non-input non-strings.
>>>
>>> If you don't disagree then you know that embedded_H does not compute
>>> the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does
>>> compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).
>> (1) embedded_H is not a decider. It does not "compute the mapping from
>> input finite strings to accept or reject states" because it has no
>> accept state. You will, eventually, have to talk about H because that's
>> where your big mistake is, and the only TM around that have accept and
>> reject states.
>
> It is OK that you force me to use much more accurate language because
> this improves my professionalism.

You show no professionalism.

> I count this as valid mentoring and appreciate your effort.

No you don't.

> It is certainly technically correct to say that embedded_H is not a
> decider because it lacks a final accept state. The key point that I
> make is that if embedded_H would reject its input ⟨Ĥ⟩ ⟨Ĥ⟩ it would be
> correct.

No.

> The Linz claim to have proven that embedded_H cannot possibly
> determine the correct halt status of its input is refuted.

Linz makes no such claim.

>> (2) Which strings a decider accepts and which it rejects is often
>> determined by what the strings encode. H must accept those strings of
>> the form <M> I such that TM M accepts input I. I.e. is accepts those
>> strings that encode halting computations and rejects all others.
>>
>> (3) Even if all you want is a TM the "refutes the proof" (i.e. one that
>> is right only about that one impossible case), you must show a TM that
>> does either this:
>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>> or this:
>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.
>> (4) You don't have such a TM. You have nothing.

I note that, again, you don't dispute that you have not such H.

> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> is correct as I have proven many many times.

No. Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
"correct" nor "incorrect". It is simply a statement about what a TM
does when presented with some input. There has to be an associated
condition by which the correctness can be assessed, and you steadfastly
remove the conditions that Linz so clearly gives you:

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.

For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.

The whole world knows why you keep omitting the condition and, instead,
claim that transitioning to Ĥ.qn "correct" with no reference to the
actual condition for correctness. When pushed, you replace the actual
condition with your "it had to be aborted, honest, guv" waffle in place
of the proper condition derived from what Linz asserts about H to start
with.

It's all so tediously obvious. You won't be able to fool anyone with
it.

> You (and Linz) continue to be under the mistaken notion that a halt
> decider must determine the halt status of the computation that
> contains itself.

A halt decider, H, must be correct about every input -- even those
strings that include something very like an encoding of H (as is the
case for Ĥ).

It almost sounds like are preparing to give up on the ruse you've been
trying to pull for the last few years, and that you are going to go back
to the "it's an invalid question nonsense" from many years ago.

> This mistake would require a decider to base its accept or reject
> decision on a non-string, non-input.

A decider must accept or reject every string and which one of those is
the case is determined by the input string and nothing else. Neither I,
nor Linz, nor anyone else, has suggested otherwise.

The conditions that determine what the correct answer is depend on what
TM and input the input encodes.

--
Ben.

On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/8/2022 7:14 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>>> It is never the case that any decider reports on the behavior of the
>>>>>> computation that contains itself. Deciders are not capable of
>>>>>> reporting on the behavior of Turing machines they can only accept or
>>>>>> reject finite string inputs.
>>>>>
>>>>> I keep addressing this. Again: you are wrong, Deciders /are/ capable of
>>>>> reporting on the behavior of Turing machines.
>>>>
>>>> Deciders only compute the mapping from input finite strings to accept
>>>> or reject states.
>>>
>>> Of course. No one has ever disputed this obvious fact. (You only
>>> discovered it recently since you used to reject any talk on string
>>> encoding as an "extraneous detail", but now this "extraneous detail"
>>> gets top billing.)
>>>
>>> I will repeat my offer: if you would like to learn how "deciders compute
>>> only a function from input strings to accept/reject states" and
>>> "deciders /are/ capable of reporting on the behavior of Turing machines"
>>> are not contradictory, nor even in conflict, I can take you through some
>>> exercises that will help.
>
> So you now know that everyone accepts that "deciders compute only a
> function from input strings to accept/reject states" and you also also
> now know that "deciders /are/ capable of reporting on the behavior of
> Turing machines".
>
> You should acknowledge when you're agreed that you have been wrong about
> something.
>

I am not wrong. Deciders never report on the actual behavior of actual
Turing machines. The closest that they get to this is is reporting on
the behavior that a finite string Turing machine description specifies.

>>>> If you disagree please provide a link that proves that
>>>> deciders compute mappings from non-input non-strings.
>>>>
>>>> If you don't disagree then you know that embedded_H does not compute
>>>> the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does
>>>> compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).
>>> (1) embedded_H is not a decider. It does not "compute the mapping from
>>> input finite strings to accept or reject states" because it has no
>>> accept state. You will, eventually, have to talk about H because that's
>>> where your big mistake is, and the only TM around that have accept and
>>> reject states.
>>
>> It is OK that you force me to use much more accurate language because
>> this improves my professionalism.
>
> You show no professionalism.
>

I am not quite yet even in the ballpark of the degree of academic
professionalism required for publication in premier computer science
journals.

Any PhD professor of computer science that is an expert in the theory of
computation on the halting problem that fully understands my work could
translate my words into academic quality in a few days.

>> I count this as valid mentoring and appreciate your effort.
>
> No you don't.
>

It is inaccurate of me to not mention that some aspects of your
critiques do have a beneficial influence on my writing style. I am
trying to be a little more disciplined in my choice of terms.

This whole [ more clarity ] sequence of posts was based on translating
some of my key ideas into generic terms that are not overloaded with
incongruous term-of-the-art meanings.

>> It is certainly technically correct to say that embedded_H is not a
>> decider because it lacks a final accept state. The key point that I
>> make is that if embedded_H would reject its input ⟨Ĥ⟩ ⟨Ĥ⟩ it would be
>> correct.
>
> No.
>
>> The Linz claim to have proven that embedded_H cannot possibly
>> determine the correct halt status of its input is refuted.
>
> Linz makes no such claim.
>

Do I have to quote his verbatim words all over again?

<Linz>
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 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞

if Ĥ applied to ⟨Ĥ⟩ halts, and

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

if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
contradiction tells us that our assumption of the existence of H, and
hence the assumption of the decidability of the halting problem, must be
false.

</Linz>

>>> (2) Which strings a decider accepts and which it rejects is often
>>> determined by what the strings encode. H must accept those strings of
>>> the form <M> I such that TM M accepts input I. I.e. is accepts those
>>> strings that encode halting computations and rejects all others.
>>>
>>> (3) Even if all you want is a TM the "refutes the proof" (i.e. one that
>>> is right only about that one impossible case), you must show a TM that
>>> does either this:
>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>>> or this:
>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.
>>> (4) You don't have such a TM. You have nothing.
>
> I note that, again, you don't dispute that you have not such H.
>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> is correct as I have proven many many times.
>
> No. Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
> "correct" nor "incorrect". It is simply a statement about what a TM
> does when presented with some input. There has to be an associated
> condition by which the correctness can be assessed, and you steadfastly
> remove the conditions that Linz so clearly gives you:
>

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
state.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
final state.

> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.
>
> For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
> occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.
>
> The whole world knows why you keep omitting the condition and, instead,
> claim that transitioning to Ĥ.qn "correct" with no reference to the
> actual condition for correctness. When pushed, you replace the actual
> condition with your "it had to be aborted, honest, guv" waffle in place
> of the proper condition derived from what Linz asserts about H to start
> with.
>
> It's all so tediously obvious. You won't be able to fool anyone with
> it.
>
>> You (and Linz) continue to be under the mistaken notion that a halt
>> decider must determine the halt status of the computation that
>> contains itself.
>
> A halt decider, H, must be correct about every input -- even those
> strings that include something very like an encoding of H (as is the
> case for Ĥ).
>

You were much sloppier in your first comment that I reponded to. Halt
deciders do not compute the halt status of non-finite string non-inputs.

> It almost sounds like are preparing to give up on the ruse you've been
> trying to pull for the last few years, and that you are going to go back
> to the "it's an invalid question nonsense" from many years ago.
>
>> This mistake would require a decider to base its accept or reject
>> decision on a non-string, non-input.
>
> A decider must accept or reject every string and which one of those is
> the case is determined by the input string and nothing else. Neither I,
> nor Linz, nor anyone else, has suggested otherwise.

Both you and Linz incorrectly believe that embedded_H must report on the
non-input non-finite string of Ĥ ⟨Ĥ⟩.

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

On 3/8/22 11:20 PM, olcott wrote:
> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/8/2022 7:14 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>> It is never the case that any decider reports on the behavior of the
>>>>>>> computation that contains itself. Deciders are not capable of
>>>>>>> reporting on the behavior of Turing machines they can only accept or
>>>>>>> reject finite string inputs.
>>>>>>
>>>>>> I keep addressing this.  Again: you are wrong, Deciders /are/
>>>>>> capable of
>>>>>> reporting on the behavior of Turing machines.
>>>>>
>>>>> Deciders only compute the mapping from input finite strings to accept
>>>>> or reject states.
>>>>
>>>> Of course.  No one has ever disputed this obvious fact.  (You only
>>>> discovered it recently since you used to reject any talk on string
>>>> encoding as an "extraneous detail", but now this "extraneous detail"
>>>> gets top billing.)
>>>>
>>>> I will repeat my offer: if you would like to learn how "deciders
>>>> compute
>>>> only a function from input strings to accept/reject states" and
>>>> "deciders /are/ capable of reporting on the behavior of Turing
>>>> machines"
>>>> are not contradictory, nor even in conflict, I can take you through
>>>> some
>>>> exercises that will help.
>>
>> So you now know that everyone accepts that "deciders compute only a
>> function from input strings to accept/reject states" and you also also
>> now know that "deciders /are/ capable of reporting on the behavior of
>> Turing machines".
>>
>> You should acknowledge when you're agreed that you have been wrong about
>> something.
>>
>
> I am not wrong. Deciders never report on the actual behavior of actual
> Turing machines. The closest that they get to this is is reporting on
> the behavior that a finite string Turing machine description specifies.

Why Not? Do you have a reference for this?

If it is True, then there absolutely CAN'T be a Halt Decider, because
Halting is exactly based on the actual behavior of actual Turing Machines.

So, I guess you just proved there can't be a Halt Decider.

>
>>>>> If you disagree please provide a link that proves that
>>>>> deciders compute mappings from non-input non-strings.
>>>>>
>>>>> If you don't disagree then you know that embedded_H does not compute
>>>>> the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does
>>>>> compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).
>>>> (1) embedded_H is not a decider.  It does not "compute the mapping from
>>>> input finite strings to accept or reject states" because it has no
>>>> accept state.  You will, eventually, have to talk about H because
>>>> that's
>>>> where your big mistake is, and the only TM around that have accept and
>>>> reject states.
>>>
>>> It is OK that you force me to use much more accurate language because
>>> this improves my professionalism.
>>
>> You show no professionalism.
>>
>
> I am not quite yet even in the ballpark of the degree of academic
> professionalism required for publication in premier computer science
> journals.

Being WRONG is the biggest issue.

>
> Any PhD professor of computer science that is an expert in the theory of
> computation on the halting problem that fully understands my work could
> translate my words into academic quality in a few days.
>

So hire one, if you can find one willing to distroy their reputation.

>>> I count this as valid mentoring and appreciate your effort.
>>
>> No you don't.
>>
>
> It is inaccurate of me to not mention that some aspects of your
> critiques do have a beneficial influence on my writing style. I am
> trying to be a little more disciplined in my choice of terms.
>
> This whole [ more clarity ] sequence of posts was based on translating
> some of my key ideas into generic terms that are not overloaded with
> incongruous term-of-the-art meanings.
>
>>> It is certainly technically correct to say that embedded_H is not a
>>> decider because it lacks a final accept state. The key point that I
>>> make is that if embedded_H would reject its input ⟨Ĥ⟩ ⟨Ĥ⟩ it would be
>>> correct.
>>
>> No.
>>
>>> The Linz claim to have proven that embedded_H cannot possibly
>>> determine the correct halt status of its input is refuted.
>>
>> Linz makes no such claim.
>>
>
> Do I have to quote his verbatim words all over again?
>
> <Linz>
>     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 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>
> if Ĥ applied to  ⟨Ĥ⟩ halts, and
>
>                  Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
> contradiction tells us that our assumption of the existence of H, and
> hence the assumption of the decidability of the halting problem, must be
> false.
>
> </Linz>
>
>
>>>> (2) Which strings a decider accepts and which it rejects is often
>>>> determined by what the strings encode.  H must accept those strings of
>>>> the form <M> I such that TM M accepts input I.  I.e. is accepts those
>>>> strings that encode halting computations and rejects all others.
>>>>
>>>> (3) Even if all you want is a TM the "refutes the proof" (i.e. one that
>>>> is right only about that one impossible case), you must show a TM that
>>>> does either this:
>>>>              H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
>>>>              or this:
>>>>              H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on input ⟨Ĥ⟩.
>>>> (4) You don't have such a TM.  You have nothing.
>>
>> I note that, again, you don't dispute that you have not such H.
>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> is correct as I have proven many many times.
>>
>> No.  Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
>> "correct" nor "incorrect".  It is simply a statement about what a TM
>> does when presented with some input.  There has to be an associated
>> condition by which the correctness can be assessed, and you steadfastly
>> remove the conditions that Linz so clearly gives you:
>>
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
> state.

No, if the computatation H^ applied to <H^> would reach its final state,
or by the definition of a UTM, if the simulation of <H> <H^> by an
actual UTM would reach its final state.

And both of these are true if embedded_H <H^> <H^> -> Qn.

>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
> final state.

Again, if the computation H^ applied to <H^> will never reach its final
state. Which is NOT true of embedded_H <H^> <H^> goes to Qn, since H^
then also goes to H^.Qn and Halts.

>
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn  if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.
>>
>> For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
>> occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.
>>
>> The whole world knows why you keep omitting the condition and, instead,
>> claim that transitioning to Ĥ.qn "correct" with no reference to the
>> actual condition for correctness.  When pushed, you replace the actual
>> condition with your "it had to be aborted, honest, guv" waffle in place
>> of the proper condition derived from what Linz asserts about H to start
>> with.
>>
>> It's all so tediously obvious.  You won't be able to fool anyone with
>> it.
>>
>>> You (and Linz) continue to be under the mistaken notion that a halt
>>> decider must determine the halt status of the computation that
>>> contains itself.
>>
>> A halt decider, H, must be correct about every input -- even those
>> strings that include something very like an encoding of H (as is the
>> case for Ĥ).
>>
>
> You were much sloppier in your first comment that I reponded to. Halt
> deciders do not compute the halt status of non-finite string non-inputs.

On 2022-03-08 21:20, olcott wrote:
> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:

>> No.  Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
>> "correct" nor "incorrect".  It is simply a statement about what a TM
>> does when presented with some input.  There has to be an associated
>> condition by which the correctness can be assessed, and you steadfastly
>> remove the conditions that Linz so clearly gives you:
>>
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
> state.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
> final state.

The above doesn't jive with the nonsense you keep asserting elsewhere.
You keep claiming that TMs can only deal with the finite strings which
are their inputs.

But the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H is neither a finite
string nor an input to embedded_H. So why do you think that non-input
non-finite string should be a valid basis for a decision criterion
whereas Ĥ applied to ⟨Ĥ⟩ should not be?

>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn  if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.
>>
>> For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
>> occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.
>>
>> The whole world knows why you keep omitting the condition and, instead,
>> claim that transitioning to Ĥ.qn "correct" with no reference to the
>> actual condition for correctness.  When pushed, you replace the actual
>> condition with your "it had to be aborted, honest, guv" waffle in place
>> of the proper condition derived from what Linz asserts about H to start
>> with.
>>
>> It's all so tediously obvious.  You won't be able to fool anyone with
>> it.
>>
>>> You (and Linz) continue to be under the mistaken notion that a halt
>>> decider must determine the halt status of the computation that
>>> contains itself.
>>
>> A halt decider, H, must be correct about every input -- even those
>> strings that include something very like an encoding of H (as is the
>> case for Ĥ).
>>
>
> You were much sloppier in your first comment that I reponded to. Halt
> deciders do not compute the halt status of non-finite string non-inputs.
>
>> It almost sounds like are preparing to give up on the ruse you've been
>> trying to pull for the last few years, and that you are going to go back
>> to the "it's an invalid question nonsense" from many years ago.
>>
>>> This mistake would require a decider to base its accept or reject
>>> decision on a non-string, non-input.
>>
>> A decider must accept or reject every string and which one of those is
>> the case is determined by the input string and nothing else.  Neither I,
>> nor Linz, nor anyone else, has suggested otherwise.
>
> Both you and Linz incorrectly believe that embedded_H must report on the
> non-input non-finite string of Ĥ ⟨Ĥ⟩.

It's not just Ben and Linz, but every single author who has ever written
about this particular proof. That's because it *isn't* a mistake.

Don't you think that it's a bit telling that everyone in the universe
who actually *understands* how Turing Machine agrees with Linz, whereas
you, who have consistently demonstrated that you've never once actually
designed or worked with actual Turing Machines, are the only one who
thinks otherwise?

Maybe you start by learning the basics and leave talking about Turing
Machines to people who have actually dealt with Turing Machines.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 3/8/2022 11:32 PM, André G. Isaak wrote:
> On 2022-03-08 21:20, olcott wrote:
>> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
>
>>> No.  Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
>>> "correct" nor "incorrect".  It is simply a statement about what a TM
>>> does when presented with some input.  There has to be an associated
>>> condition by which the correctness can be assessed, and you steadfastly
>>> remove the conditions that Linz so clearly gives you:
>>>
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
>> state.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
>> final state.
>
> The above doesn't jive with the nonsense you keep asserting elsewhere.
> You keep claiming that TMs can only deal with the finite strings which
> are their inputs.
>

From the above:
⟨Ĥ⟩ is the common convention for a finite string Turing machine description.

Ĥ is the convention for Turing machine Ĥ.

⟨Ĥ⟩ ⟨Ĥ⟩ is the convention for the input to the copy of Linz H at Ĥ.qx.

embedded_H is the convention for referring to the copy of Linz H
embedded at Ĥ.qx.

> But the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H is neither a finite
> string nor an input to embedded_H. So why do you think that non-input
> non-finite string should be a valid basis for a decision criterion
> whereas Ĥ applied to ⟨Ĥ⟩ should not be?
>

It it always that case that every decider computes the mapping from its
finite string input to accept or reject state.

In the case of a simulating halt decider this mapping is computed on the
basis of simulating the finite string and examining the simulated
behavior for any infinite behavior patterns.

>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn  if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.
>>>
>>> For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
>>> occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.
>>>
>>> The whole world knows why you keep omitting the condition and, instead,
>>> claim that transitioning to Ĥ.qn "correct" with no reference to the
>>> actual condition for correctness.  When pushed, you replace the actual
>>> condition with your "it had to be aborted, honest, guv" waffle in place
>>> of the proper condition derived from what Linz asserts about H to start
>>> with.
>>>
>>> It's all so tediously obvious.  You won't be able to fool anyone with
>>> it.
>>>
>>>> You (and Linz) continue to be under the mistaken notion that a halt
>>>> decider must determine the halt status of the computation that
>>>> contains itself.
>>>
>>> A halt decider, H, must be correct about every input -- even those
>>> strings that include something very like an encoding of H (as is the
>>> case for Ĥ).
>>>
>>
>> You were much sloppier in your first comment that I reponded to. Halt
>> deciders do not compute the halt status of non-finite string non-inputs.
>>
>>> It almost sounds like are preparing to give up on the ruse you've been
>>> trying to pull for the last few years, and that you are going to go back
>>> to the "it's an invalid question nonsense" from many years ago.
>>>
>>>> This mistake would require a decider to base its accept or reject
>>>> decision on a non-string, non-input.
>>>
>>> A decider must accept or reject every string and which one of those is
>>> the case is determined by the input string and nothing else.  Neither I,
>>> nor Linz, nor anyone else, has suggested otherwise.
>>
>> Both you and Linz incorrectly believe that embedded_H must report on
>> the non-input non-finite string of Ĥ ⟨Ĥ⟩.
>
> It's not just Ben and Linz, but every single author who has ever written
> about this particular proof. That's because it *isn't* a mistake.
>

As it turns out to actually be even an actual universal consensus does
not guarantee truth. Prior to Pythagoras there was a universal consensus
that the Earth was flat.

> Don't you think that it's a bit telling that everyone in the universe
> who actually *understands* how Turing Machine agrees with Linz, whereas
> you, who have consistently demonstrated that you've never once actually
> designed or worked with actual Turing Machines, are the only one who
> thinks otherwise?
>

Especially not when every rebuttal to my work was like yours and
entirely anchored in a misunderstanding of what I am even saying.

> Maybe you start by learning the basics and leave talking about Turing
> Machines to people who have actually dealt with Turing Machines.
>
> André
>

I am actually starting with the establishing the fundamental
philosophical underpinnings of the notion of truth itself.

The majority of philosophers agree that this cannot be done because
Willard Van Orman Quine has convinced them that they cannot really know
that all bachelors are unmarried.

https://www.theologie.uzh.ch/dam/jcr:ffffffff-fbd6-1538-0000-000070cf64bc/Quine51.pdf

--
Copyright 2021 Pete Olcott

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

On 2022-03-08 13:06:16 +0000, olcott said:

> On 3/8/2022 5:36 AM, Ben Bacarisse wrote:
>> Mikko <mikko.levanto@iki.fi> writes:
>>
>>> On 2022-03-05 11:53:50 +0000, Ben Bacarisse said:
>>>
>>>> Mikko <mikko.levanto@iki.fi> writes:
>>>>
>>>>> On 2022-03-04 21:07:30 +0000, Ben Bacarisse said:
>>>>>
>>>>>> The words used don't alter the facts -- that there is no TM
>>>>>> satisfying Linz's 12.1 can be, loosely, stated as "there is no
>>>>>> decider for the strings that represent halting computations".
>>>>> Words can be (and often are) used to hide facts.
>>>> But not, as far as I can see, in this case. The meaning of "decider" --
>>>> a TM whose language is decidable -- is not causing any confusion. OK,
>>>> PO lies about what other people say and/or know about "deciders", but
>>>> the fault there is in the lying, not in the words used.
>>>
>>> In this case the probable intent was to argue about an irrelevance in
>>> order to draw attention from the fact that the presented soulution does
>>> not satisfy the definitiopn (21.1) of a solution to the halting
>>> problem.
>>
>> That's possible.
>>
>
> I conclusively proved that the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> never reaches its final state of ⟨Ĥ⟩.qn thus proving that embedded_H
> would be correct to reject its input. This refutes the Linz proof that
> concludes this is impossible.

Linz did not present any proof with that conclusion, so you only refuted (or
at least tried to refute) a straw man.

Instead, Linz concluded that no Turing machine is a solution to the halting
problem as defined in definition 12.1. That conclusion you have not refuted.

Mikko

On 3/9/2022 7:50 AM, Mikko wrote:
> On 2022-03-08 13:06:16 +0000, olcott said:
>
>> On 3/8/2022 5:36 AM, Ben Bacarisse wrote:
>>> Mikko <mikko.levanto@iki.fi> writes:
>>>
>>>> On 2022-03-05 11:53:50 +0000, Ben Bacarisse said:
>>>>
>>>>> Mikko <mikko.levanto@iki.fi> writes:
>>>>>
>>>>>> On 2022-03-04 21:07:30 +0000, Ben Bacarisse said:
>>>>>>
>>>>>>> The words used don't alter the facts -- that there is no TM
>>>>>>> satisfying Linz's 12.1 can be, loosely, stated as "there is no
>>>>>>> decider for the strings that represent halting computations".
>>>>>> Words can be (and often are) used to hide facts.
>>>>> But not, as far as I can see, in this case.  The meaning of
>>>>> "decider" --
>>>>> a TM whose language is decidable -- is not causing any confusion.  OK,
>>>>> PO lies about what other people say and/or know about "deciders", but
>>>>> the fault there is in the lying, not in the words used.
>>>>
>>>> In this case the probable intent was to argue about an irrelevance in
>>>> order to draw attention from the fact that the presented soulution does
>>>> not satisfy the definitiopn (21.1) of a solution to the halting
>>>> problem.
>>>
>>> That's possible.
>>>
>>
>> I conclusively proved that the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>> never reaches its final state of ⟨Ĥ⟩.qn thus proving that embedded_H
>> would be correct to reject its input. This refutes the Linz proof that
>> concludes this is impossible.
>
> Linz did not present any proof with that conclusion, so you only refuted
> (or
> at least tried to refute) a straw man.
>

I keep proving that Linz did prove this yet now-a-days with "alternative
facts" it seems that many people actually believe that they can make up
their own "facts".

what would happen if Ĥ is applied to ⟨Ĥ⟩.
what would happen if Ĥ is applied to ⟨Ĥ⟩.
what would happen if Ĥ is applied to ⟨Ĥ⟩.

<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 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞

if Ĥ applied to ⟨Ĥ⟩ halts, and

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

if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
contradiction tells us that our assumption of the existence of H, and
hence the assumption of the decidability of the halting problem, must be
false.
</Linz:1990:320>

https://www.liarparadox.org/Linz_Proof.pdf

Linz is confused into believing that the copy of H embedded at Ĥ.qx must
base its halt status decision on the non-finite string non-input of: Ĥ
applied to ⟨Ĥ⟩.

It is the case that deciders only compute the mapping from their input
finite strings to an accept or reject state. This means that embedded_H
computes its mapping from ⟨Ĥ⟩ ⟨Ĥ⟩.

> Instead, Linz concluded that no Turing machine is a solution to the halting
> problem as defined in definition 12.1. That conclusion you have not
> refuted.
>
> Mikko
>

--
Copyright 2021 Pete Olcott

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

On 2022-03-09 14:15:43 +0000, olcott said:

> Linz is confused into believing that the copy of H embedded at Ĥ.qx
> must base its halt status decision on the non-finite string non-input
> of: Ĥ applied to ⟨Ĥ⟩.

What does that "must" mean?

Linz simply infers what Ĥ does from the way it is constructed, to the
extent it can be inferred. There is no confusion, the inference is correct.

Mikko

On 3/9/2022 12:25 PM, Mikko wrote:
> On 2022-03-09 14:15:43 +0000, olcott said:
>
>> Linz is confused into believing that the copy of H embedded at Ĥ.qx
>> must base its halt status decision on the non-finite string non-input
>> of: Ĥ applied to ⟨Ĥ⟩.
>
> What does that "must" mean?
>
> Linz simply infers what Ĥ does from the way it is constructed, to the
> extent it can be inferred. There is no confusion, the inference is correct.
>
> Mikko
>

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
state.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
final state.

The copy of Linz H at Ĥ.qx is referred to as embedded_H

<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 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞

if Ĥ applied to ⟨Ĥ⟩ halts, and

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

if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
contradiction tells us that our assumption of the existence of H, and
hence the assumption of the decidability of the halting problem, must be
false.
</Linz:1990:320>

https://www.liarparadox.org/Linz_Proof.pdf

As quoted above Linz believes that the halt status decision of
embedded_H is based on the behavior of a non-input, non-finite string: Ĥ
applied to ⟨Ĥ⟩ rather than the actual behavior of the actual finite
string input: ⟨Ĥ⟩ ⟨Ĥ⟩ shown below:

When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

--
Copyright 2021 Pete Olcott

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

On 3/9/22 2:17 PM, olcott wrote:
> On 3/9/2022 12:25 PM, Mikko wrote:
>> On 2022-03-09 14:15:43 +0000, olcott said:
>>
>>> Linz is confused into believing that the copy of H embedded at Ĥ.qx
>>> must base its halt status decision on the non-finite string non-input
>>> of: Ĥ applied to ⟨Ĥ⟩.
>>
>> What does that "must" mean?
>>
>> Linz simply infers what Ĥ does from the way it is constructed, to the
>> extent it can be inferred. There is no confusion, the inference is
>> correct.
>>
>> Mikko
>>
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
> state.

No, not 'by embedded_H', but by a real UTM (unless embedded_H actually
IS a UTM, but then it CAN'T 'abort' its simulation BY DEFINITION)

>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
> final state.

Again, NOT 'by embedded_H' but by a real UTM.

Note, if embedded_H aborts its simulation it is NOT a Real UTM, and your
statement is ill formed as embedded_H doesn't do a 'pure simulation', BY
DEFINITION.
>
> The copy of Linz H at Ĥ.qx is referred to as embedded_H
>
> <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 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>
> if Ĥ applied to ⟨Ĥ⟩ halts, and
>
>                  Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
> contradiction tells us that our assumption of the existence of H, and
> hence the assumption of the decidability of the halting problem, must be
> false.
> </Linz:1990:320>
>
> https://www.liarparadox.org/Linz_Proof.pdf
>
> As quoted above Linz believes that the halt status decision of
> embedded_H is based on the behavior of a non-input, non-finite string: Ĥ
> applied to ⟨Ĥ⟩ rather than the actual behavior of the actual finite
> string input: ⟨Ĥ⟩ ⟨Ĥ⟩ shown below:

FINITE STRINGS DO NOT HAVE ANY BEHAVIOR, they only represent something
with behavior.

>
> When Ĥ is applied to ⟨Ĥ⟩
>   Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>
> Then these steps would keep repeating:
>   Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>   Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>   Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

And this behavior only exists if embedded_H never aborts its simulation,
which mean it fails to be a decider as it never returns an answer.

It can't do both be a Pure Simulator, and abort its simulation.

FAIL.

On 3/9/22 9:15 AM, olcott wrote:
> On 3/9/2022 7:50 AM, Mikko wrote:
>> On 2022-03-08 13:06:16 +0000, olcott said:
>>
>>> On 3/8/2022 5:36 AM, Ben Bacarisse wrote:
>>>> Mikko <mikko.levanto@iki.fi> writes:
>>>>
>>>>> On 2022-03-05 11:53:50 +0000, Ben Bacarisse said:
>>>>>
>>>>>> Mikko <mikko.levanto@iki.fi> writes:
>>>>>>
>>>>>>> On 2022-03-04 21:07:30 +0000, Ben Bacarisse said:
>>>>>>>
>>>>>>>> The words used don't alter the facts -- that there is no TM
>>>>>>>> satisfying Linz's 12.1 can be, loosely, stated as "there is no
>>>>>>>> decider for the strings that represent halting computations".
>>>>>>> Words can be (and often are) used to hide facts.
>>>>>> But not, as far as I can see, in this case.  The meaning of
>>>>>> "decider" --
>>>>>> a TM whose language is decidable -- is not causing any confusion.
>>>>>> OK,
>>>>>> PO lies about what other people say and/or know about "deciders", but
>>>>>> the fault there is in the lying, not in the words used.
>>>>>
>>>>> In this case the probable intent was to argue about an irrelevance in
>>>>> order to draw attention from the fact that the presented soulution
>>>>> does
>>>>> not satisfy the definitiopn (21.1) of a solution to the halting
>>>>> problem.
>>>>
>>>> That's possible.
>>>>
>>>
>>> I conclusively proved that the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>> never reaches its final state of ⟨Ĥ⟩.qn thus proving that embedded_H
>>> would be correct to reject its input. This refutes the Linz proof
>>> that concludes this is impossible.
>>
>> Linz did not present any proof with that conclusion, so you only
>> refuted (or
>> at least tried to refute) a straw man.
>>
>
> I keep proving that Linz did prove this yet now-a-days with "alternative
> facts" it seems that many people actually believe that they can make up
> their own "facts".
>
> what would happen if Ĥ is applied to ⟨Ĥ⟩.
> what would happen if Ĥ is applied to ⟨Ĥ⟩.
> what would happen if Ĥ is applied to ⟨Ĥ⟩.

Right, THAT is exactly the question. READ THE DEFINITION OF H

H applied to <M> w needs to answer based on what M appiled to w does.

>
> <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 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>
> if Ĥ applied to  ⟨Ĥ⟩ halts, and
>
>                  Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
> contradiction tells us that our assumption of the existence of H, and
> hence the assumption of the decidability of the halting problem, must be
> false.
> </Linz:1990:320>
>
> https://www.liarparadox.org/Linz_Proof.pdf
>
> Linz is confused into believing that the copy of H embedded at Ĥ.qx must
> base its halt status decision on the non-finite string non-input of: Ĥ
> applied to ⟨Ĥ⟩.

Right, the DEFINITION of the problem says that CRITERIA of the mapping
for <H^> <H^> is based on the behavior of H^ applied to <H^>

Just like 2 + 3 = 5, even though 5 is not an input to the + operator.

>
> It is the case that deciders only compute the mapping from their input
> finite strings to an accept or reject state. This means that embedded_H
> computes its mapping from ⟨Ĥ⟩ ⟨Ĥ⟩.

Right, it needs to COMPUTE based on its input, which is <H^> <H^> but
the RIGHT ANSWER is based on H^ applied to <H^>, BY THE DEFINITION OF
THE MAPPING it is supposed to compute.

Remember, it is supposed to decide if the computation its input
REPRESENTS would halt.

You confuse CAPABILITY with REQUIREMENTS.

>
>> Instead, Linz concluded that no Turing machine is a solution to the
>> halting
>> problem as defined in definition 12.1. That conclusion you have not
>> refuted.
>>
>> Mikko
>>
>
>

On 3/9/22 8:03 AM, olcott wrote:
> On 3/8/2022 11:32 PM, André G. Isaak wrote:
>> On 2022-03-08 21:20, olcott wrote:
>>> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
>>
>>>> No.  Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
>>>> "correct" nor "incorrect".  It is simply a statement about what a TM
>>>> does when presented with some input.  There has to be an associated
>>>> condition by which the correctness can be assessed, and you steadfastly
>>>> remove the conditions that Linz so clearly gives you:
>>>>
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
>>> state.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
>>> final state.
>>
>> The above doesn't jive with the nonsense you keep asserting elsewhere.
>> You keep claiming that TMs can only deal with the finite strings which
>> are their inputs.
>>
>
> From the above:
> ⟨Ĥ⟩ is the common convention for a finite string Turing machine
> description.
>
> Ĥ is the convention for Turing machine Ĥ.
>
> ⟨Ĥ⟩ ⟨Ĥ⟩ is the convention for the input to the copy of Linz H at Ĥ.qx.
>
> embedded_H is the convention for referring to the copy of Linz H
> embedded at Ĥ.qx.
>
>> But the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H is neither a finite
>> string nor an input to embedded_H. So why do you think that non-input
>> non-finite string should be a valid basis for a decision criterion
>> whereas Ĥ applied to ⟨Ĥ⟩ should not be?
>>
>
> It it always that case that every decider computes the mapping from its
> finite string input to accept or reject state.
>
> In the case of a simulating halt decider this mapping is computed on the
> basis of simulating the finite string and examining the simulated
> behavior for any infinite behavior patterns.
>

Right, a CORRECT infinite behavior pattern, as testable by an ACTUAL UTM.

Note, that a REAL UTM when it simulates the input <H^> <H^>, BY
DEFINITION, gets the exact same behavior as H^ applied to <H^>, and if
embedded_H applied to <H^> <H^> 'decides' that its input has what it
thinks is an infinite behavior pattern, and goes to Qn, the we can
plainly see that H^ applied to <H^> will see that exact behavior and end
up in H^.Qn and Halts.

Thus PROVING that <H^> <H^> does not have any infinite behavior patterns.

Yes, if you have a DIFFERENT embedded_H that NEVER aborts its simulation
of its <H^> <H^> then we can see the infinite behavior, but that is a
DIFFERENT H^, because it is based on a DIFFERENT H/embedded_H, and that
embedded_H fails because it never gives the non-halting answer (because
the pattern only shows up when it NEVER aborts).

You can't NEVER abort and also abort. THAT is the Liars Paradox.

>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn  if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.
>>>>
>>>> For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
>>>> occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.
>>>>
>>>> The whole world knows why you keep omitting the condition and, instead,
>>>> claim that transitioning to Ĥ.qn "correct" with no reference to the
>>>> actual condition for correctness.  When pushed, you replace the actual
>>>> condition with your "it had to be aborted, honest, guv" waffle in place
>>>> of the proper condition derived from what Linz asserts about H to start
>>>> with.
>>>>
>>>> It's all so tediously obvious.  You won't be able to fool anyone with
>>>> it.
>>>>
>>>>> You (and Linz) continue to be under the mistaken notion that a halt
>>>>> decider must determine the halt status of the computation that
>>>>> contains itself.
>>>>
>>>> A halt decider, H, must be correct about every input -- even those
>>>> strings that include something very like an encoding of H (as is the
>>>> case for Ĥ).
>>>>
>>>
>>> You were much sloppier in your first comment that I reponded to. Halt
>>> deciders do not compute the halt status of non-finite string non-inputs.
>>>
>>>> It almost sounds like are preparing to give up on the ruse you've been
>>>> trying to pull for the last few years, and that you are going to go
>>>> back
>>>> to the "it's an invalid question nonsense" from many years ago.
>>>>
>>>>> This mistake would require a decider to base its accept or reject
>>>>> decision on a non-string, non-input.
>>>>
>>>> A decider must accept or reject every string and which one of those is
>>>> the case is determined by the input string and nothing else.
>>>> Neither I,
>>>> nor Linz, nor anyone else, has suggested otherwise.
>>>
>>> Both you and Linz incorrectly believe that embedded_H must report on
>>> the non-input non-finite string of Ĥ ⟨Ĥ⟩.
>>
>> It's not just Ben and Linz, but every single author who has ever
>> written about this particular proof. That's because it *isn't* a mistake.
>>
>
> As it turns out to actually be even an actual universal consensus does
> not guarantee truth. Prior to Pythagoras there was a universal consensus
> that the Earth was flat.
>

Yes, but disagreing with everyone doesn't make you right either.

>> Don't you think that it's a bit telling that everyone in the universe
>> who actually *understands* how Turing Machine agrees with Linz,
>> whereas you, who have consistently demonstrated that you've never once
>> actually designed or worked with actual Turing Machines, are the only
>> one who thinks otherwise?
>>
>
> Especially not when every rebuttal to my work was like yours and
> entirely anchored in a misunderstanding of what I am even saying.
>

Maybe the issue ix that even YOU don't understand what you are saying,
because it is rooted in FALSE words.

>> Maybe you start by learning the basics and leave talking about Turing
>> Machines to people who have actually dealt with Turing Machines.
>>
>> André
>>
>
> I am actually starting with the establishing the fundamental
> philosophical underpinnings of the notion of truth itself.

Then you need to go to the ROOTS of the logic system, and start working
on math that the very beginning and seeing how much survives your new
definition.

It is a violation of the basics of logic to try to work with an
inconsistent set of rules. Things proven under one set of definitions
can not just be 'assumed' to work in another.

You only need to recreate a few thousand years of work, but at least you
have a road map, at least until you find something that differs because
of your ne definition.

>
> The majority of philosophers agree that this cannot be done because
> Willard Van Orman Quine has convinced them that they cannot really know
> that all bachelors are unmarried.
>
> https://www.theologie.uzh.ch/dam/jcr:ffffffff-fbd6-1538-0000-000070cf64bc/Quine51.pdf
>
>

On 2022-03-09 06:03, olcott wrote:
> On 3/8/2022 11:32 PM, André G. Isaak wrote:
>> On 2022-03-08 21:20, olcott wrote:
>>> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
>>
>>>> No.  Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
>>>> "correct" nor "incorrect".  It is simply a statement about what a TM
>>>> does when presented with some input.  There has to be an associated
>>>> condition by which the correctness can be assessed, and you steadfastly
>>>> remove the conditions that Linz so clearly gives you:
>>>>
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
>>> state.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
>>> final state.
>>
>> The above doesn't jive with the nonsense you keep asserting elsewhere.
>> You keep claiming that TMs can only deal with the finite strings which
>> are their inputs.
>>
>
> From the above:
> ⟨Ĥ⟩ is the common convention for a finite string Turing machine
> description.
>
> Ĥ is the convention for Turing machine Ĥ.
>
> ⟨Ĥ⟩ ⟨Ĥ⟩ is the convention for the input to the copy of Linz H at Ĥ.qx.
>
> embedded_H is the convention for referring to the copy of Linz H
> embedded at Ĥ.qx.

I'm not sure why you're responding with all the above. I've read Linz
and I've read your previous posts so I already know how you are using
these terms.

>> But the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H is neither a finite
>> string nor an input to embedded_H. So why do you think that non-input
>> non-finite string should be a valid basis for a decision criterion
>> whereas Ĥ applied to ⟨Ĥ⟩ should not be?
>>
>
> It it always that case that every decider computes the mapping from its
> finite string input to accept or reject state.
>
> In the case of a simulating halt decider this mapping is computed on the
> basis of simulating the finite string and examining the simulated
> behavior for any infinite behavior patterns.

But the point is that in your criteria above you keep talking about the
"pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H"

Your embedded_H is *not* a pure simulator; it is a modified copy of what
you claim to be a simulating halt decider but with its accepting state
replaced by an infinite loop.

So you are asking it to base its decision on the behaviour of some
hypothetical "pure simulator" which is *not* a string nor the input to
embedded_H. Why is that allowed but it is not allowed to base a decision
on the behaviour of Ĥ (which while not a string nor an actual input is
at least a TM which embedded_H has a complete description of) applied to
⟨Ĥ⟩?

>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn  if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.
>>>>
>>>> For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
>>>> occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.
>>>>
>>>> The whole world knows why you keep omitting the condition and, instead,
>>>> claim that transitioning to Ĥ.qn "correct" with no reference to the
>>>> actual condition for correctness.  When pushed, you replace the actual
>>>> condition with your "it had to be aborted, honest, guv" waffle in place
>>>> of the proper condition derived from what Linz asserts about H to start
>>>> with.
>>>>
>>>> It's all so tediously obvious.  You won't be able to fool anyone with
>>>> it.
>>>>
>>>>> You (and Linz) continue to be under the mistaken notion that a halt
>>>>> decider must determine the halt status of the computation that
>>>>> contains itself.
>>>>
>>>> A halt decider, H, must be correct about every input -- even those
>>>> strings that include something very like an encoding of H (as is the
>>>> case for Ĥ).
>>>>
>>>
>>> You were much sloppier in your first comment that I reponded to. Halt
>>> deciders do not compute the halt status of non-finite string non-inputs.
>>>
>>>> It almost sounds like are preparing to give up on the ruse you've been
>>>> trying to pull for the last few years, and that you are going to go
>>>> back
>>>> to the "it's an invalid question nonsense" from many years ago.
>>>>
>>>>> This mistake would require a decider to base its accept or reject
>>>>> decision on a non-string, non-input.
>>>>
>>>> A decider must accept or reject every string and which one of those is
>>>> the case is determined by the input string and nothing else.
>>>> Neither I,
>>>> nor Linz, nor anyone else, has suggested otherwise.
>>>
>>> Both you and Linz incorrectly believe that embedded_H must report on
>>> the non-input non-finite string of Ĥ ⟨Ĥ⟩.
>>
>> It's not just Ben and Linz, but every single author who has ever
>> written about this particular proof. That's because it *isn't* a mistake.
>>
>
> As it turns out to actually be even an actual universal consensus does
> not guarantee truth. Prior to Pythagoras there was a universal consensus
> that the Earth was flat.

<pedantry> Your facts here are incorrect. There is no evidence to
suggest that there was a universal consensus that the earth was flat
prior to Pythagoras. </pedantry>

>> Don't you think that it's a bit telling that everyone in the universe
>> who actually *understands* how Turing Machine agrees with Linz,
>> whereas you, who have consistently demonstrated that you've never once
>> actually designed or worked with actual Turing Machines, are the only
>> one who thinks otherwise?
>>
>
> Especially not when every rebuttal to my work was like yours and
> entirely anchored in a misunderstanding of what I am even saying.
>
>> Maybe you start by learning the basics and leave talking about Turing
>> Machines to people who have actually dealt with Turing Machines.
>>
>> André
>>
>
> I am actually starting with the establishing the fundamental
> philosophical underpinnings of the notion of truth itself.

But the issue here has nothing to do with "truth" but with how Turing
Machines work.

If you were to actually look at some examples of real Turing Machines
maybe you would come to understand this. When we try to construct a TM
to compute some function one of the first steps involved is to figure
out how to encode elements of the domain of that function as strings
which can actually be passed to a TM. But the TM is still expected to
process those strings in a way which actually conforms to the function
being computed.

Consider a TM which decides whether a given integer x is even or not.
There is no way in which we can pass an actual integer to a TM, since an
integer is not a string. But we can easily come up with a way of
encoding the integer x as a string ⟨x⟩ which *can* be passed to an integer.

Whether the above TM accepts or rejects ⟨x⟩ *must* depend on whether x
is even or odd. Otherwise it isn't computing the function it purports to
compute. And if you claim it is only responsible for determining the
mapping from the string ⟨x⟩ which is its input rather than the actual
integer x, which is not its input, then any reasonable person is going
to respond with a look of utter confusion. What does it even *mean* to
talk about the evenness of ⟨x⟩ if it is not related to the evenness of
the actual integer x? Strings aren't 'even' anymore than they are 'halting'.

> The majority of philosophers agree that this cannot be done because
> Willard Van Orman Quine has convinced them that they cannot really know
> that all bachelors are unmarried.

Yes, you've already demonstrated that you are unable to appreciate the
nuance of Quine's article and have instead settled on this ridiculous
interpretation. Nobody cares.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 2022-03-09 18:42, Richard Damon wrote:

> Just like 2 + 3 = 5, even though 5 is not an input to the + operator.

It's clear what you meant, but PO is easily confused, so you really
should say that neither the integers 2 nor 3 are actually inputs. Only
strings representing these integers are inputs.

Nor, for that matter, is the integer 5 an output. Only some string
representation of 5 is an output.

But any function which purports to compute sums must base its answer on
the sum of the actual integers, not the strings which are the inputs and
outputs to a given TM.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 2022-03-09 19:17:10 +0000, olcott said:

> <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 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>
> if Ĥ applied to ⟨Ĥ⟩ halts, and
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
> contradiction tells us that our assumption of the existence of H, and
> hence the assumption of the decidability of the halting problem, must
> be false.
> </Linz:1990:320>
>
> https://www.liarparadox.org/Linz_Proof.pdf
>
> As quoted above Linz believes that the halt status decision of
> embedded_H is based on the behavior of a non-input, non-finite string:
> Ĥ applied to ⟨Ĥ⟩ rather than the actual behavior of the actual finite
> string input:
...

Your quote does not say so. Ĥ goes to Ĥ.qy if H goes to H.qy and to Ĥ.qn if
H goes to H.qn because that is how Ĥ is constructed. Your "based on" does
not come from the quote, as is easily observed.

Mikko

On 3/10/2022 3:18 AM, Mikko wrote:
> On 2022-03-09 19:17:10 +0000, olcott said:
>
>> <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 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>
>> if Ĥ applied to ⟨Ĥ⟩ halts, and
>>
>>                   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
>> contradiction tells us that our assumption of the existence of H, and
>> hence the assumption of the decidability of the halting problem, must
>> be false.
>> </Linz:1990:320>
>>
>> https://www.liarparadox.org/Linz_Proof.pdf
>>
>> As quoted above Linz believes that the halt status decision of
>> embedded_H is based on the behavior of a non-input, non-finite string:
>> Ĥ applied to ⟨Ĥ⟩ rather than the actual behavior of the actual finite
>> string input:
>  ...
>
> Your quote does not say so. Ĥ goes to Ĥ.qy if H goes to H.qy and to Ĥ.qn if
> H goes to H.qn because that is how Ĥ is constructed. Your "based on" does
> not come from the quote, as is easily observed.
>
> Mikko
>

When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

It is "easily observed" that the simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ would never
reach its final state of ⟨Ĥ⟩.qn in any finite number of steps. This is
the definition of non halting behavior.

Because embedded_H only computes the mapping from its input: ⟨Ĥ⟩ ⟨Ĥ⟩ and
not from the behavior of the computation that it is contained within: Ĥ
⟨Ĥ⟩ embedded_H would be correct to reject its input.

--
Copyright 2021 Pete Olcott

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

On 3/9/2022 8:50 PM, André G. Isaak wrote:
> On 2022-03-09 06:03, olcott wrote:
>> On 3/8/2022 11:32 PM, André G. Isaak wrote:
>>> On 2022-03-08 21:20, olcott wrote:
>>>> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
>>>
>>>>> No.  Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
>>>>> "correct" nor "incorrect".  It is simply a statement about what a TM
>>>>> does when presented with some input.  There has to be an associated
>>>>> condition by which the correctness can be assessed, and you
>>>>> steadfastly
>>>>> remove the conditions that Linz so clearly gives you:
>>>>>
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its
>>>> final state.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach
>>>> its final state.
>>>
>>> The above doesn't jive with the nonsense you keep asserting
>>> elsewhere. You keep claiming that TMs can only deal with the finite
>>> strings which are their inputs.
>>>
>>
>>  From the above:
>> ⟨Ĥ⟩ is the common convention for a finite string Turing machine
>> description.
>>
>> Ĥ is the convention for Turing machine Ĥ.
>>
>> ⟨Ĥ⟩ ⟨Ĥ⟩ is the convention for the input to the copy of Linz H at Ĥ.qx.
>>
>> embedded_H is the convention for referring to the copy of Linz H
>> embedded at Ĥ.qx.
>
> I'm not sure why you're responding with all the above. I've read Linz
> and I've read your previous posts so I already know how you are using
> these terms.
>
>>> But the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H is neither a finite
>>> string nor an input to embedded_H. So why do you think that non-input
>>> non-finite string should be a valid basis for a decision criterion
>>> whereas Ĥ applied to ⟨Ĥ⟩ should not be?
>>>
>>
>> It it always that case that every decider computes the mapping from
>> its finite string input to accept or reject state.
>>
>> In the case of a simulating halt decider this mapping is computed on
>> the basis of simulating the finite string and examining the simulated
>> behavior for any infinite behavior patterns.
>
> But the point is that in your criteria above you keep talking about the
> "pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H"
>
> Your embedded_H is *not* a pure simulator; it is a modified copy of what
> you claim to be a simulating halt decider but with its accepting state
> replaced by an infinite loop.
>
> So you are asking it to base its decision on the behaviour of some
> hypothetical "pure simulator" which is *not* a string nor the input to
> embedded_H.

embedded_H contains all of the functionality of a UTM as well as
additional halt deciding functionality. The halt deciding functionality
bases its halt status decision on matching infinite behavior patterns,
or failing to match any of these patterns.

> Why is that allowed but it is not allowed to base a decision
> on the behaviour of Ĥ (which while not a string nor an actual input is
> at least a TM which embedded_H has a complete description of) applied to
> ⟨Ĥ⟩?
>

All deciders map finite string inputs to an accept or reject state.
⟨Ĥ⟩ ⟨Ĥ⟩ are finite string inputs to embedded_H. Ĥ is neither a finite
string nor an input to to embedded_H.

>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn  if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.
>>>>>
>>>>> For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
>>>>> occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.
>>>>>
>>>>> The whole world knows why you keep omitting the condition and,
>>>>> instead,
>>>>> claim that transitioning to Ĥ.qn "correct" with no reference to the
>>>>> actual condition for correctness.  When pushed, you replace the actual
>>>>> condition with your "it had to be aborted, honest, guv" waffle in
>>>>> place
>>>>> of the proper condition derived from what Linz asserts about H to
>>>>> start
>>>>> with.
>>>>>
>>>>> It's all so tediously obvious.  You won't be able to fool anyone with
>>>>> it.
>>>>>
>>>>>> You (and Linz) continue to be under the mistaken notion that a halt
>>>>>> decider must determine the halt status of the computation that
>>>>>> contains itself.
>>>>>
>>>>> A halt decider, H, must be correct about every input -- even those
>>>>> strings that include something very like an encoding of H (as is the
>>>>> case for Ĥ).
>>>>>
>>>>
>>>> You were much sloppier in your first comment that I reponded to.
>>>> Halt deciders do not compute the halt status of non-finite string
>>>> non-inputs.
>>>>
>>>>> It almost sounds like are preparing to give up on the ruse you've been
>>>>> trying to pull for the last few years, and that you are going to go
>>>>> back
>>>>> to the "it's an invalid question nonsense" from many years ago.
>>>>>
>>>>>> This mistake would require a decider to base its accept or reject
>>>>>> decision on a non-string, non-input.
>>>>>
>>>>> A decider must accept or reject every string and which one of those is
>>>>> the case is determined by the input string and nothing else.
>>>>> Neither I,
>>>>> nor Linz, nor anyone else, has suggested otherwise.
>>>>
>>>> Both you and Linz incorrectly believe that embedded_H must report on
>>>> the non-input non-finite string of Ĥ ⟨Ĥ⟩.
>>>
>>> It's not just Ben and Linz, but every single author who has ever
>>> written about this particular proof. That's because it *isn't* a
>>> mistake.
>>>
>>
>> As it turns out to actually be even an actual universal consensus does
>> not guarantee truth. Prior to Pythagoras there was a universal
>> consensus that the Earth was flat.
>
> <pedantry> Your facts here are incorrect. There is no evidence to
> suggest that there was a universal consensus that the earth was flat
> prior to Pythagoras. </pedantry>
>
>>> Don't you think that it's a bit telling that everyone in the universe
>>> who actually *understands* how Turing Machine agrees with Linz,
>>> whereas you, who have consistently demonstrated that you've never
>>> once actually designed or worked with actual Turing Machines, are the
>>> only one who thinks otherwise?
>>>
>>
>> Especially not when every rebuttal to my work was like yours and
>> entirely anchored in a misunderstanding of what I am even saying.
>>
>>> Maybe you start by learning the basics and leave talking about Turing
>>> Machines to people who have actually dealt with Turing Machines.
>>>
>>> André
>>>
>>
>> I am actually starting with the establishing the fundamental
>> philosophical underpinnings of the notion of truth itself.
>
> But the issue here has nothing to do with "truth" but with how Turing
> Machines work.
>
> If you were to actually look at some examples of real Turing Machines
> maybe you would come to understand this. When we try to construct a TM
> to compute some function one of the first steps involved is to figure
> out how to encode elements of the domain of that function as strings
> which can actually be passed to a TM. But the TM is still expected to
> process those strings in a way which actually conforms to the function
> being computed.
>
> Consider a TM which decides whether a given integer x is even or not.
> There is no way in which we can pass an actual integer to a TM, since an
> integer is not a string. But we can easily come up with a way of
> encoding the integer x as a string ⟨x⟩ which *can* be passed to an integer.
>
> Whether the above TM accepts or rejects ⟨x⟩ *must* depend on whether x
> is even or odd. Otherwise it isn't computing the function it purports to
> compute. And if you claim it is only responsible for determining the
> mapping from the string ⟨x⟩ which is its input rather than the actual
> integer x, which is not its input, then any reasonable person is going
> to respond with a look of utter confusion. What does it even *mean* to
> talk about the evenness of ⟨x⟩ if it is not related to the evenness of
> the actual integer x? Strings aren't 'even' anymore than they are
> 'halting'.
>

On 3/10/22 9:43 AM, olcott wrote:
> On 3/10/2022 3:18 AM, Mikko wrote:
>> On 2022-03-09 19:17:10 +0000, olcott said:
>>
>>> <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 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>
>>> if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>
>>>                   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
>>> contradiction tells us that our assumption of the existence of H, and
>>> hence the assumption of the decidability of the halting problem, must
>>> be false.
>>> </Linz:1990:320>
>>>
>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>
>>> As quoted above Linz believes that the halt status decision of
>>> embedded_H is based on the behavior of a non-input, non-finite
>>> string: Ĥ applied to ⟨Ĥ⟩ rather than the actual behavior of the
>>> actual finite string input:
>>   ...
>>
>> Your quote does not say so. Ĥ goes to Ĥ.qy if H goes to H.qy and to
>> Ĥ.qn if
>> H goes to H.qn because that is how Ĥ is constructed. Your "based on" does
>> not come from the quote, as is easily observed.
>>
>> Mikko
>>
>
> When Ĥ is applied to ⟨Ĥ⟩
>   Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>
> Then these steps would keep repeating:
>   Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>   Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>   Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>
> It is "easily observed" that the simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ would never
> reach its final state of ⟨Ĥ⟩.qn in any finite number of steps. This is
> the definition of non halting behavior.

And it is "easily obseerved" that this pattern only occurs if NO copy of
embedded_H EVER aborts its simulation and goes to H.Qn.

To say that embedded_H is correct to actually go to H.Qn is like saying
it is correct to say that cats bark because your dog that you call 'cat'
barks.

FAIL.
>
> Because embedded_H only computes the mapping from its input: ⟨Ĥ⟩ ⟨Ĥ⟩ and
> not from the behavior of the computation that it is contained within: Ĥ
> ⟨Ĥ⟩ embedded_H would be correct to reject its input.
>

Right, and the mapping of the input <H^> <H^> needs to be to Halting if
embedded_H goes to Qn, BECAUSE the DEFINITION of the mapping is based on
the behavior of a REAL UTM simulating that input, and it has been shown
that UTM applied to <H^> <H^> will halt if embedded_H applied to <H^>
<H^> goes to Qn.

Thus embedded_H is INCORRECT to reject its input, as if it does, then
its input is HALTING.

FAIL.

On 3/10/22 10:06 AM, olcott wrote:
> On 3/9/2022 8:50 PM, André G. Isaak wrote:
>> On 2022-03-09 06:03, olcott wrote:
>>> On 3/8/2022 11:32 PM, André G. Isaak wrote:
>>>> On 2022-03-08 21:20, olcott wrote:
>>>>> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
>>>>
>>>>>> No.  Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
>>>>>> "correct" nor "incorrect".  It is simply a statement about what a TM
>>>>>> does when presented with some input.  There has to be an associated
>>>>>> condition by which the correctness can be assessed, and you
>>>>>> steadfastly
>>>>>> remove the conditions that Linz so clearly gives you:
>>>>>>
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its
>>>>> final state.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach
>>>>> its final state.
>>>>
>>>> The above doesn't jive with the nonsense you keep asserting
>>>> elsewhere. You keep claiming that TMs can only deal with the finite
>>>> strings which are their inputs.
>>>>
>>>
>>>  From the above:
>>> ⟨Ĥ⟩ is the common convention for a finite string Turing machine
>>> description.
>>>
>>> Ĥ is the convention for Turing machine Ĥ.
>>>
>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is the convention for the input to the copy of Linz H at Ĥ.qx.
>>>
>>> embedded_H is the convention for referring to the copy of Linz H
>>> embedded at Ĥ.qx.
>>
>> I'm not sure why you're responding with all the above. I've read Linz
>> and I've read your previous posts so I already know how you are using
>> these terms.
>>
>>>> But the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H is neither a finite
>>>> string nor an input to embedded_H. So why do you think that
>>>> non-input non-finite string should be a valid basis for a decision
>>>> criterion whereas Ĥ applied to ⟨Ĥ⟩ should not be?
>>>>
>>>
>>> It it always that case that every decider computes the mapping from
>>> its finite string input to accept or reject state.
>>>
>>> In the case of a simulating halt decider this mapping is computed on
>>> the basis of simulating the finite string and examining the simulated
>>> behavior for any infinite behavior patterns.
>>
>> But the point is that in your criteria above you keep talking about
>> the "pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H"
>>
>> Your embedded_H is *not* a pure simulator; it is a modified copy of
>> what you claim to be a simulating halt decider but with its accepting
>> state replaced by an infinite loop.
>>
>> So you are asking it to base its decision on the behaviour of some
>> hypothetical "pure simulator" which is *not* a string nor the input to
>> embedded_H.
>
> embedded_H contains all of the functionality of a UTM as well as
> additional halt deciding functionality. The halt deciding functionality
> bases its halt status decision on matching infinite behavior patterns,
> or failing to match any of these patterns.
>
>> Why is that allowed but it is not allowed to base a decision on the
>> behaviour of Ĥ (which while not a string nor an actual input is at
>> least a TM which embedded_H has a complete description of) applied to
>> ⟨Ĥ⟩?
>>
>
> All deciders map finite string inputs to an accept or reject state.
> ⟨Ĥ⟩ ⟨Ĥ⟩ are finite string inputs to embedded_H. Ĥ is neither a finite
> string nor an input to to embedded_H.
>
>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn  if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.
>>>>>>
>>>>>> For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
>>>>>> occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.
>>>>>>
>>>>>> The whole world knows why you keep omitting the condition and,
>>>>>> instead,
>>>>>> claim that transitioning to Ĥ.qn "correct" with no reference to the
>>>>>> actual condition for correctness.  When pushed, you replace the
>>>>>> actual
>>>>>> condition with your "it had to be aborted, honest, guv" waffle in
>>>>>> place
>>>>>> of the proper condition derived from what Linz asserts about H to
>>>>>> start
>>>>>> with.
>>>>>>
>>>>>> It's all so tediously obvious.  You won't be able to fool anyone with
>>>>>> it.
>>>>>>
>>>>>>> You (and Linz) continue to be under the mistaken notion that a halt
>>>>>>> decider must determine the halt status of the computation that
>>>>>>> contains itself.
>>>>>>
>>>>>> A halt decider, H, must be correct about every input -- even those
>>>>>> strings that include something very like an encoding of H (as is the
>>>>>> case for Ĥ).
>>>>>>
>>>>>
>>>>> You were much sloppier in your first comment that I reponded to.
>>>>> Halt deciders do not compute the halt status of non-finite string
>>>>> non-inputs.
>>>>>
>>>>>> It almost sounds like are preparing to give up on the ruse you've
>>>>>> been
>>>>>> trying to pull for the last few years, and that you are going to
>>>>>> go back
>>>>>> to the "it's an invalid question nonsense" from many years ago.
>>>>>>
>>>>>>> This mistake would require a decider to base its accept or reject
>>>>>>> decision on a non-string, non-input.
>>>>>>
>>>>>> A decider must accept or reject every string and which one of
>>>>>> those is
>>>>>> the case is determined by the input string and nothing else.
>>>>>> Neither I,
>>>>>> nor Linz, nor anyone else, has suggested otherwise.
>>>>>
>>>>> Both you and Linz incorrectly believe that embedded_H must report
>>>>> on the non-input non-finite string of Ĥ ⟨Ĥ⟩.
>>>>
>>>> It's not just Ben and Linz, but every single author who has ever
>>>> written about this particular proof. That's because it *isn't* a
>>>> mistake.
>>>>
>>>
>>> As it turns out to actually be even an actual universal consensus
>>> does not guarantee truth. Prior to Pythagoras there was a universal
>>> consensus that the Earth was flat.
>>
>> <pedantry> Your facts here are incorrect. There is no evidence to
>> suggest that there was a universal consensus that the earth was flat
>> prior to Pythagoras. </pedantry>
>>
>>>> Don't you think that it's a bit telling that everyone in the
>>>> universe who actually *understands* how Turing Machine agrees with
>>>> Linz, whereas you, who have consistently demonstrated that you've
>>>> never once actually designed or worked with actual Turing Machines,
>>>> are the only one who thinks otherwise?
>>>>
>>>
>>> Especially not when every rebuttal to my work was like yours and
>>> entirely anchored in a misunderstanding of what I am even saying.
>>>
>>>> Maybe you start by learning the basics and leave talking about
>>>> Turing Machines to people who have actually dealt with Turing Machines.
>>>>
>>>> André
>>>>
>>>
>>> I am actually starting with the establishing the fundamental
>>> philosophical underpinnings of the notion of truth itself.
>>
>> But the issue here has nothing to do with "truth" but with how Turing
>> Machines work.
>>
>> If you were to actually look at some examples of real Turing Machines
>> maybe you would come to understand this. When we try to construct a TM
>> to compute some function one of the first steps involved is to figure
>> out how to encode elements of the domain of that function as strings
>> which can actually be passed to a TM. But the TM is still expected to
>> process those strings in a way which actually conforms to the function
>> being computed.
>>
>> Consider a TM which decides whether a given integer x is even or not.
>> There is no way in which we can pass an actual integer to a TM, since
>> an integer is not a string. But we can easily come up with a way of
>> encoding the integer x as a string ⟨x⟩ which *can* be passed to an
>> integer.
>>
>> Whether the above TM accepts or rejects ⟨x⟩ *must* depend on whether x
>> is even or odd. Otherwise it isn't computing the function it purports
>> to compute. And if you claim it is only responsible for determining
>> the mapping from the string ⟨x⟩ which is its input rather than the
>> actual integer x, which is not its input, then any reasonable person
>> is going to respond with a look of utter confusion. What does it even
>> *mean* to talk about the evenness of ⟨x⟩ if it is not related to the
>> evenness of the actual integer x? Strings aren't 'even' anymore than
>> they are 'halting'.
>>
>
> embedded_H is only responsible for computing the mapping from its inputs
> ⟨Ĥ⟩ ⟨Ĥ⟩ to an accept or reject state based on the behavior that ⟨Ĥ⟩ ⟨Ĥ⟩
> specifies. A pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H is the ultimate
> measure of the behavior that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies.

olcott <polcott2@gmail.com> writes:

> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:

>> So you now know that everyone accepts that "deciders compute only a
>> function from input strings to accept/reject states" and you also also
>> now know that "deciders /are/ capable of reporting on the behavior of
>> Turing machines".
>>
>> You should acknowledge when you're agreed that you have been wrong about
>> something.
>
> I am not wrong.

I never really thought did agree that were wrong. I was just pointing
out your habit of glossing over so many points made to you. It means to
no agreement can ever be reached because you are always moving on by
making new mistakes. I will continue to assume that if you don't say
"no" you agree with what you are quoting.

> Deciders never report on the actual behavior of actual
> Turing machines. The closest that they get to this is is reporting on
> the behavior that a finite string Turing machine description
> specifies.

Pure sophistry. It's not "close" it's exact. To say that the string
<M>I encodes a halting computation is to report on the behaviour of the
TM M with input I.

You can insist, if you want, that we (and that includes you as well)
must always say things like

Ĥ.q0 ⟨Ĥ⟩⊢* Ĥ.qn
if ⟨Ĥ⟩ is the encoding of a TM, Ĥ that does not halt when run with
the input string ⟨Ĥ⟩.

but it won't change the fact that you are wrong about Ĥ.

>>> It is OK that you force me to use much more accurate language because
>>> this improves my professionalism.
>>
>> You show no professionalism.
>
> I am not quite yet even in the ballpark of the degree of academic
> professionalism required for publication in premier computer science
> journals.

You are not out of the grade-school ballpark yet -- calling clever
people nitwits, and repeating banal lines in ALL CAPS twenty times like
a petulant toddler.

> Any PhD professor of computer science that is an expert in the theory
> of computation on the halting problem that fully understands my work
> could translate my words into academic quality in a few days.

No they could not. Academic work must be, first and foremost, correct,
and you are not. Any qualified person who understand what you are
saying can only translate it as "don't keep working on this, go help out
at the dog shelter".

By the way, why are cranks so obsessed with PhDs? It was not so long
ago (when I was a CS professor in the US sense of the word) that all the
"PhD professors" of CS had PhDs in physics or engineering because the
subject was quite new. Anyway, a PhD is always about a very narrowly
focused picece of work. Do you think someone with a PhD in database
storage for traditional Scottish Country Dances (an actual example of
someone I worked with) will even know what you are talking about?

>>> The Linz claim to have proven that embedded_H cannot possibly
>>> determine the correct halt status of its input is refuted.
>>
>> Linz makes no such claim.
>
> Do I have to quote his verbatim words all over again?

No, because he makes no such claim. Repeating some text where he makes
no such claim is just pointless.

> <Linz>
> 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 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>
> if Ĥ applied to ⟨Ĥ⟩ halts, and
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

I don't know weather it's deliberate, but this is not a quote form
Linz. Linz says (using your notation)

"We can therefore legitimately ask what would happen if Ĥ is applied
to ⟨Ĥ⟩. From the above, identifying M with Ĥ, we get

Ĥ.q0 ⟨Ĥ⟩ ⊢* ∞

if Ĥ applied to ⟨Ĥ⟩ halts, and

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn

if Ĥ applied to ⟨Ĥ⟩ does not halt."

So, no, he is saying nothing about the embedded H here. He does not
even refer to it. You dishonestly put it back in the hope of suggesting
that maybe Linz was saying something about it. That's a million miles
from academic professionalism.

Linz simply writes out, in sequence, what we know about H' and the Ĥ
from the definition of what H does. The result is a contradictory:

> This is clearly nonsense. The
> contradiction tells us that our assumption of the existence of H, and
> hence the assumption of the decidability of the halting problem, must
> be false.
> </Linz>

>>>> (3) Even if all you want is a TM the "refutes the proof" (i.e. one that
>>>> is right only about that one impossible case), you must show a TM that
>>>> does either this:
>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>>>> or this:
>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.
>>>> (4) You don't have such a TM. You have nothing.
>>
>> I note that, again, you don't dispute that you have not such H.

And I note it again. You don't, do you?

>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> is correct as I have proven many many times.
>>
>> No. Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
>> "correct" nor "incorrect". It is simply a statement about what a TM
>> does when presented with some input. There has to be an associated
>> condition by which the correctness can be assessed, and you steadfastly
>> remove the conditions that Linz so clearly gives you:
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final state.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
> final state.

Yes, yes, we know about your other not-quite-the halting problem.
You've been flip-flopping like this for months: refer to Linz, then flip
the condition to your own silly one in the hope that no one notices this
is not Linz's Ĥ any more.

You can't seriously think that's going to work any better than the old
"yes it halts, but only because ..." or the even more ludicrous "it's
correct because of what would happen if line 15 were commented out".
You've been trying to pull some variation of this "it's correct because
of what would happen if it were not quote what it is" ruse for ages.

No one is buying it. Please find something more rewarding to do.

--
Ben.