Path: ...!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: Can you see that D correctly simulated by H remains stuck in
 recursive simulation?
Date: Fri, 24 May 2024 23:28:24 -0500
Organization: A noiseless patient Spider
Lines: 171
Message-ID: <v2rpda$2nvot$1@dont-email.me>
References: <v2nsvh$1rd65$2@dont-email.me> <v2pg3r$27s2r$2@dont-email.me>
 <v2qhlc$2dpfr$5@dont-email.me> <v2qihn$1vblq$2@i2pn2.org>
 <v2qrnf$2fesr$3@dont-email.me> <v2qvar$1vblp$2@i2pn2.org>
 <v2r1dn$2ge4f$4@dont-email.me> <v2r3r0$2h2l7$1@dont-email.me>
 <v2r7cq$1vblq$10@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 25 May 2024 06:28:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="010db72b80f31f696ef17c51994f71bb";
	logging-data="2883357"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19wWY8/tVJx7bgU4oRdjGKa"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Hme+qM7sP+Gu2rem6mtFbzk6vPE=
Content-Language: en-US
In-Reply-To: <v2r7cq$1vblq$10@i2pn2.org>
Bytes: 8353

On 5/24/2024 6:20 PM, Richard Damon wrote:
> On 5/24/24 6:20 PM, olcott wrote:
>> On 5/24/2024 4:39 PM, olcott wrote:
>>> On 5/24/2024 4:03 PM, Richard Damon wrote:
>>>> On 5/24/24 4:01 PM, olcott wrote:
>>>>> On 5/24/2024 12:25 PM, Richard Damon wrote:
>>>>>> On 5/24/24 1:10 PM, olcott wrote:
>>>>>>> On 5/24/2024 2:37 AM, Fred. Zwarts wrote:
>>>>>>>> Op 23.mei.2024 om 19:04 schreef olcott:
>>>>>>>>> typedef int (*ptr)();  // ptr is pointer to int function in C
>>>>>>>>> 00       int H(ptr p, ptr i);
>>>>>>>>> 01       int D(ptr p)
>>>>>>>>> 02       {
>>>>>>>>> 03         int Halt_Status = H(p, p);
>>>>>>>>> 04         if (Halt_Status)
>>>>>>>>> 05           HERE: goto HERE;
>>>>>>>>> 06         return Halt_Status;
>>>>>>>>> 07       }
>>>>>>>>> 08
>>>>>>>>> 09       int main()
>>>>>>>>> 10       {
>>>>>>>>> 11         H(D,D);
>>>>>>>>> 12         return 0;
>>>>>>>>> 13       }
>>>>>>>>>
>>>>>>>>> The above template refers to an infinite set of H/D pairs where 
>>>>>>>>> D is
>>>>>>>>> correctly simulated by pure function H. This was done because many
>>>>>>>>> reviewers used the shell game ploy to endlessly switch which 
>>>>>>>>> H/D pair
>>>>>>>>> was being referred to.
>>>>>>>>>
>>>>>>>>> *Correct Simulation Defined*
>>>>>>>>>     This is provided because every reviewer had a different 
>>>>>>>>> notion of
>>>>>>>>>     correct simulation that diverges from this notion.
>>>>>>>>>
>>>>>>>>>     A simulator is an x86 emulator that correctly emulates at 
>>>>>>>>> least one
>>>>>>>>>     of the x86 instructions of D in the order specified by the x86
>>>>>>>>>     instructions of D.
>>>>>>>>>
>>>>>>>>>     This may include correctly emulating the x86 instructions 
>>>>>>>>> of H in
>>>>>>>>>     the order specified by the x86 instructions of H thus 
>>>>>>>>> calling H(D,D)
>>>>>>>>>     in recursive simulation.
>>>>>>>>>
>>>>>>>>> *Execution Trace*
>>>>>>>>>     Line 11: main() invokes H(D,D); H(D,D) simulates lines 01, 
>>>>>>>>> 02, and 03
>>>>>>>>>     of D. This invokes H(D,D) again to repeat the process in 
>>>>>>>>> endless
>>>>>>>>>     recursive simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Of course this depends very much on the exact meaning of 
>>>>>>>> 'correct simulation', or 'correctly emulating'. 
>>>>>>>
>>>>>>> Not when these are defined above.
>>>>>>>
>>>>>>>> E.g., take the call to H(p, p). If H recognizes that it is a 
>>>>>>>> call to a H with the same algorithm as is it using itself, and 
>>>>>>>> it knows that itself returns a certain integer value K, than it 
>>>>>>>> can be argued that it is a correct emulation to substitute the 
>>>>>>>> call to H with this integer value K, which is assigned to 
>>>>>>>> Halt_Status. Then the simulation of D can proceed to line 04.
>>>>>>>> What we need is an exact definition of 'correct simulation', in 
>>>>>>>> this 
>>>>>>>
>>>>>>> No, you simply need to pay complete attention to the fact that this
>>>>>>> has already been provided.
>>>>>>>
>>>>>>> I have been over the exact same issue with dozens and dozen of 
>>>>>>> people
>>>>>>> though hundreds and hundreds of messages over two years.
>>>>>>
>>>>>> Excpet that we have two contradictory definitions present, 
>>>>>
>>>>> Yes you have a definition of simulation where the x86 machine
>>>>> language of D is simulated incorrectly or in the wrong order.
>>>>
>>>> Nope. The UTM definition still simulates EVERY x86 machine language 
>>>> instruction of D simulated correctly in the exact order. The added 
>>>> requirement is that we look at a simulation that is never aborted.
>>>
>>> H is a pure function that always returns 56 at some point other
>>> than that H is isomorphic to a UTM.
>>>
>>
>> I have learned from decades as a software engineer that complexity
>> is only manageable when it is isolated and minimized.
>>
>> It is impossible to correctly understand termination analyzer H until
>> after one first has 100% perfectly complete and total understanding of
>> pure function simulator H/D pairs.
>>
> 
> 
> So, do you agree with my comments about what you actual definitons are, 
> and what they imply?
> 

No I only agree that you are doing everything that you can to derail
an honest dialogue and it cannot possibly succeed against the basis
of my raw facts basis.

> That you H, by just needing to be a "Pure Funtion" is not necessarily 
> the computatinal eqivalent of a Turing Machine.
> 

Totally moot for the subject line.

> That your definition of "Correct Simulation" differs from that used in 
> Computation Theory, 

Totally moot for the subject line.

> and thus the fact that H does abort its simulation 
> means it is NOT a "UTM equivalent" and that your aborted correct 
> simulation not reaching a final state is not =, by itself, proof that 
> the machine represented by the input is non-halting.
> 

The easily verified fact that for the infinite set of H/D pairs
where D is correctly simulated by pure function H that no D ever
reaches its own line 06 and halts.

It is like I say red cars are red in color and you disagree by saying 
blue cars are not red in color.

> That you definition of "Correct Simulation" means that H actually 
> simulated a call to H by going into H and looking at those instructions, 

*YOU KEEP READING THINGS INTO MY SPEC THAT ARE JUST NOT THERE*
*YOU KEEP READING THINGS INTO MY SPEC THAT ARE JUST NOT THERE*
*YOU KEEP READING THINGS INTO MY SPEC THAT ARE JUST NOT THERE*

H is exactly a UTM except that it eventually halts and returns
56 even on non-halting inputs. Think of each H as counting the
number of instructions that it simulates and then stopping.

> and not switch to looking at the machine the simulation being simulated 
> is simulating.
> 
> I will also add, that you agree that if you get the agreement that if H 
> can do this, then you will produce an actual H that meets the 
> requirements, and not just claim that it must be trivial to write, and 
> such example program actually gives the claimed answer.
> 

Until you understand that D correctly simulated by pure function H
never halts we can never get to the next step.

> You agree that your funky "Infinite set of H/D pairs" is NOT what Linz 
> or Sipser were using in their proof, and that you H and D are not built 
> fully in conformance to the sample machines in the proofs.
> 

Once you understand that H is correct about D proving that embedded_H
is correct about ⟨Ĥ⟩ is easy. Until then it remains impossible

> 
> If you don't agree to these interpreations, a necessary precondition to 
> coming to an agreement on what H sees, is to reach the agreement on what 
> hte conditions imply and what those conditions actually are.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer