Re: Every D(D) is correctly simulated by H

On 5/20/24 2:33 PM, olcott wrote:

On 5/19/2024 6:31 PM, Richard Damon wrote:

On 5/19/24 4:59 PM, olcott wrote:

On 5/19/2024 2:49 PM, Richard Damon wrote:

On 5/19/24 3:29 PM, olcott wrote:

On 5/19/2024 2:09 PM, Richard Damon wrote:

On 5/19/24 2:13 PM, olcott wrote:

On 5/19/2024 12:17 PM, Richard Damon wrote:

On 5/19/24 10:03 AM, olcott wrote:

On 5/19/2024 8:48 AM, Mikko wrote:

On 2024-05-19 12:34:08 +0000, olcott said:
>

On 5/19/2024 2:53 AM, Mikko wrote:

On 2024-05-18 15:34:36 +0000, James Kuyper said:
>

On 5/18/24 09:02, Mikko wrote:

On 2024-05-17 17:14:01 +0000, olcott said:

>
I recommend ignoring olcott - nothing good ever comes from paying
attention to him.
>

On 5/17/2024 5:53 AM, Mikko wrote:

On 2024-05-16 14:50:19 +0000, olcott said:
>

On 5/16/2024 5:48 AM, Mikko wrote:

On 2024-05-15 15:24:57 +0000, olcott said:

...

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

>
Can you find any compiler that is liberal enough to accept that?
>

>
It has been fully operational code under Windows and
Linux for two years.

>
If your compiler does not reject that program it is not a conforming
C compiler. The semantics according to C standard is that a diagnostic
message must be given. The standard does not specify what happens if
you execute that program anyway.
>

>
It is not nit picky syntax that is the issue here.
The SEMANTICS OF THE C PROGRAMMING LANGUAGE SPECIFIES
>
No D simulated correctly by any H of every H/D pair specified
by the above template ever reaches its own line 06 and halts.

>
The standard allows that an program is executed but does not
specify what happens when an invalid program is executed.

>
You've cross-posted this to comp.lang.c after a long-running discussion
solely on comp.theory. Presumably you're doing that because you want
some discussion about what the standard says about this code. For the
sake of those of us who have not been following that discussion on
comp.theory, could you please identify what it is that you think renders
this code invalid? Offhand, I don't see anything wrong with it, but I'm
far more reliable when I say "I see an error" than when I say "I don't
see an error".
>
>

Fully operational software that runs under Widows and Linux
proves that the above is true EMPIRICALLY.

>
No, it does not. As the program is not strictly comforming
and uses a non-standard extension some implementation may
execute it differently or refuse to execute.

>
Which non-standard extension does it use?

>
The main question is whether both arguments of H on the line 00 can have
the same name.

>
That was a typo that I did not believe when told because so may people
continue to lie about the behavior of D correctly simulated by H.

>
How does the D that is correctly simulated by H different from any
D that is incorrectly simulated by H nor not simulated by H?
>

>
typedef int (*ptr)();  // ptr is pointer to int function
00 int H(ptr p, ptr i);
01 int D(ptr p)
02 {
03   int Halt_Status = H(p, p);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 int main()
10 {
11   H(D,D);
12   return 0;
13 }
>
In the above case a simulator is an x86 emulator that correctly
emulates at least one of the x86 instructions of D in the order
specified by the x86 instructions of D.
>
This may include correctly emulating the x86 instructions of H
in the order specified by the x86 instructions of H thus calling
H(D,D) in recursive simulation.
>

>
Which has been proven incorrect.

>
*Quoted from page 4 of the paper linked below*
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
   if (H(x, x))HERE:
    goto HERE;
}
>
int main()
{
   Output("Input_Halts = ", H((u32)P, (u32)P));
}
>
That P is correctly simulated by H is proven by the fact that
every assembly language instruction of P is correctly simulated
by H in the order specified by the x86 assembly language of P
even when H correctly simulates itself simulating P.
>
All of the details of this (except the 354 page execution
trace of H) are shown on pages 4-5 of the following paper.

>
Which of course, will have the details of what H did wrong.
>

>
*Halting problem undecidability and infinitely nested simulation*
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>

>
So, which instruction CORRECTLY SIMULATED allows H to CORRECTLY DETERMINE that its input is non-halting?
>

>
*This diverges from the point in the subject line*
*This diverges from the point in the subject line*
*This diverges from the point in the subject line*
>
I cannot afford to tolerate the CHANGE-THE-SUBJECT REBUTTAL
that wasted 15 years of my life with Ben Bacarisse
>
Your claim has always been that D correctly simulated by H does
reach its final instruction at line 06.

>
Yes.
>
If H begins as:
>
int H(ptr x, ptr y) {
   static int flag = 0;
   if (flag) return 0;
   flag = 1
>
... the rest of your normal H function, modified if needed to actually simulate into H, and to not stop until it reaches the end.
>

>
The key thing to note is that when H is a *pure function* then 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.

>
>
So, moving the goal post again.
>

 *That requirement was thought to be mutually understood*

Why? It seemed you had abandoned it quite a while ago, because

 

Note, if H is defined to be a pure function, then the ONLY correct simulation of D must show the H it calls doing the same thing as the H called by main, which yours doesn't, showing your logic is incorrect, and the "simulation" (or the logic using it) is just incorrect.
>

 *This is the whole spec, you keep trying to diverge from it*

Which still doesn't say that H must be a "pure function"
So, I guess you lied about that requirement!!!

 typedef int (*ptr)();  // ptr is pointer to int function
00 int H(ptr p, ptr i);
01 int D(ptr p)
02 {
03   int Halt_Status = H(p, p);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 int main()
10 {
11   H(D,D);
12   return 0;
13 }
 In the above case a simulator is an x86 emulator that correctly emulates
at least one of the x86 instructions of D in the order specified by the
x86 instructions of D.
 This may include correctly emulating the x86 instructions of H in the
order specified by the x86 instructions of H thus calling H(D,D) in
recursive simulation.
 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.
 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.
 

Which leads to "Undefined behavior" as you apparently have multiple definitions of the program H in a single execution unit.
What is your "Program Model" that allows a single symbol to simulataneously represent a single program to execute/trace and also an "unspecified" infinite set of such programs.
It seems your whole logic system rests on this sort of built in ambiguity.