Re: ChatGPT totally understands exactly how I refuted the conventional halting problem proof technique

On 6/26/2025 5:00 AM, Mikko wrote:

On 2025-06-25 15:26:28 +0000, olcott said:
 

On 6/25/2025 2:21 AM, Mikko wrote:

On 2025-06-24 21:41:37 +0000, olcott said:
>

On 6/24/2025 4:07 PM, joes wrote:

Am Tue, 24 Jun 2025 13:06:22 -0500 schrieb olcott:

On 6/24/2025 12:57 PM, joes wrote:

Am Tue, 24 Jun 2025 12:46:01 -0500 schrieb olcott:
>

It is an easily verified fact that no *input* to any partial halt
decider (PHD) can possibly do the opposite of what its corresponding
PHD decides. In all of the years of all of these proofs no such
*input* was ever presented.

>
You should clarify that you don't even think programs can be passed as
input.
>

It is common knowledge the no Turing Machine can take another directly
executed Turing Machine as an input.

So common that nobody would suggest such. You are the king of strawmen.

>
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
   if Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
   if Ĥ applied to ⟨Ĥ⟩ does not halt
>
Ĥ applied to ⟨Ĥ⟩ does not have embedded_H reporting on
the behavior specified by its input ⟨Ĥ⟩ ⟨Ĥ⟩ it has embedded_H
reporting on its own behavior.

>
As made clear in the source text, embedded_H does the same as
H when given the same input. The only difference is that if
that same behaviour reaches its qy state then H halts there
but Ĥ runs forever in a tight loop.

>
*You are not getting the main point*
The fact that Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to ⟨Ĥ.qn⟩ is
not contradicted by the fact that Ĥ.embedded_H itself halts.

 That is not the main point.

It is the *only* reason why
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
is incorrectly construed as being incorrect.

The main point is that Ĥ ⟨Ĥ⟩ halts if
iH ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qn but not if H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to
Ĥ.qy. Anything said about embedded_H is merely an intermediate
step in the proof of the main point if not totally irrelevant.
 

Because Ĥ.embedded_H cannot possibly take any directly
executing TM as its input that makes the behavior of
Ĥ applied to ⟨Ĥ⟩ outside of the domain of Ĥ.embedded_H.

 Irrelevant. It can and does take the same input as H and from that
computes the same as H. That is all that is needed for the proof.
 

Since Turing Machines cannot take directly executing
Turing Machines as inputs this means that the directly
executed Ĥ applied to ⟨Ĥ⟩ is not in the domain of
Ĥ.embedded_H, *thus no contradiction is ever formed*

>
False. That Turing Machines cannot take directly executing
Turing Machnes as inputs is irrelevant.

>
Directly executing TM's are not in the domain of any
halt decider.

 The definition of a halt decider requires that a halt decider
correctly predicts whether a direct execution halts

That has always been incorrect because no Turing machine
can ever take any directly executing Turing machine as
its input all of these directly executed Turing machines
are outside of the domain of any partial halt decider.
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
is correct because ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
Ĥ.embedded_H cannot possibly reach its own simulated
final halt state ⟨Ĥ.qn⟩.
Because Ĥ applied to ⟨Ĥ⟩ is outside of the domain of
Ĥ.embedded_H the fact that Ĥ applied to ⟨Ĥ⟩ halts does
not contradict the fact that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated
by Ĥ.embedded_H cannot possibly reach its own simulated
final halt state ⟨Ĥ.qn⟩.

if the
computation specified by the input will be directly executed.
 

The definition of
"halting decider" requires that the decider thakes a
description of a Turing machine and a an input to it.

>
Yes.
>

From the construction of Ĥ follows that the domain of Ĥ is
the same as the required domain of a halt decider. As the

>
Maybe, IDK. What I do know is that
Ĥ applied to ⟨Ĥ⟩ outside of the domain of Ĥ.embedded_H.

 The proof does not specify a domain fro embedded_H. Instead it

Yet everyone that that knows what TM's are knows that they
only take finite strings as inputs thus never take directly
executing TM's as inputs.

specifies that for every input, including ⟨Ĥ⟩ ⟨Ĥ⟩, and including
every input outside of the domain of H, the result embedded_H
gives is the same as the result H gives. Otherwise embedded_H
is not correctly constructed.
 

That the behavior of DDD correctly simulated by HHH is
different than the behavior of DDD correctly simulated
by HHH1 is an established fact that seems too difficult
for you.
People that "just don't believe in" execution traces make
the same kind error as people that "just don't believe in"
arithmetic.

proof proves H does not do what a halting decider is
required to do

>
It is required to take a directly executing TM as input.
   and
It is not allowed to take a directly executing TM as input.
>

when the input is <Ĥ> <Ĥ>, contradicting
the claim that H is a halting decider.

>
*It never has been doing any such thing*

 You have not shown that a premise is not true. You have not shown
that an inference is not truth preserving. Therefore you have not
shown that the conclusion is not known to be true.
 

When Ĥ.embedded_H is a simulating partial halt decider
then Ĥ.embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ specifies recursive
simulation that cannot possibly reach its own simulated
final halt state of ⟨Ĥ.qn⟩.

 Which is perfectly compatible with the hypothesis that H is not a
halting decider.
 

Both HHH1(DDD) and HHH(DDD) get the correct answer for
their input.
HHH(DDD) includes HHH simulating itself simulating DDD.
HHH1(DDD) *does not* include HHH1 simulating itself simulating DDD.
This changes the behavior of DDD.
This is so dead obvious to me that I have a very hard
time accepting that others with CS degrees cannot see this.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer