On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
> 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"

This is good.

> and you also also
>>> now know that "deciders /are/ capable of reporting on the behavior of
>>> Turing machines".

This contradicts the prior sentence:
(a) A decider only takes finite string inputs. // prior sentence
(b) A decider takes Turing machine (thus non-finite string) inputs. //
current sentence

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

Your own words contradicted themselves so it is you mistake and not mine.

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

Deciders take finite string inputs that specify Turing machine
computations.

Deciders do not take Turing machine inputs.

> 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 Ĥ.
>

Both you and Linz get confused because both you and Linz leave out key
details.

Ĥ.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.

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⟩...

Thus proving that the input ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H never
reaches its own final state ⟨Ĥ⟩.qn in any finite number of steps of pure
simulation.

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

It is required that I repeat some points many times to get you to
finally quit simply ignoring these crucially important points. I usually
wait for five back and forth exchanges before I realize that you intend
to perpetually ignore a crucial point.

If you would be more respectful and never ignore any crucially important
point I would never need to do this.

The biggest step towards an academic degree of professionalism is my
statement that all deciders compute the mapping from their finite string
inputs to an accept of reject state.

This is a big step because I have finally specified the notion of a
computable function precisely correctly and succinctly.

>> 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".
>

So far the maximum logical basis that anyone has presented in their
attempt to form a rebuttal is "we really really don't believe you".

> 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

Doubtful. Most are associate professors or assistant professors and all
of these have a PhD. There is only one Distinguished Professor that I
know of: Saul Kripke, (originally from mu home town) that only has a
bachelors degree.

> "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?
>

You simply ignored the rest of the details of qualifications that I
specified:

professor of computer science that is an expert in the theory
of computation on the halting problem that fully understands my work

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

The Linz notation glosses over key details.

> "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 is referring to Ĥ and simply deleting some of its key state
transitions as if they don't exist. He is not being dishonest he is only
trying to be concise. The effect, however is self deception.

Here is his original notation before he simply deleted part of it
q0 Wm ⊢* Ĥq0 Wm Wm ⊢* ∞
q0 Wm ⊢* Ĥq0 Wm Wm ⊢* Ĥ y1 qn y2

Here is my correction, simplification and clarification of his notation
in the case where Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

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

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

You and Linz both remain confused into thinking that a decider is
supposed to report on its own actual behavior rather than the behavior
that its finite string input specifies.

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

The claim that I unequivocally proved is that if embedded_H did reject
its input it would be correct. Linz claims that whether embedded_H
accepts or rejects its input it is incorrect.

He makes this mistake because he truncated key details of the
specification of Ĥ in his analysis of the behavior of Ĥ. This caused him
to conflate the behavior of the computation that contains embedded_H
with the behavior specified by the input to embedded_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.
>
> 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.
>

It is exactly Linz with the mistake of Linz removed.

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

It is the case that the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ never
halts no matter what embedded_H would or would not do:

(a) embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ never aborts its simulation thus the simulated
input never reaches its final state of ⟨Ĥ⟩.qn.

(b) embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation thus the simulated input is
aborted before reaching its final state.

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⟩...

embedded_H either simulates its input or aborts this simulation.

--
Copyright 2021 Pete Olcott

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