Deutsch   English   Français   Italiano  
<103j5o4$3d3gm$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: ChatGPT totally understands exactly how I refuted the conventional halting problem proof technique
Date: Thu, 26 Jun 2025 13:00:36 +0300
Organization: -
Lines: 116
Message-ID: <103j5o4$3d3gm$1@dont-email.me>
References: <1037cr1$1aja4$1@dont-email.me> <1038iil$enlc$1@dont-email.me> <10394o5$j159$2@dont-email.me> <103av83$140ie$1@dont-email.me> <103bq8n$1a3c8$4@dont-email.me> <103brmh$1bfio$1@dont-email.me> <103bvt3$1cjeg$1@dont-email.me> <103do8b$1ti9d$1@dont-email.me> <103easr$22250$1@dont-email.me> <103ekj4$22qb$1@news.muc.de> <103elhi$24lrk$1@dont-email.me> <103enru$22qb$2@news.muc.de> <103eo8q$25hsi$1@dont-email.me> <995bace8fe29b576c0d9410f991981143fd20046@i2pn2.org> <103epev$25ucn$1@dont-email.me> <9103e4719abf89a6964453318d3f52878a718788@i2pn2.org> <103f62i$292tp$1@dont-email.me> <103g811$2knml$1@dont-email.me> <103h4f4$2rinm$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 26 Jun 2025 12:00:36 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9532ec9cca79e56225651e6eb36dbe45";
	logging-data="3575318"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/7f4SQof2m4PvF5kUEQtfx"
User-Agent: Unison/2.2
Cancel-Lock: sha1:hiwyRlDuYUS+p/jrgeFgLQx+OuA=

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. 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 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
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.

>> 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.

-- 
Mikko