Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: Can you see that D correctly simulated by H remains stuck in
 recursive simulation?
Date: Fri, 24 May 2024 16:28:01 +0200
Organization: A noiseless patient Spider
Lines: 82
Message-ID: <v2q85h$2c54h$3@dont-email.me>
References: <v2ns85$1rd65$1@dont-email.me> <v2q04f$2amug$1@dont-email.me>
 <v2q3h4$2b3fj$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 24 May 2024 16:28:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6f460dec93d76c9c93a2bbcc2a51db60";
	logging-data="2495633"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18JaTz7r0E64bL1naoC8Hkn"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:1rBEAzVBJYRmpr2RXFN36BbbPss=
In-Reply-To: <v2q3h4$2b3fj$3@dont-email.me>
Content-Language: en-GB
Bytes: 4134

Op 24.mei.2024 om 15:08 schreef olcott:
> On 5/24/2024 7:10 AM, Richard Harnden wrote:
>> On 23/05/2024 17:52, olcott wrote:
>>> 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 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.
>>>
>>> In the above case 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.
>>
>>
>> So, you have: main -> H -> D -> H -> D -> ... -> H -> D until you run 
>> out of stack?
>>
>> No return statement is ever reached.
>> Line 3 never completes.
>> Halt_Status at line 3 never gets a value.
>>
>> </shrug>
>>
>>
> Thanks.
> 
> Proving that D correctly simulated by H never reaches its final
> state at line 06 and halts. Thus proving that the halting problem's
> counter-example input D would be correctly determined to be non-halting
> by its simulating termination analyzer H.
> 

Since the claim is that the simulator never reaches line 04, the 
conclusion is that line 04, 05 and 06 do not play a role in the proof. 
Which means that we can delete them and still use the 'proof'. Then the 
'proof' is that any function that calls H would be non-halting, because 
H does not halt. That D does the opposite of what H returns is not used 
in the 'proof', because it is not part of the simulation.
So, it would be equally correct to say that D1 does not halt, because H 
will never return from the recursive simulation:

        int H(ptr p, ptr i);
        int D1(ptr p)
        {
          return H(p, p);
        }
        int main()
        {
          H(D1,D1);
          return 0;
        }

Of course that does not prove it. It only proves that simulation cannot 
be used in this way to determine the halting status.