Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #119150 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-05-18 16:40 -0500 |
| Last post | 2024-05-20 10:13 -0500 |
| Articles | 20 on this page of 136 — 13 participants |
Back to article view | Back to comp.lang.c++
Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-18 16:40 -0500
Re: Can someone please verify the execution trace of this? Richard Damon <richard@damon-family.org> - 2024-05-18 18:33 -0400
Re: Can someone please verify the execution trace of this? Sam <sam@email-scan.com> - 2024-05-18 21:12 -0400
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-18 22:16 -0500
Re: Can someone please verify the execution trace of this? jak <nospam@please.ty> - 2024-05-19 06:24 +0200
Re: Can someone please verify the execution trace of this? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-19 20:08 +0200
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-19 14:00 -0500
Re: Can someone please verify the execution trace of this? Richard Damon <richard@damon-family.org> - 2024-05-19 15:24 -0400
Re: Can someone please verify the execution trace of this? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-20 03:52 +0200
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-19 21:43 -0500
Re: Can someone please verify the execution trace of this? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-20 07:09 +0200
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 00:38 -0500
Re: Can someone please verify the execution trace of this? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-20 08:41 +0200
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 09:47 -0500
Re: Can someone please verify the execution trace of this? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-20 17:16 +0200
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 11:01 -0500
Re: Can someone please verify the execution trace of this? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-20 19:15 +0200
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 12:20 -0500
Re: Can someone please verify the execution trace of this? Richard Harnden <richard.nospam@gmail.invalid> - 2024-05-20 19:26 +0100
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 14:09 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 11:35 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 14:15 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 12:23 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 14:28 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 12:30 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 14:34 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 12:35 -0700
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 12:36 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 14:38 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 12:42 -0700
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 12:38 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 14:40 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 12:44 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 14:48 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 12:50 -0700
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 12:52 -0700
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 12:32 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 14:37 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 12:41 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 14:45 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 12:47 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 14:53 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 13:04 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 15:10 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 13:19 -0700
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 13:21 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 15:30 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 13:31 -0700
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 13:32 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 15:36 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 13:38 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 15:52 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 14:05 -0700
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 14:09 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 16:27 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 13:48 -0700
Re: Can someone please verify the execution trace of this? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-20 10:10 +0200
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 09:51 -0500
Re: Can someone please verify the execution trace of this? Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-20 18:05 +0300
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 10:11 -0500
Re: Can someone please verify the execution trace of this? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-20 17:17 +0200
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 11:07 -0500
Re: Can someone please verify the execution trace of this? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-21 00:14 +0200
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 17:23 -0500
Re: Can someone please verify the execution trace of this? wij <wyniijj5@gmail.com> - 2024-05-20 20:37 +0800
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 10:02 -0500
Re: Can someone please verify the execution trace of this? wij <wyniijj5@gmail.com> - 2024-05-21 00:21 +0800
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 12:23 -0500
Re: Can someone please verify the execution trace of this? wij <wyniijj5@gmail.com> - 2024-05-21 02:23 +0800
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 14:07 -0500
Re: Can someone please verify the execution trace of this? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-20 19:23 -0700
Re: Can someone please verify the execution trace of this? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-20 19:31 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 22:58 -0500
Re: Can someone please verify the execution trace of this? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-21 09:39 +0200
Re: Can someone please verify the execution trace of this? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-05-21 09:55 +0200
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-21 08:31 -0500
Re: Can someone please verify the execution trace of this? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-21 15:56 +0200
Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-21 09:09 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-21 20:01 +0200
Re: Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-21 13:09 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-21 20:13 +0200
Re: Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-21 13:24 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-21 20:39 +0200
Re: Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-21 13:48 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-22 06:40 +0200
Re: Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-21 23:46 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-22 18:29 +0200
Re: Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-22 08:52 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-22 12:01 +0200
Re: Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-21 23:37 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-22 06:29 +0200
D correctly simulated by H remains stuck in recursive simulation olcott <polcott333@gmail.com> - 2024-05-22 10:44 -0500
Re: D correctly simulated by H remains stuck in recursive simulation "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-22 18:27 +0200
Re: D correctly simulated by H remains stuck in recursive simulation wij <wyniijj5@gmail.com> - 2024-05-23 00:11 +0800
Re: D correctly simulated by H remains stuck in recursive simulation [good attempt] olcott <polcott333@gmail.com> - 2024-05-22 15:04 -0500
Re: D correctly simulated by H remains stuck in recursive simulation [good attempt] olcott <polcott333@gmail.com> - 2024-05-22 16:26 -0500
Re: D correctly simulated by H remains stuck in recursive simulation [good attempt] wij <wyniijj5@gmail.com> - 2024-05-23 05:35 +0800
Re: D correctly simulated by H remains stuck in recursive simulation olcott <polcott333@gmail.com> - 2024-05-22 16:56 -0500
Re: D correctly simulated by H remains stuck in recursive simulation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-22 15:36 -0700
Re: D correctly simulated by H remains stuck in recursive simulation olcott <polcott333@gmail.com> - 2024-05-22 17:52 -0500
Re: D correctly simulated by H remains stuck in recursive simulation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-22 18:33 -0700
Re: Can someone please verify the execution trace of this? Sam <sam@email-scan.com> - 2024-05-20 18:59 -0400
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 18:07 -0500
Re: Can someone please verify the execution trace of this? Sam <sam@email-scan.com> - 2024-05-20 19:21 -0400
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 18:27 -0500
Re: Can someone please verify the execution trace of this? Sam <sam@email-scan.com> - 2024-05-21 07:48 -0400
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-21 08:37 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-21 12:03 -0700
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-21 14:21 -0500
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-21 14:39 -0700
Re: Can someone please verify the execution trace of this? Sam <sam@email-scan.com> - 2024-05-21 17:55 -0400
Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-21 17:09 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-21 15:18 -0700
Re: Can D correctly simulated by H reach its own line 06 and halt? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-21 15:20 -0700
Re: Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-21 17:29 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-21 15:34 -0700
Re: Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-21 18:07 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-21 16:54 -0700
Re: Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-21 19:05 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? Sam <sam@email-scan.com> - 2024-05-21 21:31 -0400
Re: Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-21 20:43 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? Sam <sam@email-scan.com> - 2024-05-21 22:10 -0400
Re: Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-21 21:17 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? Sam <sam@email-scan.com> - 2024-05-21 22:20 -0400
Re: Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-21 21:22 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-21 23:03 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-22 08:53 -0500
Re: Can D correctly simulated by H reach its own line 06 and halt? Sam <sam@email-scan.com> - 2024-05-22 13:10 -0400
Re: Can D correctly simulated by H reach its own line 06 and halt? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-22 13:50 -0700
Re: Can D correctly simulated by H reach its own line 06 and halt? Sam <sam@email-scan.com> - 2024-05-22 07:01 -0400
Re: Can D correctly simulated by H reach its own line 06 and halt? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-22 13:50 +0200
Re: Can someone please verify the execution trace of this? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-20 21:00 -0700
Can D simulated by any H possibly reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-20 23:22 -0500
Re: Can someone please verify the execution trace of this? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-05-20 15:14 +0200
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 10:10 -0500
Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-20 10:13 -0500
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-05-20 17:17 +0200 |
| Message-ID | <v2fpj2$1vq6$2@raubtier-asyl.eternal-september.org> |
| In reply to | #119169 |
Am 20.05.2024 um 16:51 schrieb olcott:
> Anyone having sufficient knowledge of the semantics
> knows the answer. Likewise for these C functions:
>
> void Infinite_Recursion(u32 N)
> {
> Infinite_Recursion(N);
> }
>
> int factorial(int n)
> {
> if (n >= 1)
> return n*factorial(n-1);
> else
> return 1;
> }
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
>
I can't believe you're a professional developer when you repeatedly
run into the wall with simple questions like this for years.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-20 11:07 -0500 |
| Message-ID | <v2fsfd$2i1u$2@dont-email.me> |
| In reply to | #119176 |
On 5/20/2024 10:17 AM, Bonita Montero wrote:
> Am 20.05.2024 um 16:51 schrieb olcott:
>
>> Anyone having sufficient knowledge of the semantics
>> knows the answer. Likewise for these C functions:
>>
>> void Infinite_Recursion(u32 N)
>> {
>> Infinite_Recursion(N);
>> }
>>
>> int factorial(int n)
>> {
>> if (n >= 1)
>> return n*factorial(n-1);
>> else
>> return 1;
>> }
>>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>>
>>
>
> I can't believe you're a professional developer when you repeatedly
> run into the wall with simple questions like this for years.
I have known the answer from an actual execution trace for years.
Anyone with sufficient knowledge of the semantics of the C language
knows the answer. *I just need several liars to be put in their place*
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.
*My 2021-09-26 09:39 AM paper*
*Halting problem undecidability and infinitely nested simulation*
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-05-21 00:14 +0200 |
| Message-ID | <v2gi0o$6pc5$1@dont-email.me> |
| In reply to | #119178 |
Op 20.mei.2024 om 18:07 schreef olcott:
> On 5/20/2024 10:17 AM, Bonita Montero wrote:
>> Am 20.05.2024 um 16:51 schrieb olcott:
>>
>>> Anyone having sufficient knowledge of the semantics
>>> knows the answer. Likewise for these C functions:
>>>
>>> void Infinite_Recursion(u32 N)
>>> {
>>> Infinite_Recursion(N);
>>> }
>>>
>>> int factorial(int n)
>>> {
>>> if (n >= 1)
>>> return n*factorial(n-1);
>>> else
>>> return 1;
>>> }
>>>
>>> void Infinite_Loop()
>>> {
>>> HERE: goto HERE;
>>> }
>>>
>>>
>>
>> I can't believe you're a professional developer when you repeatedly
>> run into the wall with simple questions like this for years.
>
> I have known the answer from an actual execution trace for years.
The actual execution trace of the infinite number of H/D pairs?
> Anyone with sufficient knowledge of the semantics of the C language
> knows the answer. *I just need several liars to be put in their place*
>
Showing a proof for the claim would help more than finding somebody to
confirm the claim without evidence.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-20 17:23 -0500 |
| Message-ID | <v2gigb$733u$1@dont-email.me> |
| In reply to | #119223 |
On 5/20/2024 5:14 PM, Fred. Zwarts wrote:
> Op 20.mei.2024 om 18:07 schreef olcott:
>> On 5/20/2024 10:17 AM, Bonita Montero wrote:
>>> Am 20.05.2024 um 16:51 schrieb olcott:
>>>
>>>> Anyone having sufficient knowledge of the semantics
>>>> knows the answer. Likewise for these C functions:
>>>>
>>>> void Infinite_Recursion(u32 N)
>>>> {
>>>> Infinite_Recursion(N);
>>>> }
>>>>
>>>> int factorial(int n)
>>>> {
>>>> if (n >= 1)
>>>> return n*factorial(n-1);
>>>> else
>>>> return 1;
>>>> }
>>>>
>>>> void Infinite_Loop()
>>>> {
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>>
>>>
>>> I can't believe you're a professional developer when you repeatedly
>>> run into the wall with simple questions like this for years.
>>
>> I have known the answer from an actual execution trace for years.
>
> The actual execution trace of the infinite number of H/D pairs?
>
>> Anyone with sufficient knowledge of the semantics of the C language
>> knows the answer. *I just need several liars to be put in their place*
>>
>
>
> Showing a proof for the claim would help more than finding somebody to
> confirm the claim without evidence.
>
The same way that my claim can be understood to be self-evidently
true that halt status of the following functions is self-evidently
true.
*Try and explain to the experts in this forum how no one can*
*possibly know that Infinite_Recursion() will not terminate normally*
void Infinite_Recursion()
{
Infinite_Recursion();
}
int factorial(int n) // on input 5
{
if (n >= 1)
return n*factorial(n-1);
else
return 1;
}
void Infinite_Loop()
{
HERE: goto HERE;
}
void This_Halts()
{
return;
}
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-05-20 20:37 +0800 |
| Message-ID | <eaa0ef93ca03f744edc4fbcf6e79fc730805cce9.camel@gmail.com> |
| In reply to | #119160 |
On Sun, 2024-05-19 at 21:43 -0500, olcott wrote:
> On 5/19/2024 8:52 PM, Bonita Montero wrote:
> > Am 19.05.2024 um 21:00 schrieb olcott:
> > > On 5/19/2024 1:08 PM, Bonita Montero wrote:
> > > > Am 18.05.2024 um 23:40 schrieb olcott:
> > > > > People are saying that they have no idea what this code does
> > > > > because they do not believe it conforms to c11 or c17.
> > > > >
> > > > > typedef int (*ptr)(); // ptr is pointer to int function
> > > > > 00 int H(ptr x, ptr y);
> > > > > 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 }
> > > > >
> > > > > 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);
> > > > >
> > > > > *keeps repeating* (unless aborted)
> > > > > Line 01:
> > > > > Line 02:
> > > > > Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
> > > > >
> > > > > *Simulation invariant*
> > > > > D correctly simulated by H cannot possibly reach past its own line 03.
> > > > >
> > > > > The key thing to note is that no D correctly simulated by any H of
> > > > > every
> > > > > H/D pair specified by the above template ever reaches its own line 06
> > > > > and halts.
> > > > >
> > > >
> > > > Other people think 30s about this, you think years about that.
> > > >
> > >
> > > It is the basis for my two decades long primary research into
> > > termination analysis. People on another forum have written
> > > hundreds of posts claiming that D correctly simulated by H
> > > reaches its own line 06 and halts.
> > >
> > > *I have only gotten truthful answers on this forum*
> > >
> >
> > That's not research, that's nonsense.
> >
>
> This is not the forum to show that it is not nonsense this is
> a simple C question that I should not even have to ask except
> for a few people in another forum that consistently lie about
> the answer.
>
> I have been a professional C++ developer since Y2K. So I already
> know the answer, I just need some competent people in this forum
> to attest to this answer. I met Bjarne Stroustrup back when he
> was going around the country promoting his new language.
>
typedef int (*ptr)(); // ptr is pointer to int function
int H(ptr x, ptr y);
int D(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
H(D,D);
return 0;
}
The code above does not compile:
1. D does not fit the protocol H accepts --> After there years, you finally
learn to use typedef but still not seem to understand it.
2. H is not defined --> cannot compile to executable
You are trapped in an infinite recursive call.
You finally know it is an infinite recursive call. But the Halting Problem
asks for a program to answer the halting question, NOT YOU to answer the
question. According to GUR, even the H were your god, he neither can provide
the correct answer.
Besides, you just posted another proof that you lied again, fake false reports
of what you did and saw, hiding the actual result and tell what you like to
believe. Strictly, this is what all human may do, you are just too stupid.
The relevant part of your brain is burnt.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-20 10:02 -0500 |
| Message-ID | <v2fom7$1pfh$1@dont-email.me> |
| In reply to | #119165 |
On 5/20/2024 7:37 AM, wij wrote:
> On Sun, 2024-05-19 at 21:43 -0500, olcott wrote:
>> On 5/19/2024 8:52 PM, Bonita Montero wrote:
>>> Am 19.05.2024 um 21:00 schrieb olcott:
>>>> On 5/19/2024 1:08 PM, Bonita Montero wrote:
>>>>> Am 18.05.2024 um 23:40 schrieb olcott:
>>>>>> People are saying that they have no idea what this code does
>>>>>> because they do not believe it conforms to c11 or c17.
>>>>>>
>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>> 00 int H(ptr x, ptr y);
>>>>>> 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 }
>>>>>>
>>>>>> 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);
>>>>>>
>>>>>> *keeps repeating* (unless aborted)
>>>>>> Line 01:
>>>>>> Line 02:
>>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>>
>>>>>> *Simulation invariant*
>>>>>> D correctly simulated by H cannot possibly reach past its own line 03.
>>>>>>
>>>>>> The key thing to note is that no D correctly simulated by any H of
>>>>>> every
>>>>>> H/D pair specified by the above template ever reaches its own line 06
>>>>>> and halts.
>>>>>>
>>>>>
>>>>> Other people think 30s about this, you think years about that.
>>>>>
>>>>
>>>> It is the basis for my two decades long primary research into
>>>> termination analysis. People on another forum have written
>>>> hundreds of posts claiming that D correctly simulated by H
>>>> reaches its own line 06 and halts.
>>>>
>>>> *I have only gotten truthful answers on this forum*
>>>>
>>>
>>> That's not research, that's nonsense.
>>>
>>
>> This is not the forum to show that it is not nonsense this is
>> a simple C question that I should not even have to ask except
>> for a few people in another forum that consistently lie about
>> the answer.
>>
>> I have been a professional C++ developer since Y2K. So I already
>> know the answer, I just need some competent people in this forum
>> to attest to this answer. I met Bjarne Stroustrup back when he
>> was going around the country promoting his new language.
>>
>
> typedef int (*ptr)(); // ptr is pointer to int function
> int H(ptr x, ptr y);
> int D(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> int main()
> {
> H(D,D);
> return 0;
> }
>
> The code above does not compile:
*It does compile*
*It does compile*
*It does compile*
*It does compile*
typedef int (*ptr)();
int H(ptr P, ptr I);
int D(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
H(D,D);
return 0;
}
cl /GS- /std:c11 /c /arch:IA32 Test_Compile.c
cl /GS- /std:c17 /c /arch:IA32 Test_Compile.c
if ERRORLEVEL 1 pause
D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>echo
off
D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>REM
2022
D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>call
"C:\Program Files\Microsoft Visual
Studio\2022\Community\Common7\Tools\VsDevCmd.BAT"
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.6.4
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
Test_Compile.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
Test_Compile.c
Press any key to continue . . .
> 1. D does not fit the protocol H accepts --> After there years, you finally
> learn to use typedef but still not seem to understand it.
That is false too. H has been fully implemented with
that protocol for a year.
> 2. H is not defined --> cannot compile to executable
>
I am asking about the behavior of
every H/D pair of the above template D correctly simulated by pure
function (thus computable function) H cannot possibly reach its own
final state at line 06 and halt.
> You are trapped in an infinite recursive call.
> You finally know it is an infinite recursive call. But the Halting Problem
> asks for a program to answer the halting question, NOT YOU to answer the
> question. According to GUR, even the H were your god, he neither can provide
> the correct answer.
>
This is a fully operational version from three years ago that
proves it does get the right answer on pages 4-5 of the paper.
*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.
*Halting problem undecidability and infinitely nested simulation*
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-05-21 00:21 +0800 |
| Message-ID | <32565d46f03edef2380267eeb552fcce102e6753.camel@gmail.com> |
| In reply to | #119170 |
On Mon, 2024-05-20 at 10:02 -0500, olcott wrote:
> On 5/20/2024 7:37 AM, wij wrote:
> > On Sun, 2024-05-19 at 21:43 -0500, olcott wrote:
> > > On 5/19/2024 8:52 PM, Bonita Montero wrote:
> > > > Am 19.05.2024 um 21:00 schrieb olcott:
> > > > > On 5/19/2024 1:08 PM, Bonita Montero wrote:
> > > > > > Am 18.05.2024 um 23:40 schrieb olcott:
> > > > > > > People are saying that they have no idea what this code does
> > > > > > > because they do not believe it conforms to c11 or c17.
> > > > > > >
> > > > > > > typedef int (*ptr)(); // ptr is pointer to int function
> > > > > > > 00 int H(ptr x, ptr y);
> > > > > > > 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 }
> > > > > > >
> > > > > > > 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);
> > > > > > >
> > > > > > > *keeps repeating* (unless aborted)
> > > > > > > Line 01:
> > > > > > > Line 02:
> > > > > > > Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
> > > > > > >
> > > > > > > *Simulation invariant*
> > > > > > > D correctly simulated by H cannot possibly reach past its own line 03.
> > > > > > >
> > > > > > > The key thing to note is that no D correctly simulated by any H of
> > > > > > > every
> > > > > > > H/D pair specified by the above template ever reaches its own line 06
> > > > > > > and halts.
> > > > > > >
> > > > > >
> > > > > > Other people think 30s about this, you think years about that.
> > > > > >
> > > > >
> > > > > It is the basis for my two decades long primary research into
> > > > > termination analysis. People on another forum have written
> > > > > hundreds of posts claiming that D correctly simulated by H
> > > > > reaches its own line 06 and halts.
> > > > >
> > > > > *I have only gotten truthful answers on this forum*
> > > > >
> > > >
> > > > That's not research, that's nonsense.
> > > >
> > >
> > > This is not the forum to show that it is not nonsense this is
> > > a simple C question that I should not even have to ask except
> > > for a few people in another forum that consistently lie about
> > > the answer.
> > >
> > > I have been a professional C++ developer since Y2K. So I already
> > > know the answer, I just need some competent people in this forum
> > > to attest to this answer. I met Bjarne Stroustrup back when he
> > > was going around the country promoting his new language.
> > >
> >
> > typedef int (*ptr)(); // ptr is pointer to int function
> > int H(ptr x, ptr y);
> > int D(ptr x)
> > {
> > int Halt_Status = H(x, x);
> > if (Halt_Status)
> > HERE: goto HERE;
> > return Halt_Status;
> > }
> >
> > int main()
> > {
> > H(D,D);
> > return 0;
> > }
> >
> > The code above does not compile:
>
> *It does compile*
> *It does compile*
> *It does compile*
> *It does compile*
>
> typedef int (*ptr)();
> int H(ptr P, ptr I);
>
> int D(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> int main()
> {
> H(D,D);
> return 0;
> }
>
> cl /GS- /std:c11 /c /arch:IA32 Test_Compile.c
> cl /GS- /std:c17 /c /arch:IA32 Test_Compile.c
> if ERRORLEVEL 1 pause
>
>
> D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>echo
> off
>
> D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>REM
> 2022
>
> D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>call
> "C:\Program Files\Microsoft Visual
> Studio\2022\Community\Common7\Tools\VsDevCmd.BAT"
> **********************************************************************
> ** Visual Studio 2022 Developer Command Prompt v17.6.4
> ** Copyright (c) 2022 Microsoft Corporation
> **********************************************************************
> Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x86
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> Test_Compile.c
> Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x86
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> Test_Compile.c
> Press any key to continue . . .
OK, My fault, gcc can compile (g++ can't. No idea why D's protocol doesn't match
type ptr and get compiled in C).
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-20 12:23 -0500 |
| Message-ID | <v2g0vb$3j0c$2@dont-email.me> |
| In reply to | #119179 |
On 5/20/2024 11:21 AM, wij wrote:
> On Mon, 2024-05-20 at 10:02 -0500, olcott wrote:
>> On 5/20/2024 7:37 AM, wij wrote:
>>> On Sun, 2024-05-19 at 21:43 -0500, olcott wrote:
>>>> On 5/19/2024 8:52 PM, Bonita Montero wrote:
>>>>> Am 19.05.2024 um 21:00 schrieb olcott:
>>>>>> On 5/19/2024 1:08 PM, Bonita Montero wrote:
>>>>>>> Am 18.05.2024 um 23:40 schrieb olcott:
>>>>>>>> People are saying that they have no idea what this code does
>>>>>>>> because they do not believe it conforms to c11 or c17.
>>>>>>>>
>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>> 00 int H(ptr x, ptr y);
>>>>>>>> 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 }
>>>>>>>>
>>>>>>>> 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);
>>>>>>>>
>>>>>>>> *keeps repeating* (unless aborted)
>>>>>>>> Line 01:
>>>>>>>> Line 02:
>>>>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>>>>
>>>>>>>> *Simulation invariant*
>>>>>>>> D correctly simulated by H cannot possibly reach past its own line 03.
>>>>>>>>
>>>>>>>> The key thing to note is that no D correctly simulated by any H of
>>>>>>>> every
>>>>>>>> H/D pair specified by the above template ever reaches its own line 06
>>>>>>>> and halts.
>>>>>>>>
>>>>>>>
>>>>>>> Other people think 30s about this, you think years about that.
>>>>>>>
>>>>>>
>>>>>> It is the basis for my two decades long primary research into
>>>>>> termination analysis. People on another forum have written
>>>>>> hundreds of posts claiming that D correctly simulated by H
>>>>>> reaches its own line 06 and halts.
>>>>>>
>>>>>> *I have only gotten truthful answers on this forum*
>>>>>>
>>>>>
>>>>> That's not research, that's nonsense.
>>>>>
>>>>
>>>> This is not the forum to show that it is not nonsense this is
>>>> a simple C question that I should not even have to ask except
>>>> for a few people in another forum that consistently lie about
>>>> the answer.
>>>>
>>>> I have been a professional C++ developer since Y2K. So I already
>>>> know the answer, I just need some competent people in this forum
>>>> to attest to this answer. I met Bjarne Stroustrup back when he
>>>> was going around the country promoting his new language.
>>>>
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function
>>> int H(ptr x, ptr y);
>>> int D(ptr x)
>>> {
>>> int Halt_Status = H(x, x);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> int main()
>>> {
>>> H(D,D);
>>> return 0;
>>> }
>>>
>>> The code above does not compile:
>>
>> *It does compile*
>> *It does compile*
>> *It does compile*
>> *It does compile*
>>
>> typedef int (*ptr)();
>> int H(ptr P, ptr I);
>>
>> int D(ptr x)
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> int main()
>> {
>> H(D,D);
>> return 0;
>> }
>>
>> cl /GS- /std:c11 /c /arch:IA32 Test_Compile.c
>> cl /GS- /std:c17 /c /arch:IA32 Test_Compile.c
>> if ERRORLEVEL 1 pause
>>
>>
>> D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>echo
>> off
>>
>> D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>REM
>> 2022
>>
>> D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>call
>> "C:\Program Files\Microsoft Visual
>> Studio\2022\Community\Common7\Tools\VsDevCmd.BAT"
>> **********************************************************************
>> ** Visual Studio 2022 Developer Command Prompt v17.6.4
>> ** Copyright (c) 2022 Microsoft Corporation
>> **********************************************************************
>> Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x86
>> Copyright (C) Microsoft Corporation. All rights reserved.
>>
>> Test_Compile.c
>> Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x86
>> Copyright (C) Microsoft Corporation. All rights reserved.
>>
>> Test_Compile.c
>> Press any key to continue . . .
>
> OK, My fault, gcc can compile (g++ can't. No idea why D's protocol doesn't match
> type ptr and get compiled in C).
>
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.
*I just need to people that have persistently lied*
*about this for two years to be put in their place*
*Can you see that*
For every H/D pair of the above template D correctly simulated by pure
function (thus computable function) H cannot possibly reach its own
final state at line 06 and halt.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-05-21 02:23 +0800 |
| Message-ID | <239b5d6057b5b9d7b63d62235fac97facb039718.camel@gmail.com> |
| In reply to | #119182 |
On Mon, 2024-05-20 at 12:23 -0500, olcott wrote:
> On 5/20/2024 11:21 AM, wij wrote:
> > On Mon, 2024-05-20 at 10:02 -0500, olcott wrote:
> > > On 5/20/2024 7:37 AM, wij wrote:
> > > > On Sun, 2024-05-19 at 21:43 -0500, olcott wrote:
> > > > > On 5/19/2024 8:52 PM, Bonita Montero wrote:
> > > > > > Am 19.05.2024 um 21:00 schrieb olcott:
> > > > > > > On 5/19/2024 1:08 PM, Bonita Montero wrote:
> > > > > > > > Am 18.05.2024 um 23:40 schrieb olcott:
> > > > > > > > > People are saying that they have no idea what this code does
> > > > > > > > > because they do not believe it conforms to c11 or c17.
> > > > > > > > >
> > > > > > > > > typedef int (*ptr)(); // ptr is pointer to int function
> > > > > > > > > 00 int H(ptr x, ptr y);
> > > > > > > > > 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 }
> > > > > > > > >
> > > > > > > > > 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);
> > > > > > > > >
> > > > > > > > > *keeps repeating* (unless aborted)
> > > > > > > > > Line 01:
> > > > > > > > > Line 02:
> > > > > > > > > Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
> > > > > > > > >
> > > > > > > > > *Simulation invariant*
> > > > > > > > > D correctly simulated by H cannot possibly reach past its own line 03.
> > > > > > > > >
> > > > > > > > > The key thing to note is that no D correctly simulated by any H of
> > > > > > > > > every
> > > > > > > > > H/D pair specified by the above template ever reaches its own line 06
> > > > > > > > > and halts.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Other people think 30s about this, you think years about that.
> > > > > > > >
> > > > > > >
> > > > > > > It is the basis for my two decades long primary research into
> > > > > > > termination analysis. People on another forum have written
> > > > > > > hundreds of posts claiming that D correctly simulated by H
> > > > > > > reaches its own line 06 and halts.
> > > > > > >
> > > > > > > *I have only gotten truthful answers on this forum*
> > > > > > >
> > > > > >
> > > > > > That's not research, that's nonsense.
> > > > > >
> > > > >
> > > > > This is not the forum to show that it is not nonsense this is
> > > > > a simple C question that I should not even have to ask except
> > > > > for a few people in another forum that consistently lie about
> > > > > the answer.
> > > > >
> > > > > I have been a professional C++ developer since Y2K. So I already
> > > > > know the answer, I just need some competent people in this forum
> > > > > to attest to this answer. I met Bjarne Stroustrup back when he
> > > > > was going around the country promoting his new language.
> > > > >
> > > >
> > > > typedef int (*ptr)(); // ptr is pointer to int function
> > > > int H(ptr x, ptr y);
> > > > int D(ptr x)
> > > > {
> > > > int Halt_Status = H(x, x);
> > > > if (Halt_Status)
> > > > HERE: goto HERE;
> > > > return Halt_Status;
> > > > }
> > > >
> > > > int main()
> > > > {
> > > > H(D,D);
> > > > return 0;
> > > > }
> > > >
> > > > The code above does not compile:
> > >
> > > *It does compile*
> > > *It does compile*
> > > *It does compile*
> > > *It does compile*
> > >
> > > typedef int (*ptr)();
> > > int H(ptr P, ptr I);
> > >
> > > int D(ptr x)
> > > {
> > > int Halt_Status = H(x, x);
> > > if (Halt_Status)
> > > HERE: goto HERE;
> > > return Halt_Status;
> > > }
> > >
> > > int main()
> > > {
> > > H(D,D);
> > > return 0;
> > > }
> > >
> > > cl /GS- /std:c11 /c /arch:IA32 Test_Compile.c
> > > cl /GS- /std:c17 /c /arch:IA32 Test_Compile.c
> > > if ERRORLEVEL 1 pause
> > >
> > >
> > > D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>echo
> > > off
> > >
> > > D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>REM
> > > 2022
> > >
> > > D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>call
> > > "C:\Program Files\Microsoft Visual
> > > Studio\2022\Community\Common7\Tools\VsDevCmd.BAT"
> > > **********************************************************************
> > > ** Visual Studio 2022 Developer Command Prompt v17.6.4
> > > ** Copyright (c) 2022 Microsoft Corporation
> > > **********************************************************************
> > > Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x86
> > > Copyright (C) Microsoft Corporation. All rights reserved.
> > >
> > > Test_Compile.c
> > > Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x86
> > > Copyright (C) Microsoft Corporation. All rights reserved.
> > >
> > > Test_Compile.c
> > > Press any key to continue . . .
> >
> > OK, My fault, gcc can compile (g++ can't. No idea why D's protocol doesn't match
> > type ptr and get compiled in C).
> >
>
>
> 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.
>
> *I just need to people that have persistently lied*
> *about this for two years to be put in their place*
>
> *Can you see that*
> For every H/D pair of the above template D correctly simulated by pure
> function (thus computable function) H cannot possibly reach its own
> final state at line 06 and halt.
People understand "H cannot possibly reach its own final state at line 06
and halt". People should be saying that your H cannot stop 'simulation' so as
to be called a simolation of D.
Your H surely can stop and make whatever decision, but since D is defined on
the behavior of H, D knows it, D will also change its behavior. This change
of behavior of D to behave differently can never be simulated and decided by H,
whatever H tries.
The logic is the same as the liar's paradox. H cannot return yes/no correctly.
All others are whatever you like to say, nothing to do with the HP. Godel,Sisper,Tarsky....
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-20 14:07 -0500 |
| Message-ID | <v2g728$4nu0$2@dont-email.me> |
| In reply to | #119183 |
On 5/20/2024 1:23 PM, wij wrote:
> On Mon, 2024-05-20 at 12:23 -0500, olcott wrote:
>> On 5/20/2024 11:21 AM, wij wrote:
>>> On Mon, 2024-05-20 at 10:02 -0500, olcott wrote:
>>>> On 5/20/2024 7:37 AM, wij wrote:
>>>>> On Sun, 2024-05-19 at 21:43 -0500, olcott wrote:
>>>>>> On 5/19/2024 8:52 PM, Bonita Montero wrote:
>>>>>>> Am 19.05.2024 um 21:00 schrieb olcott:
>>>>>>>> On 5/19/2024 1:08 PM, Bonita Montero wrote:
>>>>>>>>> Am 18.05.2024 um 23:40 schrieb olcott:
>>>>>>>>>> People are saying that they have no idea what this code does
>>>>>>>>>> because they do not believe it conforms to c11 or c17.
>>>>>>>>>>
>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>>> 00 int H(ptr x, ptr y);
>>>>>>>>>> 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 }
>>>>>>>>>>
>>>>>>>>>> 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);
>>>>>>>>>>
>>>>>>>>>> *keeps repeating* (unless aborted)
>>>>>>>>>> Line 01:
>>>>>>>>>> Line 02:
>>>>>>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>>>>>>
>>>>>>>>>> *Simulation invariant*
>>>>>>>>>> D correctly simulated by H cannot possibly reach past its own line 03.
>>>>>>>>>>
>>>>>>>>>> The key thing to note is that no D correctly simulated by any H of
>>>>>>>>>> every
>>>>>>>>>> H/D pair specified by the above template ever reaches its own line 06
>>>>>>>>>> and halts.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Other people think 30s about this, you think years about that.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is the basis for my two decades long primary research into
>>>>>>>> termination analysis. People on another forum have written
>>>>>>>> hundreds of posts claiming that D correctly simulated by H
>>>>>>>> reaches its own line 06 and halts.
>>>>>>>>
>>>>>>>> *I have only gotten truthful answers on this forum*
>>>>>>>>
>>>>>>>
>>>>>>> That's not research, that's nonsense.
>>>>>>>
>>>>>>
>>>>>> This is not the forum to show that it is not nonsense this is
>>>>>> a simple C question that I should not even have to ask except
>>>>>> for a few people in another forum that consistently lie about
>>>>>> the answer.
>>>>>>
>>>>>> I have been a professional C++ developer since Y2K. So I already
>>>>>> know the answer, I just need some competent people in this forum
>>>>>> to attest to this answer. I met Bjarne Stroustrup back when he
>>>>>> was going around the country promoting his new language.
>>>>>>
>>>>>
>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>> int H(ptr x, ptr y);
>>>>> int D(ptr x)
>>>>> {
>>>>> int Halt_Status = H(x, x);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> H(D,D);
>>>>> return 0;
>>>>> }
>>>>>
>>>>> The code above does not compile:
>>>>
>>>> *It does compile*
>>>> *It does compile*
>>>> *It does compile*
>>>> *It does compile*
>>>>
>>>> typedef int (*ptr)();
>>>> int H(ptr P, ptr I);
>>>>
>>>> int D(ptr x)
>>>> {
>>>> int Halt_Status = H(x, x);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> H(D,D);
>>>> return 0;
>>>> }
>>>>
>>>> cl /GS- /std:c11 /c /arch:IA32 Test_Compile.c
>>>> cl /GS- /std:c17 /c /arch:IA32 Test_Compile.c
>>>> if ERRORLEVEL 1 pause
>>>>
>>>>
>>>> D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>echo
>>>> off
>>>>
>>>> D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>REM
>>>> 2022
>>>>
>>>> D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>call
>>>> "C:\Program Files\Microsoft Visual
>>>> Studio\2022\Community\Common7\Tools\VsDevCmd.BAT"
>>>> **********************************************************************
>>>> ** Visual Studio 2022 Developer Command Prompt v17.6.4
>>>> ** Copyright (c) 2022 Microsoft Corporation
>>>> **********************************************************************
>>>> Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x86
>>>> Copyright (C) Microsoft Corporation. All rights reserved.
>>>>
>>>> Test_Compile.c
>>>> Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x86
>>>> Copyright (C) Microsoft Corporation. All rights reserved.
>>>>
>>>> Test_Compile.c
>>>> Press any key to continue . . .
>>>
>>> OK, My fault, gcc can compile (g++ can't. No idea why D's protocol doesn't match
>>> type ptr and get compiled in C).
>>>
>>
>>
>> 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.
>>
>> *I just need to people that have persistently lied*
>> *about this for two years to be put in their place*
>>
>> *Can you see that*
>> For every H/D pair of the above template D correctly simulated by pure
>> function (thus computable function) H cannot possibly reach its own
>> final state at line 06 and halt.
>
> People understand "H cannot possibly reach its own final state at line 06
> and halt".
That is nothing like what I said.
> People should be saying that your H cannot stop 'simulation' so as
> to be called a simolation of D.
Every element of an infinite set of H/D pairs matching the above
template where H correctly simulates 1 to ∞ steps of D thus including
0 to ∞ recursive simulations of H simulating itself simulating D.
*D correctly simulated by H never reaches its own line 06 and halts*
> Your H surely can stop and make whatever decision, but since D is defined on
> the behavior of H, D knows it, D will also change its behavior. This change
> of behavior of D to behave differently can never be simulated and decided by H,
> whatever H tries.
>
> The logic is the same as the liar's paradox. H cannot return yes/no correctly.
> All others are whatever you like to say, nothing to do with the HP. Godel,Sisper,Tarsky....
>
You are correct that this is just like the Liar Paradox.
I have a way around this that cannot be discussed in a C/C++ forum.
comp.theory is my main forum for discussing this, those people
seem clueless of the semantics of C.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-20 19:23 -0700 |
| Message-ID | <87v837kinv.fsf@nosuchdomain.example.com> |
| In reply to | #119165 |
wij <wyniijj5@gmail.com> writes:
[...]
> typedef int (*ptr)(); // ptr is pointer to int function
> int H(ptr x, ptr y);
> int D(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> int main()
> {
> H(D,D);
> return 0;
> }
>
> The code above does not compile:
Yes, it does (as you acknowledge in a later post).
This:
typedef int (*ptr)();
defines "ptr" as an alias for a type that can be described in English
as "pointer to function returning int". The empty parentheses
indicate that the function takes an unspecified but fixed number
and type(s) of arguments; this is an old-style declaration.
(The C23 standard, not yet released, changes the semantics of empty
parentheses, causing the code to be invalid, but let's assume C17.)
The function H is declared but not defined. That doesn't prevent
the code from being *compiled*, but it does prevent it from being
*linked* to produce an executable program. Perhaps a definition
of H has been presented in some other article, but I will not waste
my time hunting for it.
Ignoring variadic functions like printf, every function call
must pass the appropriate number and types of arguments, matching
the parameters defined by the corresponding function definition.
(In some cases there can be implicit type conversions, but there
are no implicit conversions for arguments or parameters of function
pointer type.) If a correct *prototype* (a function declaration that
specifies the types of all parameters) is visible, this is enforced
at compile time; failing to do so is a *constraint violation*,
requiring a compile-time diagnostic. If no such prototype is
visible, violations of this rule need not be diagnosed, but result
in *undefined behavior*; the C standard says nothing about what
the program will do.
I'll note that the code (declares and) defines the function D,
but never calls it. The address of D is passed to H, but without
a definition of H we can't guess what it does with that address.
It's possible to rewrite the code to (a) avoid the use of old-style
function declarations and (b) avoids any undefined behavior --
but without knowing or being able to guess just what the program
is supposed to do, I see no point in doing so.
The main point is this: The function H is declared but never
defined, so it's impossible to create a running program from this
code, and impossible to guess what it's intended to do without more
information. I will not make any assumptions about how H is meant
to be defined or consult other posts to find a definition. I may or
may not follow this thread to see if any clarifications are posted.
The code as presented is a valid C *translation unit*, but it is
not a valid *program*, and it has no behavior.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-20 19:31 -0700 |
| Message-ID | <87r0dvki9i.fsf@nosuchdomain.example.com> |
| In reply to | #119229 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> wij <wyniijj5@gmail.com> writes:
> [...]
>> typedef int (*ptr)(); // ptr is pointer to int function
>> int H(ptr x, ptr y);
>> int D(ptr x)
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> int main()
>> {
>> H(D,D);
>> return 0;
>> }
>>
>> The code above does not compile:
>
> Yes, it does (as you acknowledge in a later post).
>
> This:
> typedef int (*ptr)();
> defines "ptr" as an alias for a type that can be described in English
> as "pointer to function returning int". The empty parentheses
> indicate that the function takes an unspecified but fixed number
> and type(s) of arguments; this is an old-style declaration.
>
> (The C23 standard, not yet released, changes the semantics of empty
> parentheses, causing the code to be invalid, but let's assume C17.)
>
> The function H is declared but not defined. That doesn't prevent
> the code from being *compiled*, but it does prevent it from being
> *linked* to produce an executable program. Perhaps a definition
> of H has been presented in some other article, but I will not waste
> my time hunting for it.
>
> Ignoring variadic functions like printf, every function call
> must pass the appropriate number and types of arguments, matching
> the parameters defined by the corresponding function definition.
> (In some cases there can be implicit type conversions, but there
> are no implicit conversions for arguments or parameters of function
> pointer type.) If a correct *prototype* (a function declaration that
> specifies the types of all parameters) is visible, this is enforced
> at compile time; failing to do so is a *constraint violation*,
> requiring a compile-time diagnostic. If no such prototype is
> visible, violations of this rule need not be diagnosed, but result
> in *undefined behavior*; the C standard says nothing about what
> the program will do.
>
> I'll note that the code (declares and) defines the function D,
> but never calls it. The address of D is passed to H, but without
> a definition of H we can't guess what it does with that address.
>
> It's possible to rewrite the code to (a) avoid the use of old-style
> function declarations and (b) avoids any undefined behavior --
> but without knowing or being able to guess just what the program
> is supposed to do, I see no point in doing so.
>
> The main point is this: The function H is declared but never
> defined, so it's impossible to create a running program from this
> code, and impossible to guess what it's intended to do without more
> information. I will not make any assumptions about how H is meant
> to be defined or consult other posts to find a definition. I may or
> may not follow this thread to see if any clarifications are posted.
>
> The code as presented is a valid C *translation unit*, but it is
> not a valid *program*, and it has no behavior.
My apologies, I did not notice this had been posted to comp.lang.c++
until just as I posted my followup. If I had noticed that, I probably
wouldn't have posted at all. I'll try to pay better attention.
C++ does not have old-style function declaration. Empty parentheses
in a C++ function declaration or definition indicate that the
function has no parameters. In C++, a pointer of type "ptr" can
only point to a function with no parameters. The call "H(D, D)"
passes the address of the function D (which has one parameter) to
a parameter of type "ptr" (which requires a pointer to a function
with no parameters). That's an error.
The code is ill-formed in C++. And of course the lack of any
definition of H is another problem that makes it difficult or
impossible to correct the C++ errors and produce a valid program.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-20 22:58 -0500 |
| Message-ID | <v2h65i$e0lf$1@dont-email.me> |
| In reply to | #119229 |
On 5/20/2024 9:23 PM, Keith Thompson wrote:
> wij <wyniijj5@gmail.com> writes:
> [...]
>> typedef int (*ptr)(); // ptr is pointer to int function
>> int H(ptr x, ptr y);
>> int D(ptr x)
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> int main()
>> {
>> H(D,D);
>> return 0;
>> }
>>
>> The code above does not compile:
>
> Yes, it does (as you acknowledge in a later post).
>
> This:
> typedef int (*ptr)();
> defines "ptr" as an alias for a type that can be described in English
> as "pointer to function returning int". The empty parentheses
> indicate that the function takes an unspecified but fixed number
> and type(s) of arguments; this is an old-style declaration.
>
> (The C23 standard, not yet released, changes the semantics of empty
> parentheses, causing the code to be invalid, but let's assume C17.)
>
> The function H is declared but not defined. That doesn't prevent
> the code from being *compiled*, but it does prevent it from being
> *linked* to produce an executable program. Perhaps a definition
> of H has been presented in some other article, but I will not waste
> my time hunting for it.
>
> Ignoring variadic functions like printf, every function call
> must pass the appropriate number and types of arguments, matching
> the parameters defined by the corresponding function definition.
> (In some cases there can be implicit type conversions, but there
> are no implicit conversions for arguments or parameters of function
> pointer type.) If a correct *prototype* (a function declaration that
> specifies the types of all parameters) is visible, this is enforced
> at compile time; failing to do so is a *constraint violation*,
> requiring a compile-time diagnostic. If no such prototype is
> visible, violations of this rule need not be diagnosed, but result
> in *undefined behavior*; the C standard says nothing about what
> the program will do.
>
> I'll note that the code (declares and) defines the function D,
> but never calls it. The address of D is passed to H, but without
> a definition of H we can't guess what it does with that address.
>
> It's possible to rewrite the code to (a) avoid the use of old-style
> function declarations and (b) avoids any undefined behavior --
> but without knowing or being able to guess just what the program
> is supposed to do, I see no point in doing so.
>
> The main point is this: The function H is declared but never
> defined, so it's impossible to create a running program from this
> code, and impossible to guess what it's intended to do without more
> information. I will not make any assumptions about how H is meant
> to be defined or consult other posts to find a definition. I may or
> may not follow this thread to see if any clarifications are posted.
>
> The code as presented is a valid C *translation unit*, but it is
> not a valid *program*, and it has no behavior.
>
*That was a great review for c17 standards compliance*
I cannot provide the definition for H because I am asking about
the behavior of D simulated by H for the infinite set of H/D pairs.
H is required to correctly simulate 1 to N steps of D and this
may or may not involve H simulating itself simulating D in recursive
simulation.
I have two fully operational versions of H that run under Windows
and Linux. I am not asking about those.
H uses an x86 emulator to emulate the machine code of D and
H is capable of emulating itself emulating D.
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 }
Correct simulation requires correctly emulating the x86 instructions
of D in the order specified by the machine code of D and may include
correctly emulating the x86 instructions of H in the order specified
by the machine code of H.
I need to have experts in these two forums verify that no D correctly
simulated by *pure function* H can possibly reach its own final state
at line 06 and halt in N steps of correct simulation.
https://en.wikipedia.org/wiki/Pure_function#
I thought it was categorically impossible then Richard found a loophole
using static data. This new *pure function* requirement eliminates that
loophole.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-05-21 09:39 +0200 |
| Message-ID | <v2hj3j$fqfo$1@dont-email.me> |
| In reply to | #119231 |
Op 21.mei.2024 om 05:58 schreef olcott:
> On 5/20/2024 9:23 PM, Keith Thompson wrote:
>> wij <wyniijj5@gmail.com> writes:
>> [...]
>>> typedef int (*ptr)(); // ptr is pointer to int function
>>> int H(ptr x, ptr y);
>>> int D(ptr x)
>>> {
>>> int Halt_Status = H(x, x);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> int main()
>>> {
>>> H(D,D);
>>> return 0;
>>> }
>>>
>>> The code above does not compile:
>>
>> Yes, it does (as you acknowledge in a later post).
>>
>> This:
>> typedef int (*ptr)();
>> defines "ptr" as an alias for a type that can be described in English
>> as "pointer to function returning int". The empty parentheses
>> indicate that the function takes an unspecified but fixed number
>> and type(s) of arguments; this is an old-style declaration.
>>
>> (The C23 standard, not yet released, changes the semantics of empty
>> parentheses, causing the code to be invalid, but let's assume C17.)
>>
>> The function H is declared but not defined. That doesn't prevent
>> the code from being *compiled*, but it does prevent it from being
>> *linked* to produce an executable program. Perhaps a definition
>> of H has been presented in some other article, but I will not waste
>> my time hunting for it.
>>
>> Ignoring variadic functions like printf, every function call
>> must pass the appropriate number and types of arguments, matching
>> the parameters defined by the corresponding function definition.
>> (In some cases there can be implicit type conversions, but there
>> are no implicit conversions for arguments or parameters of function
>> pointer type.) If a correct *prototype* (a function declaration that
>> specifies the types of all parameters) is visible, this is enforced
>> at compile time; failing to do so is a *constraint violation*,
>> requiring a compile-time diagnostic. If no such prototype is
>> visible, violations of this rule need not be diagnosed, but result
>> in *undefined behavior*; the C standard says nothing about what
>> the program will do.
>>
>> I'll note that the code (declares and) defines the function D,
>> but never calls it. The address of D is passed to H, but without
>> a definition of H we can't guess what it does with that address.
>>
>> It's possible to rewrite the code to (a) avoid the use of old-style
>> function declarations and (b) avoids any undefined behavior --
>> but without knowing or being able to guess just what the program
>> is supposed to do, I see no point in doing so.
>>
>> The main point is this: The function H is declared but never
>> defined, so it's impossible to create a running program from this
>> code, and impossible to guess what it's intended to do without more
>> information. I will not make any assumptions about how H is meant
>> to be defined or consult other posts to find a definition. I may or
>> may not follow this thread to see if any clarifications are posted.
>>
>> The code as presented is a valid C *translation unit*, but it is
>> not a valid *program*, and it has no behavior.
>>
>
> *That was a great review for c17 standards compliance*
>
> I cannot provide the definition for H because I am asking about
> the behavior of D simulated by H for the infinite set of H/D pairs.
>
> H is required to correctly simulate 1 to N steps of D and this
> may or may not involve H simulating itself simulating D in recursive
> simulation.
>
> I have two fully operational versions of H that run under Windows
> and Linux. I am not asking about those.
>
> H uses an x86 emulator to emulate the machine code of D and
> H is capable of emulating itself emulating D.
>
> 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 }
>
> Correct simulation requires correctly emulating the x86 instructions
> of D in the order specified by the machine code of D and may include
> correctly emulating the x86 instructions of H in the order specified
> by the machine code of H.
>
> I need to have experts in these two forums verify that no D correctly
> simulated by *pure function* H can possibly reach its own final state
> at line 06 and halt in N steps of correct simulation.
> https://en.wikipedia.org/wiki/Pure_function#
Olcott is unable to prove his claim. It seems that he understands,
(although he does not admit) that a claim without a proof has little
value. Therefore is looking for experts to do the home work for him.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-05-21 09:55 +0200 |
| Message-ID | <v2hk19$gcup$1@dont-email.me> |
| In reply to | #119231 |
On 21.05.2024 05:58, olcott wrote:
> [...]
>
> I cannot provide the definition for H because I am asking about
> the behavior of D simulated by H for the infinite set of H/D pairs.
>
> H is required to correctly simulate 1 to N steps of D and this
> may or may not involve H simulating itself simulating D in recursive
> simulation.
>
> I have two fully operational versions of H that run under Windows
> and Linux. I am not asking about those.
>
> H uses an x86 emulator to emulate the machine code of D and
> H is capable of emulating itself emulating D.
>
> 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 }
>
> Correct simulation requires correctly emulating the x86 instructions
> of D in the order specified by the machine code of D and may include
> correctly emulating the x86 instructions of H in the order specified
> by the machine code of H.
>
> I need to have experts in these two forums verify that no D correctly
> simulated by *pure function* H can possibly reach its own final state
> at line 06 and halt in N steps of correct simulation.
We're not doing your homework for you. Please provide or elaborate
a rationale or explanation for your claim, thought, or theorem, and
folks here may be able and willing to support you, or show you any
possibly existing deficiencies.
(Fred Zwarts has, with slightly different wording, already given this
hint to you just 24 hours ago. I notice he just repeated that post.)
Just ignoring the replies thus far and stupidly repeating your code
is likely considered pathological behavior and may not be honored by
the audience.
If you don't understand that it's probably better to just hold your
breath until you turn blue instead of repeating your post without
generating any new insights (on both sides).
> https://en.wikipedia.org/wiki/Pure_function#
>
> I thought it was categorically impossible then Richard found a loophole
> using static data. This new *pure function* requirement eliminates that
> loophole.
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-21 08:31 -0500 |
| Message-ID | <v2i7no$jvcs$1@dont-email.me> |
| In reply to | #119235 |
On 5/21/2024 2:55 AM, Janis Papanagnou wrote:
> On 21.05.2024 05:58, olcott wrote:
>> [...]
>>
>> I cannot provide the definition for H because I am asking about
>> the behavior of D simulated by H for the infinite set of H/D pairs.
>>
>> H is required to correctly simulate 1 to N steps of D and this
>> may or may not involve H simulating itself simulating D in recursive
>> simulation.
>>
>> I have two fully operational versions of H that run under Windows
>> and Linux. I am not asking about those.
>>
>> H uses an x86 emulator to emulate the machine code of D and
>> H is capable of emulating itself emulating D.
>>
>> 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 }
>>
>> Correct simulation requires correctly emulating the x86 instructions
>> of D in the order specified by the machine code of D and may include
>> correctly emulating the x86 instructions of H in the order specified
>> by the machine code of H.
>>
>> I need to have experts in these two forums verify that no D correctly
>> simulated by *pure function* H can possibly reach its own final state
>> at line 06 and halt in N steps of correct simulation.
>
> We're not doing your homework for you. Please provide or elaborate
> a rationale or explanation for your claim, thought, or theorem, and
> folks here may be able and willing to support you, or show you any
> possibly existing deficiencies.
>
It is not homework.
I claim that D correctly simulated by H (using an x86 emulator)
never reaches its own final state at line 06 and halts for every
H/D pair matching the above template. Additional details are off-topic.
> (Fred Zwarts has, with slightly different wording, already given this
> hint to you just 24 hours ago. I notice he just repeated that post.)
>
> Just ignoring the replies thus far and stupidly repeating your code
> is likely considered pathological behavior and may not be honored by
> the audience.
>
I do not ignore the replies unless they change the subject.
> If you don't understand that it's probably better to just hold your
> breath until you turn blue instead of repeating your post without
> generating any new insights (on both sides).
>
>
>> https://en.wikipedia.org/wiki/Pure_function#
>>
>> I thought it was categorically impossible then Richard found a loophole
>> using static data. This new *pure function* requirement eliminates that
>> loophole.
>>
>>
>
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-05-21 15:56 +0200 |
| Message-ID | <v2i95g$kdk7$1@raubtier-asyl.eternal-september.org> |
| In reply to | #119240 |
Am 21.05.2024 um 15:31 schrieb olcott: > It is not homework. > I claim that D correctly simulated by H (using an x86 emulator) > never reaches its own final state at line 06 and halts for every > H/D pair matching the above template. Additional details are off-topic. What's the practical purpose for that ? I think comp.theory is a proper group for your questions since your question is generic to alot of languages.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-21 09:09 -0500 |
| Subject | Can D correctly simulated by H reach its own line 06 and halt? |
| Message-ID | <v2i9ur$kiq6$1@dont-email.me> |
| In reply to | #119242 |
On 5/21/2024 8:56 AM, Bonita Montero wrote: > Am 21.05.2024 um 15:31 schrieb olcott: > >> It is not homework. >> I claim that D correctly simulated by H (using an x86 emulator) >> never reaches its own final state at line 06 and halts for every >> H/D pair matching the above template. Additional details are off-topic. > > What's the practical purpose for that ? I think comp.theory is > a proper group for your questions since your question is generic > to alot of languages. > > I am only asking the c experts here whether or not D correctly simulated by *pure function* H can possibly reach its own line 06 and halt for every H/D pair matching the template provided. On 5/20/2024 9:23 PM, Keith Thompson confirmed that it is c17 compliant and it does compile I had to add the *pure function* requirement because Richard found a loophole using local static data. It had been agreed years ago that local static data was not allowed yet never expressly stated in the spec, so Richard took this as a loophole. https://en.wikipedia.org/wiki/Pure_function# This aspect <is> a c question. The people on other groups simply don't know c well enough. WST 2023: 19th International Workshop on Termination https://easychair.org/cfp/WST2023 AProVE: Non-Termination Witnesses for C Programs https://link.springer.com/chapter/10.1007/978-3-030-99527-0_21 -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-05-21 20:01 +0200 |
| Subject | Re: Can D correctly simulated by H reach its own line 06 and halt? |
| Message-ID | <v2inha$n6d0$1@raubtier-asyl.eternal-september.org> |
| In reply to | #119243 |
Am 21.05.2024 um 16:09 schrieb olcott: > I am only asking the c experts here whether or not D correctly > simulated by *pure function* H can possibly reach its own line > 06 and halt for every H/D pair matching the template provided. Saying this is a question about C is like questioning something about physics in Polish and claiming this is a question about Polish.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-21 13:09 -0500 |
| Subject | Re: Can D correctly simulated by H reach its own line 06 and halt? |
| Message-ID | <v2io05$n763$1@dont-email.me> |
| In reply to | #119244 |
On 5/21/2024 1:01 PM, Bonita Montero wrote:
> Am 21.05.2024 um 16:09 schrieb olcott:
>
>> I am only asking the c experts here whether or not D correctly
>> simulated by *pure function* H can possibly reach its own line
>> 06 and halt for every H/D pair matching the template provided.
>
> Saying this is a question about C is like questioning something
> about physics in Polish and claiming this is a question about
> Polish.
I am convinced that the question can be fully answered entirely on the
basis of the semantics of C in the exact same way that the termination
status of the following functions can be answered entirely on the basis
of sufficient knowledge of the semantics of c.
*If you believe otherwise then I ask for you to please justify this*
void Infinite_Recursion()
{
Infinite_Recursion();
}
int factorial(int n) // called with 5
{
if (n >= 1)
return n*factorial(n-1);
else
return 1;
}
void Infinite_Loop()
{
HERE: goto HERE;
}
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web