Re: Verified fact that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ have different behavior

On 3/9/24 2:10 PM, olcott wrote:

On 3/9/2024 3:39 PM, immibis wrote:

On 9/03/24 19:33, olcott wrote:

*Verified fact that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ have different behavior*

>
It is only verified that you would like them to have different behaviour, not that they actually do.
>

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt

>
∞ means it doesn't halt
>

Execution trace of Ĥ applied to ⟨Ĥ⟩
(a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to Ĥ.H
(b) Ĥ.H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
(c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the process

>

*This proves that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation*

>
I DON'T CARE what it MUST do, only what it ACTUALLY does. You fail to realize this or you are dishonestly ignoring this.
>
Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ does abort its simulation. This is a verified fact.

 As Richard correctly pointed out this is not a verified fact.
The only verified fact here is that when Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ meets is
spec then it aborts its simulation.
 

Ĥ ⟨Ĥ⟩ halts. This is a verified fact.
>

Only within the assumption that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ meets its spec.
 

*This is a verified fact*
When simulating halt deciders always report on the behavior of
their simulated input from their own POV then when Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
transitions to Ĥ.Hqn it is correct from its own POV.

>
Nobody cares about POV. There is no POV in the halting problem. The program halts, or it doesn't halt. End of story.
>

This criteria is the only criteria where Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ knows what
wrong answer to provide that enables H ⟨Ĥ⟩ ⟨Ĥ⟩ to provide the
correct answer. Historically Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ would simply loop and
never reach either Ĥ.Hqy or Ĥ.Hqn.
 

Ĥ ⟨Ĥ⟩ halts. This is a verified fact.
>

Not it is not. It only halts if Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ meets its design spec
and a Turing machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ might not be able to do that.
 <snip issues already addressed>
 

Because Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ seem to be identical machines
on identical input that have different behavior we must
somehow explain how they are not identical machines with
identical inputs.

>
I agree. But please understand: Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ are stipulated to be identical because they are Turing machines, and identical Turing machines with identical input always produce identical output. The Linz proof does not work for other types of machines.
>

 I generally agree that a pair of identical machines
must have the same behavior on the same input.
 This may not apply when these machines having identical
states and identical inputs:
 (a) Are out-of-sync by a whole execution trace or
 (b) When one of the machines is embedded within another machine
that would cause this embedded machine to have recursive
simulation that the non-embedded machine cannot possibly have.
 *I think that the actual difference is the latter case because*
*we have the exact same issue when the infinite loop is removed*
 Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ can possibly get stuck in recursive simulation and
H ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly get stuck in recursive simulation.
 

The halting problem is uncomputable with Olcott machines, but the proof is different. In the Olcott machine version of the Linz proof, Ĥ.H isn't an identical copy of H, but it does compute identical output when the input is identical.

 If Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ cannot meet this criteria as a Turing machine then
it is still that case that Ĥ ⟨Ĥ⟩ either halts or fails to halt.
 It may fail to halt by looping without ever transitioning to
Ĥ.Hqy or Ĥ.Hqn. I see no reason why H ⟨Ĥ⟩ ⟨Ĥ⟩ cannot see this.
 

Because if H tries to wait to see what H^ does, then so does H^.H, and so does the machine that is simulating, ...
So, Either H aborts its simulation before it knows (and then all do) or it doesn't abort its simulation, and gets stuck in an infinite simulation.