Re: Refutation of the Peter Linz Halting Problem proof 2024-03-05 --partial agreement--

On 3/8/2024 12:58 PM, immibis wrote:

On 8/03/24 19:12, olcott wrote:

On 3/8/2024 11:57 AM, immibis wrote:

On 8/03/24 18:25, olcott wrote:

On 3/8/2024 1:47 AM, Richard Damon wrote:

On 3/7/24 11:29 PM, olcott wrote:

On 3/8/2024 12:48 AM, Richard Damon wrote:

On 3/7/24 10:30 PM, olcott wrote:

On 3/8/2024 12:09 AM, Richard Damon wrote:

On 3/7/24 9:38 PM, olcott wrote:

On 3/7/2024 9:53 PM, Richard Damon wrote:

On 3/7/24 7:29 PM, olcott wrote:

On 3/7/2024 8:34 PM, Richard Damon wrote:

On 3/7/24 6:02 PM, olcott wrote:

On 3/7/2024 7:35 PM, immibis wrote:

On 7/03/24 18:05, olcott wrote:

On 3/7/2024 8:47 AM, immibis wrote:

On 7/03/24 03:40, olcott wrote:

On 3/6/2024 8:22 PM, immibis wrote:

On 7/03/24 01:12, olcott wrote:

On 3/6/2024 5:59 PM, immibis wrote:

On 7/03/24 00:55, olcott wrote:

Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>
H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.

>
What are the exact steps which the exact same program with the exact same input uses to get two different results?
I saw x86utm. In x86utm there is a mistake because Ĥ.H is not defined to do exactly the same steps as H, which means you failed to do the Linz procedure.

>
Both H(D,D) and H1(D,D) answer the exact same question:
Can I continue to simulate my input without ever aborting it?
>

>
Both H(D,D) and H1(D,D) are computer programs (or Turing machines). They execute instructions (or transitions) in sequence, determined by their programming and their input.

>
Yet because they both know their own machine address
they can both correctly determine whether or not they
themselves are called in recursive simulation.

>
They cannot do anything except for exactly what they are programmed to do.

>
H1(D,D) and H(D,D) are programmed to do this.
Because H1(D,D) simulates D(D) that calls H(D,D) that
aborts its simulation of D(D). H1 can see that its
own simulated D(D) returns from its call to H(D,D).
>

>
An Olcott machine can perform an equivalent operation.
>
Because Olcott machines are essentially nothing more than
conventional UTM's combined with Conventional Turing machine
descriptions their essence is already fully understood.
>
The input to Olcott machines can simply be the conventional
space delimited Turing Machine input followed by four spaces.
>
This is followed by the machine description of the machine
that the UTM is simulating followed by four more spaces.

>
To make the Linz proof work properly with Olcott machines, Ĥ should search for 4 spaces, delete its own machine description, and then insert the description of the original H. Then the Linz proof works for Olcott machines.

>
That someone can intentionally break an otherwise correct
halt decider

>
It always gives exactly the same answer as the working one, so how is it possibly broken?
>

>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>
When this is executed in an Olcott machine then
Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>

>
WHY?
>
The Master UTM will not change the usage at H^.H, because that is just an internal state of the Machine H^
>

>
The ONLY thing that the master UTM does differently is append
the TMD to the TMD's own tape.

>
Right, so it gives H and H^ that input.
>
H^ can erase that input and replace it.
>

>

At that point we have the IDENTICAL set of transitions (with just an equivalence mapping of state numbers) as H will have, and the EXACT same input as H

>
it is stipulated by the definition of Olcott machines
Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)

>
Nope.
>
H^.H isn't a "Olcott Machine" it is a sub-machine of H^

>
You already know that there is no such thing as sub-machines of
Turing machines. Turing machines have a set of states and a tape.
They have no sub-machines.

>
A "Sub-Machine" of a Turing Machine is where you put a copy of another Turing Machine into the state space of the overall/parent machine,
>
When the machine H^ reaches the state H^.H, then it encounters the EXACT sequence of states (after the eqivalence mapping generated when inserting them H's q0 -> H^.Hqo and so on)
>
It is called a sub-machine because it acts largely as if that Turing Machihe "called" the equivalent Turing Machine as a subroutine, only the machine code was expanded "inline".

>
There is no way that any conventional Turing machine can tell
that the states of another Turing machine are embedded withing it.

>
It doesn't need to "KNOW", but it HAS THEM there.
>
It was DESIGNED that way, so the programmer knows what he did.
>

>
immibis thought that Ĥ could copy external <H> on top of internal <Ĥ>
Your words seemed to agree with this.

>
It can't get the <H> from an external source, but can have a copy of that inside of it and use that to replace it.
>

>
Not unless it is yet another parameter, thus diverges
too far from the original Linz.

>
Why can't a Turing machine write the finite string <H> onto its own tape?

>
Unless it is an extra parameter it has no basis for doing this.
If it is an extra parameter then it is no longer the Linz proof.
>

 So it's impossible to make a Turing machine that writes 12345 onto its tape unless 12345 is a parameter?

That is a valid point.
It is impossible to get me to talk about that until
we first have full closure that the Linz H correctly
determines the halt status of the Linz Ĥ ⟨Ĥ⟩ when run
in the Olcott master UTM.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer