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