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 <v41n5l$2kanc$7@dont-email.me>
Deutsch   English   Français   Italiano  
<v41n5l$2kanc$7@dont-email.me>

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

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: How Partial Simulations correctly determine non-halting ---Ben's
 10/2022 analysis
Date: Sat, 8 Jun 2024 08:43:17 -0500
Organization: A noiseless patient Spider
Lines: 172
Message-ID: <v41n5l$2kanc$7@dont-email.me>
References: <v3j20v$3gm10$2@dont-email.me>
 <J_CdnTaA96jxpcD7nZ2dnZfqnPudnZ2d@brightview.co.uk>
 <87h6eamkgf.fsf@bsb.me.uk> <v3kcdj$3stk9$1@dont-email.me>
 <v3l7uo$13cp$8@dont-email.me> <v3lcat$228t$3@dont-email.me>
 <v3mq9j$chc3$1@dont-email.me> <v3mrli$chc4$1@dont-email.me>
 <_gWdnbwuZPJP2sL7nZ2dnZfqn_GdnZ2d@brightview.co.uk>
 <v3nkqr$h7f9$3@dont-email.me> <v3p4ka$sk6h$1@dont-email.me>
 <v3pp7p$v133$8@dont-email.me> <v3s27e$1f9kd$1@dont-email.me>
 <v3sf1n$1gra7$11@dont-email.me> <v3sjo9$1ialb$1@dont-email.me>
 <v3skoo$1iedv$1@dont-email.me> <v3u9ej$1v7rn$1@dont-email.me>
 <v3v6i7$23l33$1@dont-email.me> <v3v70o$21qlc$3@dont-email.me>
 <v3v7j8$242e9$2@dont-email.me> <v3v7qh$21qlc$4@dont-email.me>
 <v3v8f9$242e9$3@dont-email.me> <v3v96e$39q1p$4@i2pn2.org>
 <v3v9ll$242e9$7@dont-email.me> <v3vcqi$3a78f$1@i2pn2.org>
 <HhucnUC3H-bzWP77nZ2dnZfqn_qdnZ2d@brightview.co.uk>
 <v40hlv$3bc44$2@i2pn2.org> <v40jkr$2elkd$5@dont-email.me>
 <v41kr9$3cg3t$10@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 08 Jun 2024 15:43:17 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="99ea1b6838dd1404bad406fc122dbf0f";
	logging-data="2763500"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18QqLQM2WG6Ygu7uGPjn4nc"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:n9jKMK0Bl3oazxirbPWjh2+2Yig=
Content-Language: en-US
In-Reply-To: <v41kr9$3cg3t$10@i2pn2.org>
Bytes: 10970

On 6/8/2024 8:03 AM, Richard Damon wrote:
> On 6/7/24 11:36 PM, olcott wrote:
>> On 6/7/2024 10:03 PM, Richard Damon wrote:
>>> On 6/7/24 10:43 PM, Mike Terry wrote:
>>>> On 07/06/2024 17:34, joes wrote:
>>>>> Am Fri, 07 Jun 2024 10:40:37 -0500 schrieb olcott:
>>>>>> On 6/7/2024 10:32 AM, joes wrote:
>>>>>>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>>>>>>> On 6/7/2024 10:09 AM, Python wrote:
>>>>>>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>>>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>>>>
>>>>>>>>>>>> The issue here is that I proved that DD correctly simulated 
>>>>>>>>>>>> by HH
>>>>>>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>>>>>>> When you actually try to form a rebuttal of the above you will 
>>>>>>>>>> see
>>>>>>>>>> that I am correct. So far everyone simply ignores the proof 
>>>>>>>>>> that I
>>>>>>>>>> am correct as their only rebuttal.
>>>>>>>> A {correct simulation} means that each instruction of the above x86
>>>>>>>> machine language of DD is correctly simulated by HH and 
>>>>>>>> simulated in
>>>>>>>> the correct order.
>>>>>>> And to the end. Thus it can't behave differently than direct 
>>>>>>> execution.
>>>>>> You must not be very good at programming if you believe that
>>>>>> Infinite_Recursion must be simulated "to the end"
>>>>> As I said before, if there is no end the simulation can't end either.
>>>>
>>>> PO chooses to leave his terminology ambiguous, so we have 1000 post 
>>>> threads perpetuated by little more than verbal misunderstandings.
>>>>
>>>> All PO's "simulating halt deciders" (SHD) are actually "partial 
>>>> simulating partial halt deciders":
>>>> They partially simulate their input computation, while monitoring 
>>>> the simulation state for patterns which *PO* just believes (without 
>>>> proof) indicate non-halting.  When such a pattern is detected, the 
>>>> SHD abandons its simulating activity ["aborts" its simulation], and 
>>>> returns nonhalting.  Also, PO does not claim that his SHDs decide 
>>>> all inputs correctly - or even that they halt for all inputs (which 
>>>> a decider must).  He is really just interested in the H(D,D) case.
>>>>
>>>> PO has a couple of such rules/patterns, and at least one of them is 
>>>> sound: the "tight loop" pattern.  If an input (P,I) contains a tight 
>>>> loop (like "LOOP: goto LOOP"), and assuming PO has coded the rule 
>>>> correctly, his H/HH will detect the tight loop while simulating the 
>>>> code and correctly return non-halting.  In this scenario we have a 
>>>> non-terminating computation, but PO's /partial/ simulation obviously 
>>>> ends through aborting the target.  THERE'S NOTHING WRONG WITH THAT. 
>>>> If someone wants to claim "that's not valid simulation" then right 
>>>> or wrong it's nothing more than a disagreement over use of 
>>>> terminology, and nothing is achieved by that.
>>>>
>>>> PO also has at least one /unsound/ rule: his "infinite recursive 
>>>> simulation" rule.  That rule matches computations that in fact halt. 
>>>> Despite PO's colourful language like "...until H 'sees that the 
>>>> simulation will never terminate unless blah blah'" and "...DD 
>>>> 'specifies infinite recursion to HH'" and so on, the truth is simply 
>>>> that his H is applying an unsound rule, which leads to it deciding 
>>>> incorrectly.)
>>>>
>>>> And all the stuff about "correct simulations of DD by HH never 
>>>> reaching line nn" might be correct if suitably interpreted (as 
>>>> /partial simulations/ not reaching a simulated halt state, rather 
>>>> than the /actual computation/ being examined), but its all logically 
>>>> irrelevent having little to do with actual termination of a given 
>>>> computation.
>>>>
>>>> What makes the SHD work or not work is the matching of rules 
>>>> (patterns detected in the simulated computation states) that the SHD 
>>>> uses to trigger an abort.  If a /sound/ rule matches, the SHD will 
>>>> decide correctly. If an /unsound/ rule matches it may decide 
>>>> incorrectly (as with PO's H(D,D)), or in other situations it might 
>>>> be correct "by fluke".
>>>>
>>>> If PO's H used only sound rules, it would not decide input (D,D) 
>>>> incorrectly - but unfortunately neither would it decide correctly - 
>>>> it would never terminate /for that input/.  (I find that kind of 
>>>> neat...)
>>>>
>>>>>
>>>>>>>> Anyone claiming that HH should report on the behavior of the 
>>>>>>>> directly
>>>>>>>> executed DD(DD) is requiring a violation of the above definition of
>>>>>>>> correct simulation.
>>>>>>> But those are the same. How does simulating something change it?
>>>>>> It seems to boil down to you just don't know enough about programming
>>>>>> otherwise it would occur to you that there cannot possibly exist any
>>>>>> correct rebuttal to the following:
>>>>> Answer the question. Why should the simulation differ from direct
>>>>> execution?
>>>>
>>>> [Let's assume code is properly restricted to exclude the 
>>>> complications of "cheating" in PO's x86utm environment through use 
>>>> of mutable static variables and the like.]
>>>>
>>>> Obviously they wouldn't, except in so far as "partial simulation" 
>>>> differs from "full simulation". I.e. all steps will match precisely, 
>>>> up to the point where the partial simulation is abandoned.
>>>>
>>>> And in PO's H(D,D) vs D(D) example that is exactly what the traces 
>>>> show:  The simulated and direct traces match exactly, right up to 
>>>> the point where H aborts the simulation.  (The full computation 
>>>> steps of D(D) then proceeding further until D terminates a bit later.)
>>>>
>>>> Even though I put the two traces side-by-side for PO, he still 
>>>> insists the "behaviour is different".  Well, perhaps he just means 
>>>> that the H simulation was abandonned whereas directly executed D(D) 
>>>> proceeded further and eventually terminated?  If so, then /so what/? 
>>>> I think his problem here is nothing to do with /simulations/ not 
>>>> reaching whatever line of code, but more the /reason/ that his H 
>>>> aborted - it matched his (unsound) non-halting pattern, and he just 
>>>> really really really really believes that pattern is sound.
>>>>
>>>> So now he needs to account for two "verified facts":  1)  D(D) 
>>>> computation never halts (/his unsound pattern matched!/)  2) D(D) 
>>>> computation halts when run directly.  That forces him to claim there 
>>>> are two different behaviours [/beyond/ the simple truncation of the 
>>>> aborted trace] for the one computation, and to come up with some 
>>>> Words to justify that position (like "pathological self reference", 
>>>> subjective questions) and then More Words to say that his other 
>>>> Words are "the true meaning of halting" etc. etc.  All nonsense 
>>>> flowing from not being able to accept his rule is just wrong.
>>>>
>>>>
>>>> Mike.
>>>>
>>>
>>> The last time I remember him actually trying to answer, the 
>>> difference was that the order of who started mattered, because D(D) 
>>> calling H(D,D) meant that the H(D,D) that was called doesn't get 
>>> stuck in the loop, but recognizes the loop and gets out, while when 
>>> H(D,D) simulated D(D) and that first H(D,D) sees that the simulated 
>>> H(D,D) would just get into a loop, that incorrect decision becomes 
>>> the actual behavior of that simulated H(D,D).
>>>
>>> So it is always the first H(D,D) that returns, and the second one 
>>> doesn't, which just proes that is can't be a pure function, or that 
>>> rule doesn't apply to functions whose simulation has been aborted.
>>>
>>> Of course he also think that aborting th simulation mean that hte 
>>> machine being simulate had its plug pulled at that point, so it isn't 
>>> proper to look at the direct execution after that,
>>>
>>> He clearly doesn't seem to understand how these sorts of machines work.
>>
>> DD(DD) is just like infinite recursion that gets terminated at
>> its second recursive call. DD(DD) halts only because HH(DD,DD)
>> correctly determines that its input DOES NOT HALT.
> 
> Except a potentially infinite loop that has code that breaks out of that 
> loop will halt.
> 

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If simulating halt decider H correctly simulates its input D
   until H correctly determines that its simulated D would never
   stop running unless aborted then

========== REMAINDER OF ARTICLE TRUNCATED ==========