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 <f6d75a87976214126cb4b8e4f3e3279fc409aacc@i2pn2.org>
Deutsch   English   Français   Italiano  
<f6d75a87976214126cb4b8e4f3e3279fc409aacc@i2pn2.org>

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

Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Defining a correct simulating halt decider --- Ridiculously
 stupid
Date: Wed, 11 Sep 2024 19:57:20 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <f6d75a87976214126cb4b8e4f3e3279fc409aacc@i2pn2.org>
References: <vb4plc$2tqeg$1@dont-email.me> <vb6o5t$3a95s$1@dont-email.me>
 <vb71a3$3b4ub$4@dont-email.me> <vbbmuc$8nbb$1@dont-email.me>
 <vbcbe4$bdtb$3@dont-email.me> <vbeoge$q2ph$1@dont-email.me>
 <vbeprp$punj$7@dont-email.me>
 <c600a691fab10473128eed2a1fad2a429ad4733f@i2pn2.org>
 <vbh2sp$19ov0$1@dont-email.me> <vbhm3c$1c7u5$12@dont-email.me>
 <vbkdph$1v80k$1@dont-email.me> <vbne7e$2g6vo$6@dont-email.me>
 <vbpbps$2uib0$1@dont-email.me> <vbsf5t$3mi21$1@dont-email.me>
 <vbsgsu$3mr32$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 11 Sep 2024 23:57:20 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1715710"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vbsgsu$3mr32$1@dont-email.me>
Content-Language: en-US
Bytes: 7966
Lines: 149

On 9/11/24 12:35 PM, olcott wrote:
> On 9/11/2024 11:06 AM, Mike Terry wrote:
>> [Repost due to Giganews server problems. Sorry if post eventually 
>> appears multiple times...]
>> On 10/09/2024 12:50, Fred. Zwarts wrote:
>>> Op 09.sep.2024 om 20:19 schreef olcott:
>>>> On 9/8/2024 9:53 AM, Mikko wrote:
>>>>> On 2024-09-07 13:57:00 +0000, olcott said:
>>>>>
>>>>>> On 9/7/2024 3:29 AM, Mikko wrote:
>>>>>>> On 2024-09-07 05:12:19 +0000, joes said:
>>>>>>>
>>>>>>>> Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:
>>>>>>>>> On 9/6/2024 6:19 AM, Mikko wrote:
>>>>>>>>>> On 2024-09-05 13:24:20 +0000, olcott said:
>>>>>>>>>>> On 9/5/2024 2:34 AM, Mikko wrote:
>>>>>>>>>>>> On 2024-09-03 13:00:50 +0000, olcott said:
>>>>>>>>>>>>> On 9/3/2024 5:25 AM, Mikko wrote:
>>>>>>>>>>>>>> On 2024-09-02 16:38:03 +0000, olcott said:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A halt decider is a Turing machine that computes the 
>>>>>>>>>>>>>>> mapping from
>>>>>>>>>>>>>>> its finite string input to the behavior that this finite 
>>>>>>>>>>>>>>> string
>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A halt decider needn't compute the full behaviour, only 
>>>>>>>>>>>>>> whether
>>>>>>>>>>>>>> that behaviour is finite or infinite.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> New slave_stack at:1038c4 Begin Local Halt Decider Simulation
>>>>>>>>
>>>>>>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation 
>>>>>>>>>>>>> Stopped
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hence  HHH(DDD)==0 is correct
>>>>>>>>>>>>
>>>>>>>>>>>> Nice to see that you don't disagree with what said.
>>>>>>>>>>>> Unvortunately I can't agree with what you say.
>>>>>>>>>>>> HHH terminates,
>>>>>>>>>>>> os DDD obviously terminates, too. No valid
>>>>>>>>>>>
>>>>>>>>>>> DDD emulated by HHH never reaches it final halt state.
>>>>>>>>>>
>>>>>>>>>> If that iis true it means that HHH called by DDD does not 
>>>>>>>>>> return and
>>>>>>>>>> therefore is not a ceicder.
>>>>>>>>> The directly executed HHH is a decider.
>>>>>>>> What does simulating it change about that?
>>>>>>>
>>>>>>> If the simulation is incorrect it may change anything.
>>>>>>>
>>>>>> PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
>>>>>> PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
>>>>>> PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
>>>>>> PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
>>>>>> PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
>>>>>
>>>>> However, a correct simultation faithfully imitates the original
>>>>> behaviour.
>>>>>
>>>>
>>>> _DDD()
>>>> [00002172] 55         push ebp      ; housekeeping
>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping
>>>> [00002175] 6872210000 push 00002172 ; push DDD
>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>>> [0000217f] 83c404     add esp,+04
>>>> [00002182] 5d         pop ebp
>>>> [00002183] c3         ret
>>>> Size in bytes:(0018) [00002183]
>>>>
>>>> A correct emulation obeys the x86 machine code even
>>>> if this machine code catches the machine on fire.
>>>>
>>>> It is impossible for an emulation of DDD by HHH to
>>>> reach machine address 00002183 AND YOU KNOW IT!!!
>>>>
>>>
>>> It seems olcott also knows that HHH fails to reach the machine 
>>> address 00002183, because it stop the simulation too soon. A correct 
>>> simulation by the unmodified world class simulator shows that it does 
>>> reach machine address 00002183. Even HHH1 shows it. But HHH fails to 
>>> machine address 00002183.
>>> Why does olcott ignore this truth? The evidence is overwhelming.
>>
>> Because his HHH has correctly identified his "Infinite recursive 
>> simulation" pattern in the behaviour of DDD.  To PO, that means DDD is 
>> non-halting, EOD.
>>
>> PO is aware that the /full/ simulation of DDD() (e.g. as shown by HHH1 
>> simulating) shows DDD terminating - 
> 
> Ridiculously stupid to simply ignore that DDD calls
> HHH(DDD) in recursive emulation and does not call HHH1
> in recursive emulation.

He isn't. He is just claiming we need to CORRECTLY handle what it does.


> 
> I saw your identical twin brother Bill rob the liquor
> store thus proving that you (John) robbed the liquor store.
> 
> This is true even though I could see that Bill has a
> mole on his right cheek that you (John) do not have.

Your bad analogies just prove how stupid and ignorant you are.

> 
>> so how can it be that when HHH spots its infamous pattern, DDD is 
>> "exhibiting non-halting behaviour", despite its "actual" behaviour 
>> being halting PLAINLY VISIBLE IN THE SIMULATION TRACE FROM HHH1?   Hmmm.
>>
>> This is a dilemma for PO and he has no sensible answer to this.  It is 
>> demonstrated that DDD() halts (e.g. using HHH1 to simulate), and yet 
>> it is also "demonstrated" that DDD "exhibits non-halting behaviour" by 
>> matching his "non-halting" pattern (EOD).  The ONLY POSSIBILITY (in 
>> PO's mind) is that the behaviour must somehow be /different/ between 
>> HHH1 simulating DDD (=halts) and HHH simulating DDD (="exhibits non- 
>> halting behaviour").  It does not matter to PO that the traces show 
>> that the behaviour is EXACTLY THE SAME regardless of the simulator 
>> (..up to the point where one simulator chooses to abort of course..).  
>> Even when the two traces are displayed for him side by side and match 
>> x86 instruction for x86 instruction, PO is not convinced.
>>
>> The more obvious explanation that PO is simply Wrong about his 
>> "Infinite recursive simulation" pattern never occurs to him, and yet 
>> he also never seriously attempts any proof that the rule is sound.  
>> The only attempt I recall started by PO stipulating an axiom that said 
>> that when a trace satisfies the test conditions, it can never halt!  
>> (Yeah, this despite the HHH1 trace output showing that the pattern 
>> matching [*] AND the simulated DDD proceding to halt some time later.  
>> TBF that output may not have been published at that point...)
>>
>> This was the state of play 2 or 3 years ago, and absolutely nothing 
>> has progressed since then, other than the passing of 100000(?) posts 
>> arguing the same points over and over!
>>
>> Regards,
>> Mike.
>>
>> [*] the pattern occurs in HHH1's simulated DDD trace and is visible in 
>> the published output, although HHH1 was /not checking/ for that 
>> pattern due to miscodings on PO's part, which is why HHH1 did not 
>> abort the simulation, despite supposedly being a copy of HHH.
>>
> 
>