Path: ...!2.eu.feeder.erje.net!feeder.erje.net!news.mb-net.net!open-news-network.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory,sci.logic
Subject: Re: Every D(D) simulated by H presents non-halting behavior to H
Date: Mon, 6 May 2024 10:16:41 -0500
Organization: A noiseless patient Spider
Lines: 225
Message-ID: <v1as8p$2kk44$1@dont-email.me>
References: <v18e32$1vbql$1@dont-email.me> <v18f9e$5asq$4@i2pn2.org>
 <v18lj3$20ukn$1@dont-email.me> <v18sq6$5asr$9@i2pn2.org>
 <v18vni$23glj$1@dont-email.me> <v19252$5asr$14@i2pn2.org>
 <v198jn$253i2$1@dont-email.me> <v199bk$5asr$15@i2pn2.org>
 <v19g2g$2aufj$4@dont-email.me> <v19h9b$5asr$17@i2pn2.org>
 <v19knj$2c1rk$1@dont-email.me> <v1abmr$7eu1$4@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 06 May 2024 17:16:42 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2ca33c147f4bf21714ceb8650be68951";
	logging-data="2773124"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+hNarAa8FsymFOzsPl7URM"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:DHWSgaovrp6O//Oem0Y/rTyAhlE=
Content-Language: en-US
In-Reply-To: <v1abmr$7eu1$4@i2pn2.org>
Bytes: 9998

On 5/6/2024 5:34 AM, Richard Damon wrote:
> On 5/6/24 12:01 AM, olcott wrote:
>> On 5/5/2024 10:03 PM, Richard Damon wrote:
>>> On 5/5/24 10:42 PM, olcott wrote:
>>>> On 5/5/2024 7:47 PM, Richard Damon wrote:
>>>>> On 5/5/24 8:35 PM, olcott wrote:
>>>>>> On 5/5/2024 5:44 PM, Richard Damon wrote:
>>>>>>> On 5/5/24 6:03 PM, olcott wrote:
>>>>>>>> On 5/5/2024 4:13 PM, Richard Damon wrote:
>>>>>>>>> On 5/5/24 3:10 PM, olcott wrote:
>>>>>>>>>> On 5/5/2024 12:22 PM, Richard Damon wrote:
>>>>>>>>>>> On 5/5/24 1:02 PM, olcott wrote:
>>>>>>>>>>>> The x86utm operating system: 
>>>>>>>>>>>> https://github.com/plolcott/x86utm enables
>>>>>>>>>>>> one C function to execute another C function in debug step 
>>>>>>>>>>>> mode.
>>>>>>>>>>>> Simulating Termination analyzer H simulates the x86 machine 
>>>>>>>>>>>> code of its
>>>>>>>>>>>> input (using libx86emu) in debug step mode until it 
>>>>>>>>>>>> correctly matches a
>>>>>>>>>>>> correct non-halting behavior pattern proving that its input 
>>>>>>>>>>>> will never
>>>>>>>>>>>> stop running unless aborted.
>>>>>>>>>>>
>>>>>>>>>>> Except that the pattern it uses is incorrect, since H(D,D) 
>>>>>>>>>>> using this "pattern" says that D(D) will not halt, where, 
>>>>>>>>>>> when main calls D(D), it does return/halt, so H is just 
>>>>>>>>>>> incorrect.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Can D correctly simulated by H terminate normally?
>>>>>>>>>>>> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
>>>>>>>>>>>> 01 int D(ptr x)
>>>>>>>>>>>> 02 {
>>>>>>>>>>>> 03   int Halt_Status = H(x, x);
>>>>>>>>>>>> 04   if (Halt_Status)
>>>>>>>>>>>> 05     HERE: goto HERE;
>>>>>>>>>>>> 06   return Halt_Status;
>>>>>>>>>>>> 07 }
>>>>>>>>>>>> 08
>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>> 10 {
>>>>>>>>>>>> 11   H(D,D);
>>>>>>>>>>>> 12 }
>>>>>>>>>>>>
>>>>>>>>>>>> *Execution Trace*
>>>>>>>>>>>> Line 11: main() invokes H(D,D);
>>>>>>>>>>>>
>>>>>>>>>>>> *keeps repeating* (unless aborted)
>>>>>>>>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that 
>>>>>>>>>>>> simulates D(D)
>>>>>>>>>>>>
>>>>>>>>>>>> *Simulation invariant*
>>>>>>>>>>>> D correctly simulated by H cannot possibly reach past its 
>>>>>>>>>>>> own line 03.
>>>>>>>>>>>
>>>>>>>>>>> Nope, PROVEN WRONG AND THE PROOF IGNORED, PO have even 
>>>>>>>>>>> claimed that it would be trivial to show the error in the 
>>>>>>>>>>> proof, but hasn't done it, showing that he doesn't actually 
>>>>>>>>>>> have an answer to the refutation, and thus by just repeating 
>>>>>>>>>>> a statment that is know to at least potentially have a 
>>>>>>>>>>> problem as if it was just clearly true is just a pathological 
>>>>>>>>>>> lie.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The above execution trace proves that (for every H/D pair of 
>>>>>>>>>>>> the
>>>>>>>>>>>> infinite set of H/D pairs) each D(D) simulated by the H that 
>>>>>>>>>>>> this D(D)
>>>>>>>>>>>> calls cannot possibly reach past its own line 03.
>>>>>>>>>>>
>>>>>>>>>>> Except that the proof shows that you are not smart enough to 
>>>>>>>>>>> think of some of the ways arround the problem (even though 
>>>>>>>>>>> those methods were discussed a long time back)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The above execution trace proves the behavior of each D 
>>>>>>>>>> simulated by
>>>>>>>>>> each H of the elements of the infinite set of H/D pairs where 
>>>>>>>>>> this D
>>>>>>>>>> calls that H.
>>>>>>>>>
>>>>>>>>> Nope, your problem is you stop simulating at the call to H and 
>>>>>>>>> then resort to incorrect logic to try to figure out what 
>>>>>>>>> happens next.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I have to usually tell you the exactly same thing several
>>>>>>>> hundreds of times before you notice that I ever said it once.
>>>>>>>>
>>>>>>>> We are talking about the infinite set of H/D pairs where
>>>>>>>> D is simulated by the same H that D calls.
>>>>>>>>
>>>>>>>> We are talking about the infinite set of H/D pairs where
>>>>>>>> D is simulated by the same H that D calls.
>>>>>>>>
>>>>>>>> We are talking about the infinite set of H/D pairs where
>>>>>>>> D is simulated by the same H that D calls.
>>>>>>>>
>>>>>>>> H that simulates the D that calls H(D,D) will simulate to
>>>>>>>> 1 ∞ steps of D.
>>>>>>>
>>>>>>> Nope, when your H simulates the call to H(D,D) inside D, your H 
>>>>>>> does NOT simulated that H, but instead simultes the machine that 
>>>>>>> that machine would be simulating.
>>>>>>>
>>>>>>
>>>>>> I am not talking about my H
>>>>>> I am talking about every element of the infinite set of
>>>>>> H/D pairs where D is simulated by the same H that D calls.
>>>>>> I will repeat this endlessly to your every post until you get it
>>>>>
>>>>> So, what does an infinite set of programs and an infinte set of 
>>>>> inputs do?
>>>>>
>>>>
>>>> I am talking about every element of the infinite set of
>>>> H/D pairs where D is simulated by the same H that D calls.
>>>>
>>>> The 1st H simulates 1 steps of D
>>>> The 2nd H simulates 2 steps of D
>>>> The 3rd H simulates 3 steps of D
>>>> ...
>>>> The 5,000,000,000 H simulates 5,000,000,000 steps of D
>>>> ...
>>>> All the way up to H that simulates ∞ steps of D
>>>>
>>>> None of these D(D) simulated by the H that D(D) calls
>>>> ever reach past their own line 03.
>>>
>>> Then they aren't doing it right.
>>>
>>
>> When HH(DD,DD) simulates its input and reaches the call
>> to repeat this process it goes ahead and repeats this
>> process simulating itself simulating DD. I don't show
>> the 251 pages of text of HH simulating itself. People
>> are totally overwhelmed with the halt a page of text
>> that I do show them.
>>
>> The hypothetical H(D,D) that I am referring to works
>> just like the actual HH(DD,DD). When HH simulates HH
>> simulating DD there is an extra 250 pages of execution
>> trace that what I show and that is only by simulating
>> DD twice. 8 lines of DD simulated twice is actually
>> 16000 lines of code.
>>
>> Simulated once   = 8 lines
>> Simulated twice  = 16,000 lines
>> Simulated thrice = 16,000^2 lines
>> The above hypothetical H does simulate itself simulating D.
>>
>> The 5 billion lines of D simulated would take
>> 5,000,000,000 / 8 = 625,000,000 simulations this
>> 251^625,000,000 pages of text to show the full execution trace.
>>
>>> In particular, I suspect they aren't simulation the CALL H 
>>> instruction right.
>>>
>>> Note, it DOESN'T go directly from "Call H" to a new layer of 
>>> simulation of D(D).
>>>
>>
>> I would have to display 251 pages of execution trace
>> of HH(DD,DD) simulating its input recursively once.
>>
>> It takes 251^2 pages to simulate it recursively twice.
>> It takes 251^3 pages to simulate it recursively thrice.
>> The hypothetical H(D,D) that I am referring to does do this.
> 
> And why does H use the infinite set of HH's?
> 

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