Re: Can D simulated by H terminate normally? --- Message_ID Provided

On 5/18/24 11:59 PM, olcott wrote:

On 5/18/2024 6:38 PM, Richard Damon wrote:

On 5/18/24 7:24 PM, olcott wrote:

On 5/18/2024 6:06 PM, Richard Damon wrote:

On 5/18/24 6:44 PM, olcott wrote:

On 5/18/2024 3:02 PM, Richard Damon wrote:

On 5/18/24 3:57 PM, olcott wrote:

On 5/1/2024 7:10 PM, Richard Damon wrote:

The second method uses the fact that you have not restricted what H is allowed to do, and thus H can remember that it is simulating, and if a call to H shows that it is currently doing a simulation, just immediately return 0.

>
Nice try but this has no effect on any D correctly simulated by H.
When the directly executed H aborts its simulation it only returns
to whatever directly executed it.

>
Why? My H does correctly simulate the D it was given.
>
You don't seem to understand how the C code actually works.
>

>
If the directly executed outermost H does not abort then none of
the inner simulated ones abort because they are the exact same code.
When the directly executed outermost H does abort it can only return
to its own caller.

>
WHAT inner simulatioin?
>
>
My H begins as:
>
int H(ptr x, ptr y) {
   static int flag = 0;
   if(flag) return 0;
   flag = 1;
>
followed by essentially your code for H, except that you need to disable the hack that doesn't simulate the call to H, but just let it continue into H where it will immediately return to D and D will then return.
>
>
Thus, your claim is shown to be wrong.
>

>
We are talking about every element of an infinite set where
H correctly simulates 1 to ∞ steps of D thus including 0 to ∞
recursive simulations of H simulating itself simulating D.
>
*At whatever point the directly executed H(D,D) stops simulating*
*its input it cannot possibly return to any simulated input*

>
And my H never stops simulating, so that doesn't apply. It will reach the final state.

>
*Show the error in my execution trace that I empirically*
*proved has no error by H correctly simulating D to the*
*point where H correctly simulates itself simulating D*
(Fully operational empirically code proved this)

>
See below:
>
>

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

>
For Reference
>
14 int H(ptr x, ptr y)
15 {
16   static int flag = 0
17   if (flag)
18      return 0
19   ... continuation of H that simulates its input
>

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

>
Line 03: Calls H (line 14)
Line 16: Static already inited, so not changed.
Line 17: Flag is 1, so
Line 18: Return 0
Line 03: Set Halt_Status to 0
Line 04: if (Halt_Status)      halts status is 0, so skip
Line 06: return Halt_Status
>
Simulation completed, program halted.
>
>

>
Simulation invariant:
D correctly simulated by H cannot possibly reach past its own line 03.
>
>

>
Nope. Not for this H
>
>

 (a) That idea might work yet you did not say it correctly.
For example line 11 is the first one invoked.

No, I was showing what happens INSTEAD of your last line 03.
Are you so stupid that you need everything just fully explained to you?

(b) Computable functions cannot alter their behavior this way.

But C programs are NOT "Computable Functions", they might be the example to prove that a Functions is computable, but they are not "Computable Functions" themselves, as "Computable Functions" are a sub-type of the Mathematical concept of a "Function", which in this context, is a mathematical mapping of input values to outputs.
A program, like H, isn't itself a mapping, but produces as a semantic property of itself such a mapping, which if it matches the Function being looked at, shows that function is computable.
This sort of error by you just show how mis-learned by rote your knowledge base is. You just don't understand the meaning of many of the words you use, cause you to make just plain dumb errors.
Note also, your requirements were never listed as such, when asked, you said that the source code given was the sole definition, and H just needed to be a C program that simulated its input.

 (1) the function return values are identical for identical arguments (no
variation with local static variables, non-local variables, mutable
reference arguments or input streams, i.e., referential transparency), and

SO, YOU H fails to meet that, since we have that H(D,D) returns 0 when called by main, but you logic says that H(D,D) when called by D(D) never returns. This is one of the reasons you seemed to have dropped back from H being a "Turing Equivant" to Linz's H, because you do logic that doesn't work with that limitation.
And, your stated requirements on H did not say it needed to be a "pure function", just that it was a "C program".
Note, if you want to add the requirement that H MUST be a "pure function", then the only correct determination of the behavior of a function is its actual behavior, which means your H that determines that H doesn't return is just wrong, since it does.
Aborted partial simulation, especially of a DIFFERENT input (using an H other than the H that the D given to the H in question actually calls).

 (2) the function has no side effects (no mutation of local static
variables, non-local variables, mutable reference arguments or
input/output streams).
https://en.wikipedia.org/wiki/Pure_function