Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #384618 > unrolled thread

Can someone please verify the execution trace of this?

Back to article view | Back to comp.lang.c

Contents

  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? Rosario19 <Ros@invalid.invalid> - 2024-05-19 06:25 +0200
      Re: Can someone please verify the execution trace of this? olcott <polcott333@gmail.com> - 2024-05-18 23:58 -0500
    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? 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? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 21:23 -0700
                                  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? tTh <tth@none.invalid> - 2024-05-22 06:45 +0200
                                        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:47 -0700
                                    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? 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? bart <bc@freeuk.com> - 2024-05-21 22:34 +0100
                                    Re: Can D correctly simulated by H reach its own line 06 and halt? olcott <polcott333@gmail.com> - 2024-05-21 16:56 -0500
                                      Re: Can D correctly simulated by H reach its own line 06 and halt? David Brown <david.brown@hesbynett.no> - 2024-05-22 10:54 +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 [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] wij <wyniijj5@gmail.com> - 2024-05-23 04:59 +0800
                                              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 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 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
            Partial function types Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 22:15 -0700
              Re: Partial function types Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-21 23:27 -0700
    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 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

#384724 — Can D simulated by any H possibly reach its own line 06 and halt?

On 5/20/2024 11:00 PM, Chris M. Thomasson wrote:
> What is his point?

Keith Thompson verified it does compile and is c17
standard compliant.

*I renamed this thread to focus on the key point*
*I renamed this thread to focus on the key point*
*I renamed this thread to focus on the key point*

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 }

The above template specifies and infinite set of H/D pairs where
*pure function* H correctly simulates N steps of D with an x86 emulator. 
https://en.wikipedia.org/wiki/Pure_function#

*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.

I need to verify that D correctly simulated by any *pure function*
H cannot possibly reach its own line 06 and halt.

Richard just found a loophole using static local data, so I added
the *pure function* requirement.


-- 
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]

#384722

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]

#384729

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]

#384730

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]

#384741

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]

#384743

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]

#384744 — Can D correctly simulated by H reach its own line 06 and halt?

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]

#384750 — Re: Can D correctly simulated by H reach its own line 06 and halt?

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]

#384751 — Re: Can D correctly simulated by H reach its own line 06 and halt?

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]

#384752 — Re: Can D correctly simulated by H reach its own line 06 and halt?

Am 21.05.2024 um 20:09 schrieb olcott:
> 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;
> }
> 
> 

This is possible with most languages so this isn't a question about C.

[toc] | [prev] | [next] | [standalone]

#384753 — Re: Can D correctly simulated by H reach its own line 06 and halt?

On 5/21/2024 1:13 PM, Bonita Montero wrote:
> Am 21.05.2024 um 20:09 schrieb olcott:
>> 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;
>> }
>>
>>
> 
> This is possible with most languages so this isn't a question about C.

None-the-less the semantics of my code template does seem
to prove the result that I stated. I would not even be here
except for the people in the other forum that consistently
lie about this.

-- 
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]

#384755 — Re: Can D correctly simulated by H reach its own line 06 and halt?

Am 21.05.2024 um 20:24 schrieb olcott:
> On 5/21/2024 1:13 PM, Bonita Montero wrote:
>> Am 21.05.2024 um 20:09 schrieb olcott:
>>> 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;
>>> }
>>>
>>>
>>
>> This is possible with most languages so this isn't a question about C.
> 
> None-the-less the semantics of my code template does seem
> to prove the result that I stated. I would not even be here
> except for the people in the other forum that consistently
> lie about this.
> 

You're neither asking about a C- or C++ problem.
So use a proper newsgroup.

[toc] | [prev] | [next] | [standalone]

#384756 — Re: Can D correctly simulated by H reach its own line 06 and halt?

On 5/21/2024 1:39 PM, Bonita Montero wrote:
> Am 21.05.2024 um 20:24 schrieb olcott:
>> On 5/21/2024 1:13 PM, Bonita Montero wrote:
>>> Am 21.05.2024 um 20:09 schrieb olcott:
>>>> 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;
>>>> }
>>>>
>>>>
>>>
>>> This is possible with most languages so this isn't a question about C.
>>
>> None-the-less the semantics of my code template does seem
>> to prove the result that I stated. I would not even be here
>> except for the people in the other forum that consistently
>> lie about this.
>>
> 
> You're neither asking about a C- or C++ problem.
> So use a proper newsgroup.
> 

There is no other group that knows enough about the semantics of the
C programming language and there is no other group still alive that
knows enough about the semantics of programming languages.

-- 
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]

#384769 — Re: Can D correctly simulated by H reach its own line 06 and halt?

On 21/05/2024 19:48, olcott wrote:
> On 5/21/2024 1:39 PM, Bonita Montero wrote:

>> You're neither asking about a C- or C++ problem.
>> So use a proper newsgroup.
>>
> 
> There is no other group that knows enough about the semantics of the
> C programming language and there is no other group still alive that
> knows enough about the semantics of programming languages.

Then FFS take it to Reddit, where there are a myriad thriving forums, 
rather than a dying usenet group populated by a few aging regulars.

[toc] | [prev] | [next] | [standalone]

#384772 — Re: Can D correctly simulated by H reach its own line 06 and halt?

On 5/21/2024 4:34 PM, bart wrote:
> On 21/05/2024 19:48, olcott wrote:
>> On 5/21/2024 1:39 PM, Bonita Montero wrote:
> 
>>> You're neither asking about a C- or C++ problem.
>>> So use a proper newsgroup.
>>>
>>
>> There is no other group that knows enough about the semantics of the
>> C programming language and there is no other group still alive that
>> knows enough about the semantics of programming languages.
> 
> Then FFS take it to Reddit, where there are a myriad thriving forums, 
> rather than a dying usenet group populated by a few aging regulars.
> 
> 

I have taken it to many different forums.
This is one of two forums where someone actually answered the question.
Two years ago someone answered the assembly language version of the 
question. I think the Reddit banned me for even asking the question.

-- 
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]

#384798 — Re: Can D correctly simulated by H reach its own line 06 and halt?

On 21/05/2024 23:56, olcott wrote:
> On 5/21/2024 4:34 PM, bart wrote:
>> On 21/05/2024 19:48, olcott wrote:
>>> On 5/21/2024 1:39 PM, Bonita Montero wrote:
>>
>>>> You're neither asking about a C- or C++ problem.
>>>> So use a proper newsgroup.
>>>>
>>>
>>> There is no other group that knows enough about the semantics of the
>>> C programming language and there is no other group still alive that
>>> knows enough about the semantics of programming languages.
>>
>> Then FFS take it to Reddit, where there are a myriad thriving forums, 
>> rather than a dying usenet group populated by a few aging regulars.
>>
>>
> 
> I have taken it to many different forums.
> This is one of two forums where someone actually answered the question.
> Two years ago someone answered the assembly language version of the 
> question. I think the Reddit banned me for even asking the question.
> 

The /only/ reason you are not banned here is because unmoderated Usenet 
groups cannot ban people.

You post obsessively in many places, and face nothing but rejection, 
ridicule, and banning.  Has it ever occurred to you to look for the 
common factor here?  It is /you/, and the posts you make.  If you truly 
want to make progress on your bizarre ideas, you are going to have to 
re-think your strategy - it is entirely obvious to everyone that you 
will not get the answers you are asking for here or anywhere else with 
your current posting style.

[toc] | [prev] | [next] | [standalone]

#384811 — D correctly simulated by H remains stuck in recursive simulation

On 5/22/2024 3:54 AM, David Brown wrote:
> On 21/05/2024 23:56, olcott wrote:
>> On 5/21/2024 4:34 PM, bart wrote:
>>> On 21/05/2024 19:48, olcott wrote:
>>>> On 5/21/2024 1:39 PM, Bonita Montero wrote:
>>>
>>>>> You're neither asking about a C- or C++ problem.
>>>>> So use a proper newsgroup.
>>>>>
>>>>
>>>> There is no other group that knows enough about the semantics of the
>>>> C programming language and there is no other group still alive that
>>>> knows enough about the semantics of programming languages.
>>>
>>> Then FFS take it to Reddit, where there are a myriad thriving forums, 
>>> rather than a dying usenet group populated by a few aging regulars.
>>>
>>>
>>
>> I have taken it to many different forums.
>> This is one of two forums where someone actually answered the question.
>> Two years ago someone answered the assembly language version of the 
>> question. I think the Reddit banned me for even asking the question.
>>
> 
> The /only/ reason you are not banned here is because unmoderated Usenet 
> groups cannot ban people.
> 
> You post obsessively in many places, and face nothing but rejection, 
> ridicule, and banning.  Has it ever occurred to you to look for the 
> common factor here?  It is /you/, and the posts you make.  If you truly 
> want to make progress on your bizarre ideas, you are going to have to 
> re-think your strategy - it is entirely obvious to everyone that you 
> will not get the answers you are asking for here or anywhere else with 
> your current posting style.
> 
> 

*On the other hand people could simply answer my question*
*I only repeat it until it is answered*

For every H/D pair matching the following template where
H is a pure function:

Does any D correctly simulated by H reach its own line 06 and
halt or does the fact that D remains stuck in recursive simulation
prevent that?

typedef int (*ptr)();  // ptr is pointer to int function in C
00       int H(ptr p, ptr i);
01       int D(ptr p)
02       {
03         int Halt_Status = H(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         H(D,D);
12         return 0;
13       }

It is trivial to see that for every H/D pair of the infinite
set of H/D pairs that match the above template that

D correctly simulated by H cannot possibly reach its own final
state at line 06 and halt because D correctly simulated by
H remains stuck in recursive simulation.

This provides the basis for simulating termination analyzer H to
correctly determine that the halting problem's counter-example
input D cannot possibly 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]

#384812 — Re: D correctly simulated by H remains stuck in recursive simulation

Op 22.mei.2024 om 17:44 schreef olcott:
> On 5/22/2024 3:54 AM, David Brown wrote:
>> On 21/05/2024 23:56, olcott wrote:
>>> On 5/21/2024 4:34 PM, bart wrote:
>>>> On 21/05/2024 19:48, olcott wrote:
>>>>> On 5/21/2024 1:39 PM, Bonita Montero wrote:
>>>>
>>>>>> You're neither asking about a C- or C++ problem.
>>>>>> So use a proper newsgroup.
>>>>>>
>>>>>
>>>>> There is no other group that knows enough about the semantics of the
>>>>> C programming language and there is no other group still alive that
>>>>> knows enough about the semantics of programming languages.
>>>>
>>>> Then FFS take it to Reddit, where there are a myriad thriving 
>>>> forums, rather than a dying usenet group populated by a few aging 
>>>> regulars.
>>>>
>>>>
>>>
>>> I have taken it to many different forums.
>>> This is one of two forums where someone actually answered the question.
>>> Two years ago someone answered the assembly language version of the 
>>> question. I think the Reddit banned me for even asking the question.
>>>
>>
>> The /only/ reason you are not banned here is because unmoderated 
>> Usenet groups cannot ban people.
>>
>> You post obsessively in many places, and face nothing but rejection, 
>> ridicule, and banning.  Has it ever occurred to you to look for the 
>> common factor here?  It is /you/, and the posts you make.  If you 
>> truly want to make progress on your bizarre ideas, you are going to 
>> have to re-think your strategy - it is entirely obvious to everyone 
>> that you will not get the answers you are asking for here or anywhere 
>> else with your current posting style.
>>
>>
> 
> *On the other hand people could simply answer my question*
> *I only repeat it until it is answered*
Why would an answer help? Would you then try a proof by authority? That 
does not help. You should work on a proof, instead of waiting for an 
answer. Waiting is spoiling your time. Try to formulate the proof.

[toc] | [prev] | [next] | [standalone]

#384828 — Re: D correctly simulated by H remains stuck in recursive simulation [good attempt]

On 5/22/2024 11:11 AM, wij wrote:
> On Wed, 2024-05-22 at 10:44 -0500, olcott wrote:
>> On 5/22/2024 3:54 AM, David Brown wrote:
>>> On 21/05/2024 23:56, olcott wrote:
>>>> On 5/21/2024 4:34 PM, bart wrote:
>>>>> On 21/05/2024 19:48, olcott wrote:
>>>>>> On 5/21/2024 1:39 PM, Bonita Montero wrote:
>>>>>
>>>>>>> You're neither asking about a C- or C++ problem.
>>>>>>> So use a proper newsgroup.
>>>>>>>
>>>>>>
>>>>>> There is no other group that knows enough about the semantics of the
>>>>>> C programming language and there is no other group still alive that
>>>>>> knows enough about the semantics of programming languages.
>>>>>
>>>>> Then FFS take it to Reddit, where there are a myriad thriving forums,
>>>>> rather than a dying usenet group populated by a few aging regulars.
>>>>>
>>>>>
>>>>
>>>> I have taken it to many different forums.
>>>> This is one of two forums where someone actually answered the question.
>>>> Two years ago someone answered the assembly language version of the
>>>> question. I think the Reddit banned me for even asking the question.
>>>>
>>>
>>> The /only/ reason you are not banned here is because unmoderated Usenet
>>> groups cannot ban people.
>>>
>>> You post obsessively in many places, and face nothing but rejection,
>>> ridicule, and banning.  Has it ever occurred to you to look for the
>>> common factor here?  It is /you/, and the posts you make.  If you truly
>>> want to make progress on your bizarre ideas, you are going to have to
>>> re-think your strategy - it is entirely obvious to everyone that you
>>> will not get the answers you are asking for here or anywhere else with
>>> your current posting style.
>>>
>>>
>>
>> *On the other hand people could simply answer my question*
>> *I only repeat it until it is answered*
>>
>> For every H/D pair matching the following template where
>> H is a pure function:
>>
>> Does any D correctly simulated by H reach its own line 06 and
>> halt or does the fact that D remains stuck in recursive simulation
>> prevent that?
>>
>> typedef int (*ptr)();  // ptr is pointer to int function in C
>> 00       int H(ptr p, ptr i);
>> 01       int D(ptr p)
>> 02       {
>> 03         int Halt_Status = H(p, p);
>> 04         if (Halt_Status)
>> 05           HERE: goto HERE;
>> 06         return Halt_Status;
>> 07       }
>> 08
>> 09       int main()
>> 10       {
>> 11         H(D,D);
>> 12         return 0;
>> 13       }
>>
>> It is trivial to see that for every H/D pair of the infinite
>> set of H/D pairs that match the above template that
>>
>> D correctly simulated by H cannot possibly reach its own final
>> state at line 06 and halt because D correctly simulated by
>> H remains stuck in recursive simulation.
>>
>> This provides the basis for simulating termination analyzer H to
>> correctly determine that the halting problem's counter-example
>> input D cannot possibly halt.
>>
> 
> If H is truly a simulator, its function is expected to be equivalent to:
> 
> int H(ptr x, ptr y) {
>   x(y);
>   return __WHATEVER;
> }
> 
> The H(D,D) can never halt.
> 
> 

Finally someone took 30 seconds to answer, thanks!
*The actual question was slightly different in a very crucial way*

It is trivial to see that for every H/D pair of the infinite
set of H/D pairs that match the above template that

D correctly simulated by H cannot possibly reach its own final
state at line 06 and halt because D correctly simulated by
H remains stuck in recursive simulation.

*In other words even when H(D,D) terminates normally D*
*correctly simulated by H cannot possibly terminate normally*

-- 
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]

#384836 — Re: D correctly simulated by H remains stuck in recursive simulation [good attempt]

On Wed, 2024-05-22 at 15:04 -0500, olcott wrote:
> On 5/22/2024 11:11 AM, wij wrote:
> > On Wed, 2024-05-22 at 10:44 -0500, olcott wrote:
> > > On 5/22/2024 3:54 AM, David Brown wrote:
> > > > On 21/05/2024 23:56, olcott wrote:
> > > > > On 5/21/2024 4:34 PM, bart wrote:
> > > > > > On 21/05/2024 19:48, olcott wrote:
> > > > > > > On 5/21/2024 1:39 PM, Bonita Montero wrote:
> > > > > > 
> > > > > > > > You're neither asking about a C- or C++ problem.
> > > > > > > > So use a proper newsgroup.
> > > > > > > > 
> > > > > > > 
> > > > > > > There is no other group that knows enough about the semantics of the
> > > > > > > C programming language and there is no other group still alive that
> > > > > > > knows enough about the semantics of programming languages.
> > > > > > 
> > > > > > Then FFS take it to Reddit, where there are a myriad thriving forums,
> > > > > > rather than a dying usenet group populated by a few aging regulars.
> > > > > > 
> > > > > > 
> > > > > 
> > > > > I have taken it to many different forums.
> > > > > This is one of two forums where someone actually answered the question.
> > > > > Two years ago someone answered the assembly language version of the
> > > > > question. I think the Reddit banned me for even asking the question.
> > > > > 
> > > > 
> > > > The /only/ reason you are not banned here is because unmoderated Usenet
> > > > groups cannot ban people.
> > > > 
> > > > You post obsessively in many places, and face nothing but rejection,
> > > > ridicule, and banning.  Has it ever occurred to you to look for the
> > > > common factor here?  It is /you/, and the posts you make.  If you truly
> > > > want to make progress on your bizarre ideas, you are going to have to
> > > > re-think your strategy - it is entirely obvious to everyone that you
> > > > will not get the answers you are asking for here or anywhere else with
> > > > your current posting style.
> > > > 
> > > > 
> > > 
> > > *On the other hand people could simply answer my question*
> > > *I only repeat it until it is answered*
> > > 
> > > For every H/D pair matching the following template where
> > > H is a pure function:
> > > 
> > > Does any D correctly simulated by H reach its own line 06 and
> > > halt or does the fact that D remains stuck in recursive simulation
> > > prevent that?
> > > 
> > > typedef int (*ptr)();  // ptr is pointer to int function in C
> > > 00       int H(ptr p, ptr i);
> > > 01       int D(ptr p)
> > > 02       {
> > > 03         int Halt_Status = H(p, p);
> > > 04         if (Halt_Status)
> > > 05           HERE: goto HERE;
> > > 06         return Halt_Status;
> > > 07       }
> > > 08
> > > 09       int main()
> > > 10       {
> > > 11         H(D,D);
> > > 12         return 0;
> > > 13       }
> > > 
> > > It is trivial to see that for every H/D pair of the infinite
> > > set of H/D pairs that match the above template that
> > > 
> > > D correctly simulated by H cannot possibly reach its own final
> > > state at line 06 and halt because D correctly simulated by
> > > H remains stuck in recursive simulation.
> > > 
> > > This provides the basis for simulating termination analyzer H to
> > > correctly determine that the halting problem's counter-example
> > > input D cannot possibly halt.
> > > 
> > 
> > If H is truly a simulator, its function is expected to be equivalent to:
> > 
> > int H(ptr x, ptr y) {
> >   x(y);
> >   return __WHATEVER;
> > }
> > 
> > The H(D,D) can never halt.
> > 
> > 
> 
> Finally someone took 30 seconds to answer, thanks!
> *The actual question was slightly different in a very crucial way*
> 
> It is trivial to see that for every H/D pair of the infinite
> set of H/D pairs that match the above template that
> 
> D correctly simulated by H cannot possibly reach its own final
> state at line 06 and halt because D correctly simulated by
> H remains stuck in recursive simulation.

Correct. H will be stuck in the recursive simulations.

> *In other words even when H(D,D) terminates normally D*
> *correctly simulated by H cannot possibly terminate normally*

Correct. Because D is programmed to behave the opposite of what the 
called H inside H reported.

[toc] | [prev] | [next] | [standalone]

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web