Path: ...!weretis.net!feeder9.news.weretis.net!feeder8.news.weretis.net!news.mixmin.net!news2.arglkargh.de!news.karotte.org!news.space.net!news.muc.de!.POSTED.news.muc.de!not-for-mail
From: Alan Mackenzie <acm@muc.de>
Newsgroups: comp.theory,sci.logic
Subject: Re: Every D(D) simulated by H presents non-halting behavior to H ###
Followup-To: comp.theory
Date: Sat, 11 May 2024 09:48:24 -0000 (UTC)
Organization: muc.de e.V.
Message-ID: <v1net8$bb4$1@news.muc.de>
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> <v1lndc$1g5g6$1@dont-email.me> <v1lpj7$vfh$2@news.muc.de> <v1lrpm$1h1bd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sat, 11 May 2024 09:48:24 -0000 (UTC)
Injection-Info: news.muc.de; posting-host="news.muc.de:2001:608:1000::2";
	logging-data="11620"; mail-complaints-to="news-admin@muc.de"
User-Agent: tin/2.6.3-20231224 ("Banff") (FreeBSD/14.0-RELEASE-p5 (amd64))
Bytes: 7851
Lines: 198

[ Followup-To: set ]

In comp.theory olcott <polcott333@gmail.com> wrote:
> On 5/10/2024 1:38 PM, Alan Mackenzie wrote:

>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>> On 5/10/2024 12:55 PM, Alan Mackenzie wrote:

>>>> In comp.theory olcott <polcott333@gmail.com> wrote:

>>>> [ .... ]

>>>> I've tried out your much spammed code on GCC (see below).  It is cle=
ar
>>>> you have never built or run this code, which ironically can't reach =
Line
>>>> 06.  It can't even reach line 00.

>>>>> Richard tried to get away with D never simulated by H as an example
>>>>> of D simulated by H:

>>>>> Message-ID: <v0ummt$2qov3$2@i2pn2.org>
>>>>> On 5/1/2024 7:28 PM, Richard Damon wrote:

>>>>> *That people say they know I am wrong yet will not show the detaile=
d*
>>>>> *steps of how I am wrong indicates that they are probably liars*

>>>> You have said, or at least implied that your code fragment is runnab=
le.
>>>> I think you are the liar, here.

>>>>> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
>>>>> 01 int D(ptr x)
>>>>> 02 {
>>>>> 03   int Halt_Status =3D 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 }

>>>> I removed the line numbers from your code, added in a "pointer to in=
t
>>>> function" type (you should really learn how to do this yourself) and=
 ran
>>>> the result on GCC.

>>>> This is the file I submitted:

>>>> typedef int (* ptr) (void);
>>>> int H(ptr x, ptr x)  // ptr is pointer to int function
>>>> int D(ptr x)
>>>> {
>>>>       int Halt_Status =3D H(x, x);
>>>>       if (Halt_Status)
>>>>           HERE: goto HERE;
>>>>       return Halt_Status;
>>>> }

>>>> int main()
>>>> {
>>>>       H(D,D);
>>>> }

>>>> .  These are the diagnostics generated by GCC:

>>>> olcott.c:2:18: error: redefinition of parameter =E2=80=98x=E2=80=99
>>>>       2 | int H(ptr x, ptr x)  // ptr is pointer to int function
>>>>         |              ~~~~^
>>>> olcott.c:2:11: note: previous definition of =E2=80=98x=E2=80=99 with=
 type =E2=80=98ptr=E2=80=99 {aka =E2=80=98int
>>>> (*)(void)=E2=80=99}
>>>>       2 | int H(ptr x, ptr x)  // ptr is pointer to int function
>>>>         |       ~~~~^
>>>> olcott.c: In function =E2=80=98H=E2=80=99:
>>>> olcott.c:4:1: error: expected =E2=80=98=3D=E2=80=99, =E2=80=98,=E2=80=
=99, =E2=80=98;=E2=80=99, =E2=80=98asm=E2=80=99 or =E2=80=98__attribute__=
=E2=80=99
>>>> before =E2=80=98{=E2=80=99 token
>>>>       4 | {
>>>>         | ^
>>>> olcott.c:12:1: error: expected =E2=80=98=3D=E2=80=99, =E2=80=98,=E2=80=
=99, =E2=80=98;=E2=80=99, =E2=80=98asm=E2=80=99 or =E2=80=98__attribute__=
=E2=80=99
>>>> before =E2=80=98{=E2=80=99 token
>>>>      12 | {
>>>>         | ^
>>>> olcott.c:15: error: expected =E2=80=98{=E2=80=99 at end of input

>>>>> Any H/D pair matching the above template where D(D) is simulated
>>>>> by the same H(D,D) that it calls cannot possibly reach past its own
>>>>> line 03. Simple software engineering verified fact.

>>>> The code for D is so full of errors that it cannot demonstrate anyth=
ing,
>>>> beyond a lack of proficiency in C in its author.


>>> *I have fully operational code, yet this is*
>>> *not the code that the words below refer to*

>> Why, then, have you been spamming the group with faulty code for so lo=
ng?
>> Why did you not first check it and correct it before posting it?

>> When I brought up the issue before, you "answered", in

>> From: olcott <polcott333@gmail.com>
>> Newsgroups: comp.theory,sci.logic
>> Subject: Re: D simulated by H never halts no matter what H does V3
>> Date: Sat, 4 May 2024 10:47:00 -0500

>> , that

>>> There is no actual error in these lines of code.
>>> int main()
>>> {
>>>    H(D,D);
>>>    return 0;
>>> }

>> .  Why did you answer so evasively?  Why did you not admit then that t=
he
>> code was faulty, and thank me for pointing it out?

>>> I had to change the wording for people that intentionally
>>> try as hard as possible to make sure to interpret my words
>>> incorrectly.

>> There are no such people on this newsgroup.  Most people here try to
>> answer your posts directly and honestly.  You are the poster who attem=
pts
>> to mislead, obfuscate, and evade.

>>> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
>>> 01 int D(ptr x)
>>> 02 {
>>> 03   int Halt_Status =3D 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 }

>>> Any H/D pair matching the above template where D(D) is simulated
>>> by the same H(D,D) that it calls cannot possibly reach past its own
>>> line 03. Simple software engineering verified fact.

>> Why are you doing this again?  Simple software engineering shows that =
the
>> above code is so broken as to be unusable.  Why don't you correct it
>> first before posting it yet again?

> *above template ---not code, code template*
> *I said it was a code template*
> *You knew it was a code template and pretend to not know*

Now I understand why you write vaguely.  It's so that you can tell
untruths without lying, as you see it.  You're like a politician in that
respect; you never commit yourself to anything, always leaving a get-out
for when the truth emerges.

You strongly implied, perhaps without actually saying, that that spammed
fragment was actual code - you denigrated critics of it by saying they
didn't have enough expertise in the C language.

You referred to the code's execution trace.  Your actual words were:

> Perhaps you do understand what an execution trace is and
> disparage my work without even looking at it?

This was presumably a "virtual" execution trace, i.e. totally
========== REMAINDER OF ARTICLE TRUNCATED ==========