Path: ...!news.nobody.at!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) is correctly simulated by H
Date: Sun, 19 May 2024 15:34:51 -0500
Organization: A noiseless patient Spider
Lines: 200
Message-ID: <v2dnpc$3i9bd$1@dont-email.me>
References: <v18e32$1vbql$1@dont-email.me> <v1du2i$3dt7u$1@dont-email.me>
 <v1fetd$3s7jo$1@dont-email.me> <v1ft42$3vdau$2@dont-email.me>
 <-5Gdnf-nQvstC6b7nZ2dnZfqnPadnZ2d@brightview.co.uk>
 <v1gid8$4ilc$1@dont-email.me> <v1h9eu$9faf$1@dont-email.me>
 <v1iqli$nsva$1@dont-email.me> <v1ln3c$vfh$1@news.muc.de>
 <v1s6e6$397iq$2@dont-email.me> <v1slmi$3cjtp$1@dont-email.me>
 <v1t8tt$3gu9t$3@dont-email.me> <v1vc8j$3jmr$1@dont-email.me>
 <v1vsru$7eqc$1@dont-email.me> <v21r4i$otc2$2@dont-email.me>
 <v22k4b$umr4$1@dont-email.me> <v24oah$1h4u3$1@dont-email.me>
 <v256fc$1kais$1@dont-email.me> <v27d05$25ga0$1@dont-email.me>
 <v2838r$29rd7$1@dont-email.me> <v2a8th$2ps09$1@dont-email.me>
 <v2ahqc$2qvr9$1@dont-email.me> <v2cb5s$39fvg$1@dont-email.me>
 <v2crk0$3cifp$1@dont-email.me> <v2cvuo$3dfkm$1@dont-email.me>
 <v2d0qm$3ddo5$3@dont-email.me> <v2dc7a$1g2n9$5@i2pn2.org>
 <v2dffn$3gjtv$1@dont-email.me> <v2diom$1g2n8$3@i2pn2.org>
 <v2djtt$3hgb1$1@dont-email.me> <v2dl51$1g2n9$12@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 19 May 2024 22:34:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8b2dd23db76027a1e88bd64b7a96c771";
	logging-data="3745133"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19TcUKqACWIpOlUB1Sy2I79"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:xeCQlA/vExe28HpCVQRWQwio7yg=
In-Reply-To: <v2dl51$1g2n9$12@i2pn2.org>
Content-Language: en-US
Bytes: 9166

On 5/19/2024 2:49 PM, Richard Damon wrote:
> On 5/19/24 3:29 PM, olcott wrote:
>> On 5/19/2024 2:09 PM, Richard Damon wrote:
>>> On 5/19/24 2:13 PM, olcott wrote:
>>>> On 5/19/2024 12:17 PM, Richard Damon wrote:
>>>>> On 5/19/24 10:03 AM, olcott wrote:
>>>>>> On 5/19/2024 8:48 AM, Mikko wrote:
>>>>>>> On 2024-05-19 12:34:08 +0000, olcott said:
>>>>>>>
>>>>>>>> On 5/19/2024 2:53 AM, Mikko wrote:
>>>>>>>>> On 2024-05-18 15:34:36 +0000, James Kuyper said:
>>>>>>>>>
>>>>>>>>>> On 5/18/24 09:02, Mikko wrote:
>>>>>>>>>>> On 2024-05-17 17:14:01 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>> I recommend ignoring olcott - nothing good ever comes from paying
>>>>>>>>>> attention to him.
>>>>>>>>>>
>>>>>>>>>>>> On 5/17/2024 5:53 AM, Mikko wrote:
>>>>>>>>>>>>> On 2024-05-16 14:50:19 +0000, olcott said:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 5/16/2024 5:48 AM, Mikko wrote:
>>>>>>>>>>>>>>> On 2024-05-15 15:24:57 +0000, olcott said:
>>>>>>>>>> ...
>>>>>>>>>>>>>>>> typedef int (*ptr)();  // ptr is pointer to int function
>>>>>>>>>>>>>>>> 00 int H(ptr x, ptr x);
>>>>>>>>>>>>>>>> 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   return 0;
>>>>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can you find any compiler that is liberal enough to 
>>>>>>>>>>>>>>> accept that?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It has been fully operational code under Windows and
>>>>>>>>>>>>>> Linux for two years.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If your compiler does not reject that program it is not a 
>>>>>>>>>>>>> conforming
>>>>>>>>>>>>> C compiler. The semantics according to C standard is that a 
>>>>>>>>>>>>> diagnostic
>>>>>>>>>>>>> message must be given. The standard does not specify what 
>>>>>>>>>>>>> happens if
>>>>>>>>>>>>> you execute that program anyway.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It is not nit picky syntax that is the issue here.
>>>>>>>>>>>> The SEMANTICS OF THE C PROGRAMMING LANGUAGE SPECIFIES
>>>>>>>>>>>>
>>>>>>>>>>>> No D simulated correctly by any H of every H/D pair specified
>>>>>>>>>>>> by the above template ever reaches its own line 06 and halts.
>>>>>>>>>>>
>>>>>>>>>>> The standard allows that an program is executed but does not
>>>>>>>>>>> specify what happens when an invalid program is executed.
>>>>>>>>>>
>>>>>>>>>> You've cross-posted this to comp.lang.c after a long-running 
>>>>>>>>>> discussion
>>>>>>>>>> solely on comp.theory. Presumably you're doing that because 
>>>>>>>>>> you want
>>>>>>>>>> some discussion about what the standard says about this code. 
>>>>>>>>>> For the
>>>>>>>>>> sake of those of us who have not been following that 
>>>>>>>>>> discussion on
>>>>>>>>>> comp.theory, could you please identify what it is that you 
>>>>>>>>>> think renders
>>>>>>>>>> this code invalid? Offhand, I don't see anything wrong with 
>>>>>>>>>> it, but I'm
>>>>>>>>>> far more reliable when I say "I see an error" than when I say 
>>>>>>>>>> "I don't
>>>>>>>>>> see an error".
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Fully operational software that runs under Widows and Linux
>>>>>>>>>>>> proves that the above is true EMPIRICALLY.
>>>>>>>>>>>
>>>>>>>>>>> No, it does not. As the program is not strictly comforming
>>>>>>>>>>> and uses a non-standard extension some implementation may
>>>>>>>>>>> execute it differently or refuse to execute.
>>>>>>>>>>
>>>>>>>>>> Which non-standard extension does it use?
>>>>>>>>>
>>>>>>>>> The main question is whether both arguments of H on the line 00 
>>>>>>>>> can have
>>>>>>>>> the same name.
>>>>>>>>
>>>>>>>> That was a typo that I did not believe when told because so may 
>>>>>>>> people
>>>>>>>> continue to lie about the behavior of D correctly simulated by H.
>>>>>>>
>>>>>>> How does the D that is correctly simulated by H different from any
>>>>>>> D that is incorrectly simulated by H nor not simulated by H?
>>>>>>>
>>>>>>
>>>>>> typedef int (*ptr)();  // ptr is pointer to int function
>>>>>> 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 }
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> Which has been proven incorrect.
>>>>
>>>> *Quoted from page 4 of the paper linked below*
>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>> // Strachey(1965) CPL translated to C
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))HERE:
>>>>     goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> That P is correctly simulated by H is proven by the fact that
>>>> every assembly language instruction of P is correctly simulated
>>>> by H in the order specified by the x86 assembly language of P
>>>> even when H correctly simulates itself simulating P.
>>>>
>>>> All of the details of this (except the 354 page execution
>>>> trace of H) are shown on pages 4-5 of the following paper.
>>>
>>> Which of course, will have the details of what H did wrong.
>>>
>>>>
>>>> *Halting problem undecidability and infinitely nested simulation*
>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>
>>>>
>>>
>>> So, which instruction CORRECTLY SIMULATED allows H to CORRECTLY 
>>> DETERMINE that its input is non-halting?
>>>
>>
========== REMAINDER OF ARTICLE TRUNCATED ==========