XPost: comp.theory

On 8/1/2021 5:54 AM, Ben Bacarisse wrote:

olcott <[email protected]> writes:

On 7/31/2021 5:08 PM, Ben Bacarisse wrote:

olcott <[email protected]> writes:

On 7/30/2021 2:58 PM, Ben Bacarisse wrote:

olcott <[email protected]> writes:

On 7/30/2021 7:39 AM, Ben Bacarisse wrote:

Any chance you will now say if

Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)

transitions to Ĥ.qn or Ĥ.qy? If you find this question difficult, >>>>>>> please ask for some help in understanding it.

Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn

An answer. Thank you.

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

For Ĥ to be "exactly and precisely as in Linz" this, then, is the clause >>>>> that applies to your H and Ĥ:

There is no H in the relevant last paragraph of the Linz proof that
forms the basis for the Linz conclusion.

Distraction. Everything you ignore below is about the proof and refers
only to Ĥ.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt

so Ĥ (M) applied to ⟨Ĥ⟩ (wM) does not halt, but you have just told me
that it does. That is what this full (but abbreviated) state transition >>>>> sequence means:

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

Which is it?

Ĥ0.q0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then Ĥ0.qx simulates Ĥ1 with the
⟨Ĥ2⟩ copy then
Ĥ1.q0 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then Ĥ1.qx simulates Ĥ2 with the
⟨Ĥ3⟩ copy then
Ĥ2.q0 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then Ĥ2.qx simulates Ĥ3 with the
⟨Ĥ4⟩ copy then ...

This is an abuse of the notation (but I know what you mean). There is
no Ĥ1 or Ĥ2. If you think it helps to show which copy of ⟨Ĥ⟩ your >>> simulating "decider" is either running and/or currently looking at, you
need to come up with a notation that does that.

A better notation is what I have in my PDF actual subscripts but
people here tel me that their newsreader makes sure to totally ignore
posts with HTML so that do even see the post at all.

I am happy you have a notation you like. Are you prepared to address
that fact that your H^ is not "as in Linz"?

At least I know what
this "math poem" means, because you've been saying this "it's a
simulator until" stuff for years.

The outermost Ĥ0.qx correctly decides that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩)
can't possibly ever reach its final state. Then it transitions to
Ĥ0.qn causing the outermost Ĥ0 to halt.

Apart from the bad notation, yes. All those copies and tests and
eventual deciding are neatly summed up in the last ⊢* Ĥ.qn of
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Because the outermost Ĥ0.qx did not decide that Ĥ0 would never halt
and it is self evident that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't possibly
ever reach its final state there is no contradiction or paradox and it >>>> decided correctly.

You are free to define "decide correctly" in any way you like provided
you are honest about it. But you hooked people in by saying that your Ĥ >>> is "exactly and precisely as in Linz", and you quoted, even now, what
Linz has to say about such TMs:
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
This is your quote. You brought it up. You claimed your Ĥ was as Linz >>> states -- that Ĥ.q0 wM ⊢* Ĥ.qn if and only if M applied to wM does not >>> halt. Linz makes no exceptions based on why the transitions from Ĥ.q0
wM to Ĥ.qn occur. Linz does not say
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt or if M applied wM only halts
because...
Are you now saying that your TM was not "as in Linz"? (You should,
because you've admitted that elsewhere.)

Ĥ[0] is to be interpreted to mean Ĥ₀
[0] Means the actual Turing machine and not a TM description.
[1] Means the first TM description parameter
[2] Means a copy of the the first TM description parameter

Now I am saying that when the actual unmodified Linz Ĥ is understood
to have a UTM/Halt-Decider at Ĥ[0].qx that this Ĥ[0].qx does correctly
decide that its input: (⟨Ĥ[1]⟩, ⟨Ĥ[2]⟩) can't possibly ever reach its
final state of Ĥ[1].qn or Ĥ[2].qn, therefore we know that its input
never halts therefore we know that a state transition from Ĥ[0].qx to
Ĥ0.qn is necessarily correct.

We all know you are declaring that to be correct. Here's why your Ĥ is
not "as in Linz". Linz requires that

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt

Any Ĥ that eventually transitions to Ĥ.qn on input wM must do so
if, and only if, the encoded M applied to wM does not halt. But you've
given us a case where your Ĥ is not like this:

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

*This did not show up in my other news server so I am pointing it again*

And when we eliminate the fallacy of equivocation error we have

Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ ⊢* Ĥ[0].qn

The way that you do it when your twin bother commits a crime that makes
you guilty.

Ĥ[0].q0 ⟨Ĥ[1]⟩ only halts because the simulation of the
the input to Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ was aborted.

(a) The simulation of the input to Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩
was aborted because neither ⟨Ĥ[1]⟩ nor ⟨Ĥ[2]⟩ could
ever possibly reach their final states.

(b) Because neither ⟨Ĥ[1]⟩ nor ⟨Ĥ[2]⟩ could ever possibly reach
their final states we know that they never halt.

(c) Because they never halt we know that Ĥ[0].qx correctly decided
that its input never halts.

This is the same as: X > Y & Y > Z therefore X > Z
I do seem to have a correct chain of inference.
I do not think that you can point to any error in
this chain of inference.

In an honest dialogue when you would disagree that a
chain of inference derives a correct conclusion you
would point to a specific error in this chain of inference.

What is the error in (a)(b)(c) ?

Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's behaviour "correct". You can call it anything you like. But it's not
"as in Linz". It does not say anything about Linz's proof. It does not
do anything people would call impossible or even interesting.

Presumably, you will simply explain, yet again, why you choose to call
it correct. You might even, yet again, quote the symbols from Linz that don't apply to your Ĥ in order to make you posts seem relevant.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)