Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: Every D(D) simulated by H presents non-halting behavior to H ###
Date: Wed, 22 May 2024 10:17:10 +0300
Organization: -
Lines: 135
Message-ID: <v2k65m$12nvc$1@dont-email.me>
References: <v18e32$1vbql$1@dont-email.me> <v1d2mi$9f72$11@i2pn2.org> <v1di1h$3b2m5$1@dont-email.me> <v1dtdv$3dqg4$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> <v2f15t$3t14c$1@dont-email.me> <v2i8gs$jvcs$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 22 May 2024 09:17:11 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f7e0bc7db22343d0ab5efd8d30cb7c95";
	logging-data="1138668"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18wMNef8wHViS6D+bzlDaD2"
User-Agent: Unison/2.2
Cancel-Lock: sha1:kuIGaQK3QZ3zGsXO+SKN5/HmokU=
Bytes: 7121

On 2024-05-21 13:44:59 +0000, olcott said:

> On 5/20/2024 3:21 AM, Mikko wrote:
>> On 2024-05-19 14:03:01 +0000, olcott said:
>> 
>>> 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?
>> 
>> Oops, I made a typo on the last line. Pro "nor" lege "or".
>> Fortunately most of the typos are harmless but this one
>> might be a problem.
>> 
>>> 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.
>> 
>> As far as I can see, that does not say anything that was not already
>> said (but there is a minor presentational imporvement) and in particular
>> does not answer my question.
>> 
> 
> The problem is that people continue to refuse to answer the updated
> question and the original question. Everyone spends enormous effort
> on not answering either question.

Then you must figure out how to proceed without an answer. You can try
another question but it is possible that they don't answer that, either.

One way to solve a hard problem is to first solve an isomorphic problem.
I don't know whether it helps to extract an answer but it has worked
in some other problems.

-- 
Mikko