Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connections
Warning: mysqli::query(): Couldn't fetch mysqli in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\index.php on line 66
Article <usj790$1cf5q$3@i2pn2.org>
Deutsch   English   Français   Italiano  
<usj790$1cf5q$3@i2pn2.org>

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

Path: ...!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: =?UTF-8?B?UmU6IFZlcmlmaWVkIGZhY3QgdGhhdCDEpC5IIOKfqMSk4p+pIOKfqMSk?=
 =?UTF-8?B?4p+pIGFuZCBIIOKfqMSk4p+pIOKfqMSk4p+pIGhhdmUgZGlmZmVyZW50IGJlaGF2?=
 =?UTF-8?Q?ior?=
Date: Sat, 9 Mar 2024 18:52:15 -0800
Organization: i2pn2 (i2pn.org)
Message-ID: <usj790$1cf5q$3@i2pn2.org>
References: <usia2e$2f2pd$1@dont-email.me> <usiku5$2hc10$1@dont-email.me>
 <usimoo$2hnpb$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 10 Mar 2024 02:52:20 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1457338"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <usimoo$2hnpb$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5590
Lines: 100

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.