Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details

On 6/1/24 10:37 AM, olcott wrote:

On 6/1/2024 2:52 AM, Mikko wrote:

On 2024-05-31 15:35:18 +0000, olcott said:

 

>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

>
Of those two lines one is false.
As embedded_H is a copy of H both lines imply that H is not a halt decider.
>

*Formalizing the Linz Proof structure*
∃H  ∈ Turing_Machines
∀x  ∈ Turing_Machine_Descriptions
∀y  ∈ Finite_Strings
such that H(x,y) = Halts(x,y)

>
As already noted, the above is not a part of a proof structure.
>

 Unless and until you provide reasoning to back that up it counts
as if you said nothing about it.

YOU ARE THE ONE Claiming it is.
I guess you don't understand about Russel's teapot.

 

That <is> what Linz is claiming is false.
*Here is the same claim with 100% complete specificity*
such that H(⟨Ĥ⟩, ⟨Ĥ⟩) != Halts(⟨Ĥ⟩, ⟨Ĥ⟩)

>
That does not make sense. Every H such that H(⟨Ĥ⟩, ⟨Ĥ⟩) != Halts(⟨Ĥ⟩, ⟨Ĥ⟩)
is uninteresting.
>

 *Unless it is proven that there is a fatal flaw in the proof*

But your proof has been shown to have the fatal flaw.
You are just proving you don't understand enough of what you are talking about to understand the problem

 

*A quick summary of the reasoning provided below*
The LHS is behavior that embedded_H is allowed to report on.

>
There is no restrictions on what embedded_H is allowed to report on.

 embedded_H is only allowed to report on the behavior that its finite
string Turing Machine Description specifies to a UTM.trace H^ (H^) to Qn and it will halt, thus eyour embedded_H will halt.

And that is the problem it can't.
Remember, if embedded_H (H^) (H^) goes to Qn, then it can be shown that UTH (H^) (H^) will

 embedded_H <is> a UTM except that it stops simulating and reports
non-halting as soon as it correctly recognizes a non-halting behavior
pattern that is specified by its input.

Which means it isn't a UTM.
You seem to think that if you take an electric car are replace the electric motor with an internal combustion engine, that you still have an electric car.

 When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 (a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d)

If that IS what happens, then neither H nor embeeded_H will ever answer and thus are not deciders.
You must look at the ACTUAL behavior of the machine, not the behavior of some other machine where "embedded_H" isn't the machine it is.

 embedded_H is not allowed to be applied to Ĥ ⟨Ĥ⟩ because inputs can
only be finite strings and Ĥ is not a finite string. This means
that embedded_H is not allowed to report on its own actual behavior.

But (H^) (H^) represent the machine H^ (H^), and as you said earlier, H / embedded_H are supposed to answer about their input give to a UTM, and that definiton says that UTM (H^) (H^) will have, BY DEFINITION, the exact same final behavior as H^ (H^), so while H / embedded_H was given the input (H^) (H^) the behavior it needs to decide on it the behavior of H^ (H^) as expressed by UTM (H^) (H^) which is by definition the same.

 embedded_H only allowed to report on the behavior specified by its
finite string input. That behavior never stops running for 1 to ∞ steps
of ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H.

Nope. Remember, embedded_H is a SPECIFIC machine that this point, so it wlll always simulate this given input (also based on this specific embedded_H) for a fixed number of steps before it aborts.

 

The only reauirement is that embedded_H has the same transition
rules as H. Therefore embedded_H reports the same as H, whether
allowed or not.
>

 Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ derives a different result than
embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩.

Nope, Can you show that?
He uses the fact that if we assume that all copies of H do the correct thing, we get a contradiction. You don't seem to understand how proof by contradiction works, maybe because your world seems to be based on the assumption that contradictions are not a problem, which is why your logic systems just fail.

 This is because the in the latter case embedded_H must determine that
⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly stop running
after 1 to ∞ steps of correct simulation. Thus embedded_H meets its
abort simulation criteria.
 

Where does he say that?

The former case of Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ can see that embedded_H
has already aborted its simulation, thus it never reaches its own
abort criteria.
 It is only because everyone since 1936 has rejected simulation
OUT-OF-HAND without review that no one ever noticed this before.

Nope, you just don't unerstand what people have been talking about since you have decided to talk about things you haven't actually studied.

 

The RHS is behavior that embedded_H NOT is allowed to report on.
The LHS and the RHS specify different behaviors.

>
You have not shown anything with behaviours as LHS and RHS.
>

Please to not reply here instead reply at the end of my proof
after all of the steps have been presented.

>
Not a reasonable request. Correctness of a step of proof does not
depend on what follows. If one step is erroneous the rest is
irrelevant.
>