On 5/1/2024 7:10 PM, Richard Damon wrote:
On 5/1/24 12:11 PM, olcott wrote:
Until you refine your current non-existant definitions of the terms,
you have the problem described.
I can't have any idea what you are saying until you fill in
all of the details of your baseless claims.
But you refuse to listen.
Remember, YOU are the one saying you are needing to change the
definition from the classical theory, where we have things well defined.
YOU have decided that H is just whatever C code you want to write for
it, and D is the input proved. (which doesn't actually match the Linz
or Sipser proof, but fairly close).
First of all the code template that I am currently referring
has nothing to do with any decider, it only pertains to a
simulator where H correctly simulates 1 to ∞ steps of D
of each H/D pair specified by the following template.
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.
With THAT set of definitions we have a lot of options that break your
incorrectly assumed results.
I augmented the definitions since you posted this reply.
The first method has been discussed here by Flibble. While the final
answer he got to doesn't fit the requirements, the first part of the
method DOES show that it is possible for an H to simulate to past line 3.
It is impossible for D to be correctly simulated by H within the
above definitions that have H as only a simulator and specify
exactly what a correct simulation is.
THe basic idea is that if H(M,d) finds that its simulation of M(d) get
to a call to H(M,d) then rather that your idea of just saying it will
get stuck and declair the input invalid, since there ARE a number of
possible inputs that there is a "correct" answer that H can give to
match the behavior of the direct execution of M(d), what H does is
fork its simulation into two threads.
Pure simulator H has no basis to do that. I am stopping here
you can update this view on this new set of definitions.
On 5/1/2024 7:10 PM, Richard Damon wrote:
On 5/1/24 12:11 PM, olcott wrote:
Until you refine your current non-existant definitions of the terms,
you have the problem described.
I can't have any idea what you are saying until you fill in
all of the details of your baseless claims.
But you refuse to listen.
Remember, YOU are the one saying you are needing to change the
definition from the classical theory, where we have things well defined.
YOU have decider that H is just whatever C code you want to write for
it, and D is the input proved. (which doesn't actually match the Linz
or Sipser proof, but fairly close).
First of all the code template that I am currently referring
has nothing to do with any decider, it only pertains to a
simulator where H correctly simulates 1 to ∞ steps of D
of each H/D pair specified by the following template.
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.
With THAT set of definitions we have a lot of options that break your
incorrectly assumed results.
I augmented the definitions since you posted this reply.
The first method has been discussed here by Flibble. While the final
answer he got to doesn't fit the requirements, the first part of the
method DOES show that it is possible for an H to simulate to past line 3.
It is impossible for D to be correctly simulated by H within the
above definitions that have H as only a simulator and specify
exactly what a correct simulation is.
THe basic idea is that if H(M,d) finds that its simulation of M(d) get
to a call to H(M,d) then rather that your idea of just saying it will
get stuck and declair the input invalid, since there ARE a number of
possible inputs that there is a "correct" answer that H can give to
match the behavior of the direct execution of M(d), what H does is
fork its simulation into two threads.
Pure simulator H has no basis to do that. I am stopping here
you can update this view on this new set of definitions.
On 5/18/2024 2:18 PM, Richard Damon wrote:
On 5/18/24 2:54 PM, olcott wrote:
On 5/1/2024 7:10 PM, Richard Damon wrote:
On 5/1/24 12:11 PM, olcott wrote:
Until you refine your current non-existant definitions of the
terms, you have the problem described.
I can't have any idea what you are saying until you fill in
all of the details of your baseless claims.
But you refuse to listen.
Remember, YOU are the one saying you are needing to change the
definition from the classical theory, where we have things well
defined.
YOU have decider that H is just whatever C code you want to write
for it, and D is the input proved. (which doesn't actually match the
Linz or Sipser proof, but fairly close).
First of all the code template that I am currently referring
has nothing to do with any decider, it only pertains to a
simulator where H correctly simulates 1 to ∞ steps of D
of each H/D pair specified by the following template.
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.
With THAT set of definitions we have a lot of options that break
your incorrectly assumed results.
I augmented the definitions since you posted this reply.
The first method has been discussed here by Flibble. While the final
answer he got to doesn't fit the requirements, the first part of the
method DOES show that it is possible for an H to simulate to past
line 3.
It is impossible for D to be correctly simulated by H within the
above definitions that have H as only a simulator and specify
exactly what a correct simulation is.
THe basic idea is that if H(M,d) finds that its simulation of M(d)
get to a call to H(M,d) then rather that your idea of just saying it
will get stuck and declair the input invalid, since there ARE a
number of possible inputs that there is a "correct" answer that H
can give to match the behavior of the direct execution of M(d), what
H does is fork its simulation into two threads.
Pure simulator H has no basis to do that. I am stopping here
you can update this view on this new set of definitions.
And point of fact, YOUR H doesn't meet your definition either,
The above refers to pure simulator H that correctly simulates
1 to ∞ steps of D. It takes you a very very long time to
*PAY COMPLETE ATTENTION TO ALL OF MY EXACT WORDS*
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.
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.
Thus, H can actually correct simulate the instruction at the call to
H, as they will execute just a few instructions testing that condition
and returning, and thus not run into the problem you ran into where H
just couldn't simulate itself because it got bogged down.
In this case it is actually true that the direct execution of D(D)
differs from the correct simulation of the input by H, as H is no
longer a "Computation" per the rules of Computation Theory, but you
have admitted that you are abandoning those, so it doesn't matter (of
course that make trying to get your results to apply to something
similar harder, but that is why you need to try to come up with some
actual definitons.)
So, by the rules of Compuation Theory, your H is not correct, but by
your lack of rules, your conclusion that H can not simulate past the
call are incorrect, so you proof is also broken.
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.
My original H(P,P) does simulate itself simulating P.
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.
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*
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)
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.
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.
(b) Computable functions cannot alter their behavior this way.
(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
On 5/19/2024 7:16 AM, immibis wrote:
On 19/05/24 05:59, 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.
(b) Computable functions cannot alter their behavior this way.
(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
Your function H works like Richard's function H. You just called the
variable "execution trace" instead of "flag".
Since Richard did not respond to this post I am taking that
as he understands that he is incorrect.
He has known this whole time that we having only been talking
about computable functions. Thus he knows his example using
static data is no good.
On 5/19/2024 12:17 PM, Richard Damon wrote:
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?
*You just admitted that you thought that lying is OK because*
*I did not specifically say that I expect correct answers*
On 5/19/2024 12:17 PM, Richard Damon wrote:
On 5/19/24 9:59 AM, olcott wrote:
Richard has stated that he thinks that an example of
{D never simulated by H} ∈ {every D simulated by H}
No, the H that didn't simulate its input shows that
*once you allow H to not be required to be correct*,
that we can then have a trivial function that is
"just as correct" (since wrong answers were allowed).
On 5/1/2024 7:28 PM, Richard Damon wrote:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv0ummt%242qov3%242%40i2pn2.org%3E
On 5/19/2024 7:16 AM, immibis wrote:
On 19/05/24 05:59, 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.
(b) Computable functions cannot alter their behavior this way.
(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
Your function H works like Richard's function H. You just called the
variable "execution trace" instead of "flag".
pages 4-5 (of a paper that I published 2021-09-26 09:39 AM)
Show H simulating P and H simulating itself simulating P.
The 395 pages of the execution trace of the simulated H are
screened out. No one here could ever understand the half page
trace so embedding that in 395 more pages would not help.
That P is simulated correctly is proven by the fact that the
x86 assembly language instructions of P are correctly simulated
and they are simulated in the order that the assembly language
of P specifies.
On 5/19/2024 11:37 PM, immibis wrote:
On 19/05/24 15:06, olcott wrote:
Show H simulating P and H simulating itself simulating P.
The 395 pages of the execution trace of the simulated H are
screened out. No one here could ever understand the half page
trace so embedding that in 395 more pages would not help.
The fact that you took 395 pages to get to "if(flag) return 0;" does
not mean that you didn't use "if(flag) return 0;"
That P is simulated correctly is proven by the fact that the
x86 assembly language instructions of P are correctly simulated
and they are simulated in the order that the assembly language
of P specifies.
This is a lie -> If every assembly instruction that was simulated is
simulated correctly, the program was simulated correctly. <- This is a
lie.
*Quoted from page 4 of the paper linked below*
On 5/19/2024 7:16 AM, immibis wrote:
On 19/05/24 05:59, 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.
(b) Computable functions cannot alter their behavior this way.
(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
Your function H works like Richard's function H. You just called the
variable "execution trace" instead of "flag".
Since Richard did not respond to this post I am taking that
as he understands that he is incorrect.
He has known this whole time that we having only been talking
about computable functions. Thus he knows his example using
static data is no good.
On 5/19/2024 11:37 PM, immibis wrote:
On 19/05/24 15:06, olcott wrote:
On 5/19/2024 7:16 AM, immibis wrote:
On 19/05/24 05:59, 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
Line 03: Calls H (line 14)
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 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.
(b) Computable functions cannot alter their behavior this way.
(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
Your function H works like Richard's function H. You just called the
variable "execution trace" instead of "flag".
pages 4-5 (of a paper that I published 2021-09-26 09:39 AM)
Show H simulating P and H simulating itself simulating P.
The 395 pages of the execution trace of the simulated H are
screened out. No one here could ever understand the half page
trace so embedding that in 395 more pages would not help.
The fact that you took 395 pages to get to "if(flag) return 0;" does
not mean that you didn't use "if(flag) return 0;"
That P is simulated correctly is proven by the fact that the
x86 assembly language instructions of P are correctly simulated
and they are simulated in the order that the assembly language
of P specifies.
This is a lie -> If every assembly instruction that was simulated is
simulated correctly, the program was simulated correctly. <- This is a
lie.
*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
On 5/20/2024 3:37 AM, immibis wrote:
On 20/05/24 07:17, olcott wrote:
On 5/19/2024 11:37 PM, immibis wrote:
On 19/05/24 15:06, olcott wrote:
Show H simulating P and H simulating itself simulating P.
The 395 pages of the execution trace of the simulated H are
screened out. No one here could ever understand the half page
trace so embedding that in 395 more pages would not help.
The fact that you took 395 pages to get to "if(flag) return 0;" does
not mean that you didn't use "if(flag) return 0;"
The fact that every instruction of D is correctly emulated in the
order of the the assembly language that D specifies both before D
calls H(D,D) and then after H(D,D) correctly simulates D(D) all
over again conclusively proves recursive simulation without the
need for the additional 395 pages mixed in.
The tricky part of this was giving each simulated D its own
separate process with its own memory registers and stack.
That P is simulated correctly is proven by the fact that the
x86 assembly language instructions of P are correctly simulated
and they are simulated in the order that the assembly language
of P specifies.
This is a lie -> If every assembly instruction that was simulated is
simulated correctly, the program was simulated correctly. <- This is
a lie.
*Quoted from page 4 of the paper linked below*
Notice that none of what you wrote had any relationship to anything
that I wrote.
I am using categorically exhaustive reasoning that can work
through every possibility that can possibly exist in a feasible
amount of time as long as the category is very very narrow.
Enlarge the category a tiny little bit and then the time
becomes infeasible.
The tiniest little divergence from the title of this
thread and I totally ignore and erase everything else
that you say.
*This boiler plate will be the only reply*
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 498 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 09:17:08 |
| Calls: | 9,822 |
| Calls today: | 1 |
| Files: | 13,757 |
| Messages: | 6,190,747 |