On 5/8/2024 10:13 AM, Mike Terry wrote:
On 08/05/2024 14:01, olcott wrote:
On 5/8/2024 3:59 AM, Mikko wrote:
On 2024-05-07 19:05:54 +0000, olcott said:
On 5/7/2024 1:54 PM, Fred. Zwarts wrote:
Op 07.mei.2024 om 17:40 schreef olcott:
On 5/7/2024 6:18 AM, Richard Damon wrote:
On 5/7/24 3:30 AM, Mikko wrote:
On 2024-05-06 18:28:37 +0000, olcott said:
On 5/6/2024 11:19 AM, Mikko wrote:
On 2024-05-05 17:02:25 +0000, olcott said:
The x86utm operating system:
https://github.com/plolcott/x86utm enables
one C function to execute another C function in debug step >>>>>>>>>>>> mode.
Simulating Termination analyzer H simulates the x86 machine >>>>>>>>>>>> code of its
input (using libx86emu) in debug step mode until it
correctly matches a
correct non-halting behavior pattern proving that its input >>>>>>>>>>>> will never
stop running unless aborted.
Can D correctly simulated by H terminate normally?
00 int H(ptr x, ptr x) // ptr is pointer to int function >>>>>>>>>>>> 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 }
*Execution Trace*
Line 11: main() invokes H(D,D);
*keeps repeating* (unless aborted)
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 above execution trace proves that (for every H/D pair of >>>>>>>>>>>> the
infinite set of H/D pairs) each D(D) simulated by the H that >>>>>>>>>>>> this D(D)
calls cannot possibly reach past its own line 03.
When you say "every H/D pair" you should specify which set of >>>>>>>>>>> pairs
you are talking about. As you don't, your words don't mean >>>>>>>>>>> anything.
Every H/D pair in the universe where D(D) is simulated by the >>>>>>>>>> same H(D,D) that D(D) calls. This involves 1 to ∞ steps of D >>>>>>>>>> and also includes zero to ∞ recursive simulations where H >>>>>>>>>> H simulates itself simulating D(D).
"In the universe" is not a set. In typical set theories like >>>>>>>>> ZFC there
is no universal set.
This template defines an infinite set of finite string H/D pairs >>>>>>> where each D(D) that is simulated by H(D,D) also calls this same >>>>>>> H(D,D).
These H/D pairs can be enumerated by the one to ∞ simulated steps >>>>>>> of D and involve zero to ∞ recursive simulations of H simulating >>>>>>> itself simulating D(D). Every time Lines 1,2,3 are simulated
again defines
one more level of recursive simulation.
1st element of H/D pairs 1 step of D is simulated by H
2nd element of H/D pairs 2 steps of D are simulated by H
3rd element of H/D pairs 3 steps of D are simulated by H
4th element of H/D pairs 4 steps of D are simulated by H
this begins the first recursive simulation at line 01
5th element of H/D pairs 5 steps of D are simulated by
next step of the first recursive simulation at line 02
6th element of H/D pairs 6 steps of D are simulated by
last step of the first recursive simulation at line 03
7th element of H/D pairs 7 steps of D are simulated by H
this begins the second recursive simulation at line 01
Is this the definition of the infinite set of H? We can think of
many more simulations that only these.
This template defines an infinite set of finite string H/D pairs where >>>>> each D(D) that is simulated by H(D,D) also calls this same H(D,D).
No-one can possibly show one element of this set where D(D) reaches
past its own line 03.
If H is a decider of any kind then the D build from it reaches its line >>>> 4 as numberd above. Whether the simulation of D by H reaches that line >>>> is another question.
*My fully operational code proves otherwise*
I seems like you guys don't have a clue about how infinite
recursion works. You can run the code and see that I am correct.
I have one concrete instance as fully operational code.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
line 555 u32 HH(ptr P, ptr I) its input in on
line 932 int DD(int (*x)())
HH is completely broken - it uses a global variable which is allows HH
to detect whether it is the outer HH or a nested (simulated) HH. As a
result, the nested HH behaves completely differently to the outer HH -
I mean /completely/ differently: it goes through a totally separate "I
am called in nested mode" code path!
The encoding of HH is not the pure function that it needs to be to
be a computable function.
*Maybe you can settle this*
The disagreement is entirely over an enormously much simpler thing.
The disagreement is that Richard says that a D simulated by H could
reach past its own line 03 and halt.
On 5/8/2024 10:13 AM, Mike Terry wrote:
On 08/05/2024 14:01, olcott wrote:
On 5/8/2024 3:59 AM, Mikko wrote:
On 2024-05-07 19:05:54 +0000, olcott said:
On 5/7/2024 1:54 PM, Fred. Zwarts wrote:
Op 07.mei.2024 om 17:40 schreef olcott:
On 5/7/2024 6:18 AM, Richard Damon wrote:
On 5/7/24 3:30 AM, Mikko wrote:
On 2024-05-06 18:28:37 +0000, olcott said:
On 5/6/2024 11:19 AM, Mikko wrote:
On 2024-05-05 17:02:25 +0000, olcott said:
The x86utm operating system: https://github.com/plolcott/x86utm enables
one C function to execute another C function in debug step mode. >>>>>>>>>>>> Simulating Termination analyzer H simulates the x86 machine code of its
input (using libx86emu) in debug step mode until it correctly matches a
correct non-halting behavior pattern proving that its input will never
stop running unless aborted.
Can D correctly simulated by H terminate normally?
00 int H(ptr x, ptr x) // ptr is pointer to int function >>>>>>>>>>>> 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 }
*Execution Trace*
Line 11: main() invokes H(D,D);
*keeps repeating* (unless aborted)
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 above execution trace proves that (for every H/D pair of the >>>>>>>>>>>> infinite set of H/D pairs) each D(D) simulated by the H that this D(D)
calls cannot possibly reach past its own line 03.
When you say "every H/D pair" you should specify which set of pairs >>>>>>>>>>> you are talking about. As you don't, your words don't mean anything.
Every H/D pair in the universe where D(D) is simulated by the >>>>>>>>>> same H(D,D) that D(D) calls. This involves 1 to ∞ steps of D >>>>>>>>>> and also includes zero to ∞ recursive simulations where H >>>>>>>>>> H simulates itself simulating D(D).
"In the universe" is not a set. In typical set theories like ZFC there
is no universal set.
This template defines an infinite set of finite string H/D pairs where each D(D) that is
simulated by H(D,D) also calls this same H(D,D).
These H/D pairs can be enumerated by the one to ∞ simulated steps of D and involve zero to ∞
recursive simulations of H simulating itself simulating D(D). Every time Lines 1,2,3 are
simulated again defines
one more level of recursive simulation.
1st element of H/D pairs 1 step of D is simulated by H
2nd element of H/D pairs 2 steps of D are simulated by H
3rd element of H/D pairs 3 steps of D are simulated by H
4th element of H/D pairs 4 steps of D are simulated by H
this begins the first recursive simulation at line 01
5th element of H/D pairs 5 steps of D are simulated by
next step of the first recursive simulation at line 02
6th element of H/D pairs 6 steps of D are simulated by
last step of the first recursive simulation at line 03
7th element of H/D pairs 7 steps of D are simulated by H
this begins the second recursive simulation at line 01
Is this the definition of the infinite set of H? We can think of many more simulations that
only these.
This template defines an infinite set of finite string H/D pairs where >>>>> each D(D) that is simulated by H(D,D) also calls this same H(D,D).
No-one can possibly show one element of this set where D(D) reaches
past its own line 03.
If H is a decider of any kind then the D build from it reaches its line >>>> 4 as numberd above. Whether the simulation of D by H reaches that line >>>> is another question.
*My fully operational code proves otherwise*
I seems like you guys don't have a clue about how infinite
recursion works. You can run the code and see that I am correct.
I have one concrete instance as fully operational code.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
line 555 u32 HH(ptr P, ptr I) its input in on
line 932 int DD(int (*x)())
HH is completely broken - it uses a global variable which is allows HH to detect whether it is the
outer HH or a nested (simulated) HH. As a result, the nested HH behaves completely differently to
the outer HH - I mean /completely/ differently: it goes through a totally separate "I am called in
nested mode" code path!
The encoding of HH is not the pure function that it needs to be to
be a computable function.
*Maybe you can settle this*
The disagreement is entirely over an enormously much simpler thing.
The disagreement is that Richard says that a D simulated by H could
reach past its own line 03 and halt.
*He used this example to prove that*
On 5/1/2024 7:28 PM, Richard Damon wrote:
int H(ptr m, ptr d) {
return 0;
}
*Any "simulator" that never simulates is not a simulator at all*
*Any "simulator" that never simulates is not a simulator at all*
*Any "simulator" that never simulates is not a simulator at all*
*Any "simulator" that never simulates is not a simulator at all*
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
Any H/D pair matching the above template where D(D) is simulated
by the same H(D,D) that it calls cannot possibly reach past
it own line 03. Simple software engineering verified fact.
Richard keeps saying that he posted proof otherwise and
absolutely will not provide this "proof".
You agreed this a few weeks ago. Or have you fixed this code now? I bet you haven't.
That you proved it can be fixed on the basis that a simulator can
examine every detail of its simulated input's internal state seems
to prove that it can be fixed.
This is good enough for my current state of physical health.
I can't drop everything and take six months to make this fix
before proving my point.
We are only talking about a simple hypothetical that four
experts in C (two of them with master's in CS) already agreed to.
Richard just doesn't seem able to tell the truth about this.
Until you fix the code you should not be referring to it as "fully operational" code, because it
is simply WRONG and so does not demonstrate anything at all.
Regards,
Mike.
I'll respond with my assessment on this, provided you agree in advance
that you won't quote me elsewhere [in other threads/forums] in support
of your claims. Not that I can really enforce this, but I think for the
most part you are basically honest, and would try to keep an agreement
you made on this, if you chose to make one.
You understand the reason I ask this: you are unfortunately completely unable to judge what other people say to you, and as soon as you (mis)interpret the smallest thing as supporting some part of your
argument you will (mis)quote "Mike Terry [or whoever] agrees that
[something I did not agree to, or some literal quote taken out of
context, which misrepresents my actual opinion]."
If I persuade you of anything, of course you can present those views /as
your own words/, but none of that "Mike Terry said..." or "an expert
(lol) has agreed that..." and so on. Those are attempts to silence opposition through (mistaken) appeals to authority and I don't want to
be involved in that.
Of course you can quote me freely within this thread where it will be in context :)
Mike.
Am Thu, 09 May 2024 04:05:14 +0100 schrieb Mike Terry:
I'll respond with my assessment on this, provided you agree in advance
that you won't quote me elsewhere [in other threads/forums] in support
of your claims. Not that I can really enforce this, but I think for the
most part you are basically honest, and would try to keep an agreement
you made on this, if you chose to make one.
You understand the reason I ask this: you are unfortunately completely
unable to judge what other people say to you, and as soon as you
(mis)interpret the smallest thing as supporting some part of your
argument you will (mis)quote "Mike Terry [or whoever] agrees that
[something I did not agree to, or some literal quote taken out of
context, which misrepresents my actual opinion]."
If I persuade you of anything, of course you can present those views /as
your own words/, but none of that "Mike Terry said..." or "an expert
(lol) has agreed that..." and so on. Those are attempts to silence
opposition through (mistaken) appeals to authority and I don't want to
be involved in that.
Of course you can quote me freely within this thread where it will be in
context :)
Mike.
Hello Mike, are you one of the experts Olcott quotes? I would be
interested in what your original concession regarding the code was.
Have a nice day
On 5/8/2024 10:05 PM, Mike Terry wrote:
On 08/05/2024 20:05, olcott wrote:
On 5/8/2024 10:13 AM, Mike Terry wrote:
On 08/05/2024 14:01, olcott wrote:
On 5/8/2024 3:59 AM, Mikko wrote:
On 2024-05-07 19:05:54 +0000, olcott said:
On 5/7/2024 1:54 PM, Fred. Zwarts wrote:
Op 07.mei.2024 om 17:40 schreef olcott:
On 5/7/2024 6:18 AM, Richard Damon wrote:
On 5/7/24 3:30 AM, Mikko wrote:
On 2024-05-06 18:28:37 +0000, olcott said:
On 5/6/2024 11:19 AM, Mikko wrote:
On 2024-05-05 17:02:25 +0000, olcott said:
The x86utm operating system: https://github.com/plolcott/x86utm enables
one C function to execute another C function in debug step mode. >>>>>>>>>>>>>> Simulating Termination analyzer H simulates the x86 machine code of its
input (using libx86emu) in debug step mode until it correctly matches a
correct non-halting behavior pattern proving that its input will never
stop running unless aborted.
Can D correctly simulated by H terminate normally? >>>>>>>>>>>>>> 00 int H(ptr x, ptr x) // ptr is pointer to int function >>>>>>>>>>>>>> 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 }
*Execution Trace*
Line 11: main() invokes H(D,D);
*keeps repeating* (unless aborted)
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 above execution trace proves that (for every H/D pair of the >>>>>>>>>>>>>> infinite set of H/D pairs) each D(D) simulated by the H that this D(D)
calls cannot possibly reach past its own line 03.
When you say "every H/D pair" you should specify which set of pairs
you are talking about. As you don't, your words don't mean anything.
Every H/D pair in the universe where D(D) is simulated by the >>>>>>>>>>>> same H(D,D) that D(D) calls. This involves 1 to ∞ steps of D >>>>>>>>>>>> and also includes zero to ∞ recursive simulations where H >>>>>>>>>>>> H simulates itself simulating D(D).
"In the universe" is not a set. In typical set theories like ZFC there
is no universal set.
This template defines an infinite set of finite string H/D pairs where each D(D) that is
simulated by H(D,D) also calls this same H(D,D).
These H/D pairs can be enumerated by the one to ∞ simulated steps of D and involve zero to
∞ recursive simulations of H simulating itself simulating D(D). Every time Lines 1,2,3 are
simulated again defines
one more level of recursive simulation.
1st element of H/D pairs 1 step of D is simulated by H
2nd element of H/D pairs 2 steps of D are simulated by H
3rd element of H/D pairs 3 steps of D are simulated by H
4th element of H/D pairs 4 steps of D are simulated by H
this begins the first recursive simulation at line 01
5th element of H/D pairs 5 steps of D are simulated by
next step of the first recursive simulation at line 02
6th element of H/D pairs 6 steps of D are simulated by
last step of the first recursive simulation at line 03
7th element of H/D pairs 7 steps of D are simulated by H
this begins the second recursive simulation at line 01
Is this the definition of the infinite set of H? We can think of many more simulations that
only these.
This template defines an infinite set of finite string H/D pairs where >>>>>>> each D(D) that is simulated by H(D,D) also calls this same H(D,D). >>>>>>>
No-one can possibly show one element of this set where D(D) reaches >>>>>>> past its own line 03.
If H is a decider of any kind then the D build from it reaches its line >>>>>> 4 as numberd above. Whether the simulation of D by H reaches that line >>>>>> is another question.
*My fully operational code proves otherwise*
I seems like you guys don't have a clue about how infinite
recursion works. You can run the code and see that I am correct.
I have one concrete instance as fully operational code.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
line 555 u32 HH(ptr P, ptr I) its input in on
line 932 int DD(int (*x)())
HH is completely broken - it uses a global variable which is allows HH to detect whether it is
the outer HH or a nested (simulated) HH. As a result, the nested HH behaves completely
differently to the outer HH - I mean /completely/ differently: it goes through a totally
separate "I am called in nested mode" code path!
The encoding of HH is not the pure function that it needs to be to
be a computable function.
*Maybe you can settle this*
The disagreement is entirely over an enormously much simpler thing.
The disagreement is that Richard says that a D simulated by H could
reach past its own line 03 and halt.
I'll respond with my assessment on this, provided you agree in advance that you won't quote me
elsewhere [in other threads/forums] in support of your claims. Not that I can really enforce
this, but I think for the most part you are basically honest, and would try to keep an agreement
you made on this, if you chose to make one.
That is really great Mike, you have been a wonderful help.
I will agree not to quote you anywhere else but these two
forums and I am nearly certain that I never quoted anyone
else from these forums anywhere else besides these forums.
You understand the reason I ask this: you are unfortunately completely unable to judge what other
people say to you, and as soon as you (mis)interpret the smallest thing as supporting some part of
your argument you will (mis)quote "Mike Terry [or whoever] agrees that [something I did not agree
to, or some literal quote taken out of context, which misrepresents my actual opinion]."
OK, so I agree that I will only quote you using the message ID
of your reply with its time/date stamp and I will only quote
you in these forums.
On 5/8/2024 8:38 PM, immibis wrote:
On 8/05/24 21:05, olcott wrote:
On 5/8/2024 10:13 AM, Mike Terry wrote:
On 08/05/2024 14:01, olcott wrote:
On 5/8/2024 3:59 AM, Mikko wrote:
On 2024-05-07 19:05:54 +0000, olcott said:
On 5/7/2024 1:54 PM, Fred. Zwarts wrote:
Op 07.mei.2024 om 17:40 schreef olcott:
On 5/7/2024 6:18 AM, Richard Damon wrote:
On 5/7/24 3:30 AM, Mikko wrote:
On 2024-05-06 18:28:37 +0000, olcott said:
On 5/6/2024 11:19 AM, Mikko wrote:
On 2024-05-05 17:02:25 +0000, olcott said:
The x86utm operating system:
https://github.com/plolcott/x86utm enables
one C function to execute another C function in debug step >>>>>>>>>>>>>> mode.
Simulating Termination analyzer H simulates the x86 >>>>>>>>>>>>>> machine code of its
input (using libx86emu) in debug step mode until it >>>>>>>>>>>>>> correctly matches a
correct non-halting behavior pattern proving that its >>>>>>>>>>>>>> input will never
stop running unless aborted.
Can D correctly simulated by H terminate normally? >>>>>>>>>>>>>> 00 int H(ptr x, ptr x) // ptr is pointer to int function >>>>>>>>>>>>>> 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 }
*Execution Trace*
Line 11: main() invokes H(D,D);
*keeps repeating* (unless aborted)
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 above execution trace proves that (for every H/D pair >>>>>>>>>>>>>> of the
infinite set of H/D pairs) each D(D) simulated by the H >>>>>>>>>>>>>> that this D(D)
calls cannot possibly reach past its own line 03.
When you say "every H/D pair" you should specify which set >>>>>>>>>>>>> of pairs
you are talking about. As you don't, your words don't mean >>>>>>>>>>>>> anything.
Every H/D pair in the universe where D(D) is simulated by the >>>>>>>>>>>> same H(D,D) that D(D) calls. This involves 1 to ∞ steps of D >>>>>>>>>>>> and also includes zero to ∞ recursive simulations where H >>>>>>>>>>>> H simulates itself simulating D(D).
"In the universe" is not a set. In typical set theories like >>>>>>>>>>> ZFC there
is no universal set.
This template defines an infinite set of finite string H/D
pairs where each D(D) that is simulated by H(D,D) also calls >>>>>>>>> this same H(D,D).
These H/D pairs can be enumerated by the one to ∞ simulated >>>>>>>>> steps of D and involve zero to ∞ recursive simulations of H >>>>>>>>> simulating itself simulating D(D). Every time Lines 1,2,3 are >>>>>>>>> simulated again defines
one more level of recursive simulation.
1st element of H/D pairs 1 step of D is simulated by H
2nd element of H/D pairs 2 steps of D are simulated by H
3rd element of H/D pairs 3 steps of D are simulated by H
4th element of H/D pairs 4 steps of D are simulated by H
this begins the first recursive simulation at line 01
5th element of H/D pairs 5 steps of D are simulated by
next step of the first recursive simulation at line 02
6th element of H/D pairs 6 steps of D are simulated by
last step of the first recursive simulation at line 03
7th element of H/D pairs 7 steps of D are simulated by H
this begins the second recursive simulation at line 01
Is this the definition of the infinite set of H? We can think of >>>>>>>> many more simulations that only these.
This template defines an infinite set of finite string H/D pairs >>>>>>> where
each D(D) that is simulated by H(D,D) also calls this same H(D,D). >>>>>>>
No-one can possibly show one element of this set where D(D) reaches >>>>>>> past its own line 03.
If H is a decider of any kind then the D build from it reaches its >>>>>> line
4 as numberd above. Whether the simulation of D by H reaches that
line
is another question.
*My fully operational code proves otherwise*
I seems like you guys don't have a clue about how infinite
recursion works. You can run the code and see that I am correct.
I have one concrete instance as fully operational code.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
line 555 u32 HH(ptr P, ptr I) its input in on
line 932 int DD(int (*x)())
HH is completely broken - it uses a global variable which is allows
HH to detect whether it is the outer HH or a nested (simulated) HH.
As a result, the nested HH behaves completely differently to the
outer HH - I mean /completely/ differently: it goes through a
totally separate "I am called in nested mode" code path!
The encoding of HH is not the pure function that it needs to be to
be a computable function.
*Maybe you can settle this*
The disagreement is entirely over an enormously much simpler thing.
The disagreement is that Richard says that a D simulated by H could
reach past its own line 03 and halt.
Here's the proof:
1. A simulation always produces an identical execution trace to the
direct execution.
*When pathological self-reference is involved this is counter-factual*
That no one can possibly show the steps of how D simulated by H possibly reach line 06 of H proves this.
Richard tried to get away with D never simulated by H as an example
of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the detailed*
*steps of how I am wrong indicates that they are probably liars*
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
Any H/D pair matching the above template where D(D) is simulated
by the same H(D,D) that it calls cannot possibly reach past its own
line 03. Simple software engineering verified fact.
On 5/9/2024 6:43 PM, Mike Terry wrote:
On 09/05/2024 04:46, olcott wrote:
On 5/8/2024 10:05 PM, Mike Terry wrote:
On 08/05/2024 20:05, olcott wrote:
On 5/8/2024 10:13 AM, Mike Terry wrote:
On 08/05/2024 14:01, olcott wrote:
On 5/8/2024 3:59 AM, Mikko wrote:
On 2024-05-07 19:05:54 +0000, olcott said:
On 5/7/2024 1:54 PM, Fred. Zwarts wrote:
Op 07.mei.2024 om 17:40 schreef olcott:
On 5/7/2024 6:18 AM, Richard Damon wrote:
On 5/7/24 3:30 AM, Mikko wrote:
On 2024-05-06 18:28:37 +0000, olcott said:
On 5/6/2024 11:19 AM, Mikko wrote:
On 2024-05-05 17:02:25 +0000, olcott said:
The x86utm operating system: https://github.com/plolcott/x86utm enablesWhen you say "every H/D pair" you should specify which set of pairs
one C function to execute another C function in debug step mode.
Simulating Termination analyzer H simulates the x86 machine code of its
input (using libx86emu) in debug step mode until it correctly matches a
correct non-halting behavior pattern proving that its input will never
stop running unless aborted.
Can D correctly simulated by H terminate normally? >>>>>>>>>>>>>>>> 00 int H(ptr x, ptr x) // ptr is pointer to int function >>>>>>>>>>>>>>>> 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 }
*Execution Trace*
Line 11: main() invokes H(D,D);
*keeps repeating* (unless aborted)
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 above execution trace proves that (for every H/D pair of the
infinite set of H/D pairs) each D(D) simulated by the H that this D(D)
calls cannot possibly reach past its own line 03. >>>>>>>>>>>>>>>
you are talking about. As you don't, your words don't mean anything.
Every H/D pair in the universe where D(D) is simulated by the >>>>>>>>>>>>>> same H(D,D) that D(D) calls. This involves 1 to ∞ steps of D >>>>>>>>>>>>>> and also includes zero to ∞ recursive simulations where H >>>>>>>>>>>>>> H simulates itself simulating D(D).
"In the universe" is not a set. In typical set theories like ZFC there
is no universal set.
This template defines an infinite set of finite string H/D pairs where each D(D) that is
simulated by H(D,D) also calls this same H(D,D).
These H/D pairs can be enumerated by the one to ∞ simulated steps of D and involve zero
to ∞ recursive simulations of H simulating itself simulating D(D). Every time Lines 1,2,3
are simulated again defines
one more level of recursive simulation.
1st element of H/D pairs 1 step of D is simulated by H >>>>>>>>>>> 2nd element of H/D pairs 2 steps of D are simulated by H >>>>>>>>>>> 3rd element of H/D pairs 3 steps of D are simulated by H >>>>>>>>>>>
4th element of H/D pairs 4 steps of D are simulated by H >>>>>>>>>>> this begins the first recursive simulation at line 01
5th element of H/D pairs 5 steps of D are simulated by
next step of the first recursive simulation at line 02
6th element of H/D pairs 6 steps of D are simulated by
last step of the first recursive simulation at line 03
7th element of H/D pairs 7 steps of D are simulated by H >>>>>>>>>>> this begins the second recursive simulation at line 01
Is this the definition of the infinite set of H? We can think of many more simulations
that only these.
This template defines an infinite set of finite string H/D pairs where
each D(D) that is simulated by H(D,D) also calls this same H(D,D). >>>>>>>>>
No-one can possibly show one element of this set where D(D) reaches >>>>>>>>> past its own line 03.
If H is a decider of any kind then the D build from it reaches its line
4 as numberd above. Whether the simulation of D by H reaches that line >>>>>>>> is another question.
*My fully operational code proves otherwise*
I seems like you guys don't have a clue about how infinite
recursion works. You can run the code and see that I am correct. >>>>>>>
I have one concrete instance as fully operational code.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
line 555 u32 HH(ptr P, ptr I) its input in on
line 932 int DD(int (*x)())
HH is completely broken - it uses a global variable which is allows HH to detect whether it is
the outer HH or a nested (simulated) HH. As a result, the nested HH behaves completely
differently to the outer HH - I mean /completely/ differently: it goes through a totally
separate "I am called in nested mode" code path!
The encoding of HH is not the pure function that it needs to be to
be a computable function.
*Maybe you can settle this*
The disagreement is entirely over an enormously much simpler thing.
The disagreement is that Richard says that a D simulated by H could
reach past its own line 03 and halt.
I'll respond with my assessment on this, provided you agree in advance that you won't quote me
elsewhere [in other threads/forums] in support of your claims. Not that I can really enforce
..NOTE: not in other THREADS or forums, i.e. NOT in other threads on these newsgroups. (Just in
this specific thread, where what I say will be quoted automatically by your newsreader! I can't
see why you would quote me in other threads anyway other than in some kind of attempt to shut down
discussion in your favour...)
this, but I think for the most part you are basically honest, and would try to keep an agreement
you made on this, if you chose to make one.
That is really great Mike, you have been a wonderful help.
I will agree not to quote you anywhere else but these two
forums and I am nearly certain that I never quoted anyone
else from these forums anywhere else besides these forums.
You understand the reason I ask this: you are unfortunately completely unable to judge what
other people say to you, and as soon as you (mis)interpret the smallest thing as supporting some
part of your argument you will (mis)quote "Mike Terry [or whoever] agrees that [something I did
not agree to, or some literal quote taken out of context, which misrepresents my actual opinion]."
OK, so I agree that I will only quote you using the message ID
of your reply with its time/date stamp and I will only quote
you in these forums.
My condition is "only in THIS THREAD"...
Mike.
So I cannot post the entire dialogue of everything you
said along with a time/date stamp of your full reply
and its message ID in a different thread in this forum?
My issue is that too many people in this forum insist
on directly contradicting the easily verified facts
AND THEN CALL ME A LIAR BOUT THIS SAME ISSUE!!!
I will find what you said about the computability issue
in a few minutes so that you can attest to or rebuke my
range of interpretations of this issue.
I just had hail damage, a refrigerator that quit the night
before surgery, surgery and one other huge issue in the last
few days. I want have an opportunity to retract any inaccurate characterizations of what you said.
There are so few people here that are honest so I must
treat them as very special.
*I will abide by your wish and not post any*
*copy of your reply outside of this thread*
I really need someone to shut down the liars about this specific
point so I can move on to the next point and complete an actual
honest review of my work before my pod24 diagnosis kills me.
*Validation of POD24 as a robust early clinical end point of*
*poor survival in FL from 5225 patients on 13 clinical trials* https://pubmed.ncbi.nlm.nih.gov/34614146/
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
Any H/D pair matching the above template where D(D) is simulated
by the same H(D,D) that it calls cannot possibly reach past its own
line 03. Simple software engineering verified fact.
Richard tried to get away with D never simulated by H as an example
of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the detailed*
*steps of how I am wrong indicates that they are probably liars*
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
Any H/D pair matching the above template where D(D) is simulated
by the same H(D,D) that it calls cannot possibly reach past its own
line 03. Simple software engineering verified fact.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 5/10/2024 12:55 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It is clear
you have never built or run this code, which ironically can't reach Line
06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an example
of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the detailed*
*steps of how I am wrong indicates that they are probably liars*
You have said, or at least implied that your code fragment is runnable.
I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
I removed the line numbers from your code, added in a "pointer to int
function" type (you should really learn how to do this yourself) and ran
the result on GCC.
This is the file I submitted:
typedef int (* ptr) (void);
int H(ptr x, ptr x) // ptr is pointer to int function
int D(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
H(D,D);
}
. These are the diagnostics generated by GCC:
olcott.c:2:18: error: redefinition of parameter ‘x’
2 | int H(ptr x, ptr x) // ptr is pointer to int function
| ~~~~^
olcott.c:2:11: note: previous definition of ‘x’ with type ‘ptr’ {aka ‘int
(*)(void)’}
2 | int H(ptr x, ptr x) // ptr is pointer to int function
| ~~~~^
olcott.c: In function ‘H’:
olcott.c:4:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘{’ token
4 | {
| ^
olcott.c:12:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘{’ token
12 | {
| ^
olcott.c:15: error: expected ‘{’ at end of input
Any H/D pair matching the above template where D(D) is simulated
by the same H(D,D) that it calls cannot possibly reach past its own
line 03. Simple software engineering verified fact.
The code for D is so full of errors that it cannot demonstrate anything,
beyond a lack of proficiency in C in its author.
*I have fully operational code, yet this is*
*not the code that the words below refer to*
There is no actual error in these lines of code.
int main()
{
H(D,D);
return 0;
}
I had to change the wording for people that intentionally
try as hard as possible to make sure to interpret my words
incorrectly.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
Any H/D pair matching the above template where D(D) is simulated
by the same H(D,D) that it calls cannot possibly reach past its own
line 03. Simple software engineering verified fact.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 5/10/2024 1:38 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 5/10/2024 12:55 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It is clear >>>> you have never built or run this code, which ironically can't reach
Line
06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an example
of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the detailed* >>>>> *steps of how I am wrong indicates that they are probably liars*
You have said, or at least implied that your code fragment is runnable. >>>> I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
I removed the line numbers from your code, added in a "pointer to int
function" type (you should really learn how to do this yourself) and
ran
the result on GCC.
This is the file I submitted:
typedef int (* ptr) (void);
int H(ptr x, ptr x) // ptr is pointer to int function
int D(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
H(D,D);
}
. These are the diagnostics generated by GCC:
olcott.c:2:18: error: redefinition of parameter ‘x’
2 | int H(ptr x, ptr x) // ptr is pointer to int function >>>> | ~~~~^
olcott.c:2:11: note: previous definition of ‘x’ with type ‘ptr’ {aka
‘int
(*)(void)’}
2 | int H(ptr x, ptr x) // ptr is pointer to int function >>>> | ~~~~^
olcott.c: In function ‘H’:
olcott.c:4:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘{’ token
4 | {
| ^
olcott.c:12:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘{’ token
12 | {
| ^
olcott.c:15: error: expected ‘{’ at end of input
Any H/D pair matching the above template where D(D) is simulated
by the same H(D,D) that it calls cannot possibly reach past its own
line 03. Simple software engineering verified fact.
The code for D is so full of errors that it cannot demonstrate
anything,
beyond a lack of proficiency in C in its author.
*I have fully operational code, yet this is*
*not the code that the words below refer to*
Why, then, have you been spamming the group with faulty code for so long?
Why did you not first check it and correct it before posting it?
When I brought up the issue before, you "answered", in
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory,sci.logic
Subject: Re: D simulated by H never halts no matter what H does V3
Date: Sat, 4 May 2024 10:47:00 -0500
, that
There is no actual error in these lines of code.
int main()
{
H(D,D);
return 0;
}
. Why did you answer so evasively? Why did you not admit then that the >> code was faulty, and thank me for pointing it out?
I had to change the wording for people that intentionally
try as hard as possible to make sure to interpret my words
incorrectly.
There are no such people on this newsgroup. Most people here try to
answer your posts directly and honestly. You are the poster who attempts >> to mislead, obfuscate, and evade.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
Any H/D pair matching the above template where D(D) is simulated
by the same H(D,D) that it calls cannot possibly reach past its own
line 03. Simple software engineering verified fact.
Why are you doing this again? Simple software engineering shows that the >> above code is so broken as to be unusable. Why don't you correct it
first before posting it yet again?
*above template ---not code, code template*
*I said it was a code template*
*You knew it was a code template and pretend to not know*
*isomorphic to this code template*
rec routine P
§L :if T[P] goto L
Return §
*An impossible program*
C. Strachey
The Computer Journal, Volume 7, Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
Published: 01 January 1965 https://academic.oup.com/comjnl/article/7/4/313/354243
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 5/10/2024 1:38 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 5/10/2024 12:55 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It is clear >>>> you have never built or run this code, which ironically can't reach Line >>>> 06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an example
of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the detailed* >>>>> *steps of how I am wrong indicates that they are probably liars*
You have said, or at least implied that your code fragment is runnable. >>>> I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
I removed the line numbers from your code, added in a "pointer to int
function" type (you should really learn how to do this yourself) and ran >>>> the result on GCC.
This is the file I submitted:
typedef int (* ptr) (void);
int H(ptr x, ptr x) // ptr is pointer to int function
int D(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
H(D,D);
}
. These are the diagnostics generated by GCC:
olcott.c:2:18: error: redefinition of parameter ‘x’
2 | int H(ptr x, ptr x) // ptr is pointer to int function
| ~~~~^
olcott.c:2:11: note: previous definition of ‘x’ with type ‘ptr’ {aka ‘int
(*)(void)’}
2 | int H(ptr x, ptr x) // ptr is pointer to int function
| ~~~~^
olcott.c: In function ‘H’:
olcott.c:4:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘{’ token
4 | {
| ^
olcott.c:12:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘{’ token
12 | {
| ^
olcott.c:15: error: expected ‘{’ at end of input
Any H/D pair matching the above template where D(D) is simulated
by the same H(D,D) that it calls cannot possibly reach past its own
line 03. Simple software engineering verified fact.
The code for D is so full of errors that it cannot demonstrate anything, >>>> beyond a lack of proficiency in C in its author.
*I have fully operational code, yet this is*
*not the code that the words below refer to*
Why, then, have you been spamming the group with faulty code for so long?
Why did you not first check it and correct it before posting it?
When I brought up the issue before, you "answered", in
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory,sci.logic
Subject: Re: D simulated by H never halts no matter what H does V3
Date: Sat, 4 May 2024 10:47:00 -0500
, that
There is no actual error in these lines of code.
int main()
{
H(D,D);
return 0;
}
. Why did you answer so evasively? Why did you not admit then that the
code was faulty, and thank me for pointing it out?
I had to change the wording for people that intentionally
try as hard as possible to make sure to interpret my words
incorrectly.
There are no such people on this newsgroup. Most people here try to
answer your posts directly and honestly. You are the poster who attempts
to mislead, obfuscate, and evade.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
Any H/D pair matching the above template where D(D) is simulated
by the same H(D,D) that it calls cannot possibly reach past its own
line 03. Simple software engineering verified fact.
Why are you doing this again? Simple software engineering shows that the
above code is so broken as to be unusable. Why don't you correct it
first before posting it yet again?
*above template ---not code, code template*
*I said it was a code template*
*You knew it was a code template and pretend to not know*
Perhaps you do understand what an execution trace is and
disparage my work without even looking at it?
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
*Any H/D pair matching the above template*
*Any H/D pair matching the above template*
*Any H/D pair matching the above template*
*Any H/D pair matching the above template*
*where D(D) is simulated by the same H(D,D) that it calls*
*where D(D) is simulated by the same H(D,D) that it calls*
*where D(D) is simulated by the same H(D,D) that it calls*
*where D(D) is simulated by the same H(D,D) that it calls*
*cannot possibly reach past its own line 03*
*cannot possibly reach past its own line 03*
*cannot possibly reach past its own line 03*
*cannot possibly reach past its own line 03*
You are simply dishonest.
On 5/11/2024 4:48 AM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 5/10/2024 1:38 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 5/10/2024 12:55 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It is
clear you have never built or run this code, which ironically
can't reach Line 06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an
example of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the
detailed* *steps of how I am wrong indicates that they are
probably liars*
You have said, or at least implied that your code fragment is
runnable. I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
I removed the line numbers from your code, added in a "pointer to
int function" type (you should really learn how to do this
yourself) and ran the result on GCC.
This is the file I submitted:
typedef int (* ptr) (void);
int H(ptr x, ptr x) // ptr is pointer to int function
int D(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
H(D,D);
}
. These are the diagnostics generated by GCC:
olcott.c:2:18: error: redefinition of parameter ‘x’
2 | int H(ptr x, ptr x) // ptr is pointer to int function
| ~~~~^
olcott.c:2:11: note: previous definition of ‘x’ with type ‘ptr’ {aka ‘int
(*)(void)’}
2 | int H(ptr x, ptr x) // ptr is pointer to int function
| ~~~~^
olcott.c: In function ‘H’:
olcott.c:4:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘{’ token
4 | {
| ^
olcott.c:12:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘{’ token
12 | {
| ^
olcott.c:15: error: expected ‘{’ at end of input
Any H/D pair matching the above template where D(D) is simulated >>>>>>> by the same H(D,D) that it calls cannot possibly reach past its own >>>>>>> line 03. Simple software engineering verified fact.
The code for D is so full of errors that it cannot demonstrate anything, >>>>>> beyond a lack of proficiency in C in its author.
*I have fully operational code, yet this is*
*not the code that the words below refer to*
Why, then, have you been spamming the group with faulty code for so long? >>>> Why did you not first check it and correct it before posting it?
When I brought up the issue before, you "answered", in
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory,sci.logic
Subject: Re: D simulated by H never halts no matter what H does V3
Date: Sat, 4 May 2024 10:47:00 -0500
, that
There is no actual error in these lines of code.
int main()
{
H(D,D);
return 0;
}
. Why did you answer so evasively? Why did you not admit then that the >>>> code was faulty, and thank me for pointing it out?
I had to change the wording for people that intentionally
try as hard as possible to make sure to interpret my words
incorrectly.
There are no such people on this newsgroup. Most people here try to
answer your posts directly and honestly. You are the poster who attempts >>>> to mislead, obfuscate, and evade.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
Any H/D pair matching the above template where D(D) is simulated
by the same H(D,D) that it calls cannot possibly reach past its own
line 03. Simple software engineering verified fact.
Why are you doing this again? Simple software engineering shows that the >>>> above code is so broken as to be unusable. Why don't you correct it
first before posting it yet again?
*above template ---not code, code template*
*I said it was a code template*
*You knew it was a code template and pretend to not know*
Now I understand why you write vaguely.
I did not write vaguely you simply did not bother to pay attention to
me clear words.
It's so that you can tell
untruths without lying, as you see it. You're like a politician in that
respect; you never commit yourself to anything, always leaving a get-out
for when the truth emerges.
You strongly implied, perhaps without actually saying, that that spammed
fragment was actual code - you denigrated critics of it by saying they
didn't have enough expertise in the C language.
*Any H/D pair matching the above template*
*where D(D) is simulated by the same H(D,D) that it calls*
*cannot possibly reach past its own line 03*
You are simply dishonest.
You referred to the code's execution trace. Your actual words were:
Perhaps you do understand what an execution trace is and
disparage my work without even looking at it?
This was presumably a "virtual" execution trace, i.e. totally
fictitious. Maybe you meant the ambiguous "it" to refer to "my work"
rather than the non-existent execution trace.
Maybe you don't class such untruths as lying. I do, and I think most
other posters here do too.
Again, why don't you correct that "template" and turn it into correct C?
Are you capable of doing that?
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
*A simulator is the conventional meaning of an x86 emulator or a UTM*
*D simulated by H where H can*
(a) Watch all of the state changes of its input.
(b) Analyze these state changes.
(c) Correctly determine that its input (and itself) would never halt.
(d) Continue to report that its input would never halt by
transitioning to a special non-final state indicating this.
*All the while remaining a pure simulator with extra features*
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It is clear
you have never built or run this code, which ironically can't reach Line
06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an example
of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the detailed*
*steps of how I am wrong indicates that they are probably liars*
You have said, or at least implied that your code fragment is runnable.
I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
. These are the diagnostics generated by GCC:
On 5/12/2024 11:54 PM, immibis wrote:
On 10/05/24 19:55, Alan Mackenzie wrote:
[ Followup-To: set ]And the halting problem is about Turing machines, anyway.
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It is clear
you have never built or run this code, which ironically can't reach Line >>> 06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an example
of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the detailed*
*steps of how I am wrong indicates that they are probably liars*
You have said, or at least implied that your code fragment is runnable.
I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
. These are the diagnostics generated by GCC:
It is sufficiently isomorphic to the Linz machines.
On 10/05/24 19:55, Alan Mackenzie wrote:
[ Followup-To: set ]And the halting problem is about Turing machines, anyway.
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It is clear
you have never built or run this code, which ironically can't reach Line
06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an example
of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the detailed*
*steps of how I am wrong indicates that they are probably liars*
You have said, or at least implied that your code fragment is runnable.
I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
. These are the diagnostics generated by GCC:
On 5/12/2024 11:54 PM, immibis wrote:
On 10/05/24 19:55, Alan Mackenzie wrote:
[ Followup-To: set ]And the halting problem is about Turing machines, anyway.
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It is clear
you have never built or run this code, which ironically can't reach Line >>> 06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an example
of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the detailed*
*steps of how I am wrong indicates that they are probably liars*
You have said, or at least implied that your code fragment is runnable.
I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
. These are the diagnostics generated by GCC:
It is sufficiently isomorphic to the Linz machines.
On 5/13/2024 4:14 AM, Mikko wrote:
On 2024-05-13 04:54:30 +0000, immibis said:
On 10/05/24 19:55, Alan Mackenzie wrote:
[ Followup-To: set ]And the halting problem is about Turing machines, anyway.
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It is clear >>>> you have never built or run this code, which ironically can't reach
Line
06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an example
of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the detailed* >>>>> *steps of how I am wrong indicates that they are probably liars*
You have said, or at least implied that your code fragment is runnable. >>>> I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
. These are the diagnostics generated by GCC:
Not necessarily. The same question can be asked about different machines.
The restriction to Turing machines is just one way to ensure that the
problem is well defined.
Well put. All computable functions even if written in C.
On 5/13/2024 12:29 AM, immibis wrote:
On 13/05/24 07:19, olcott wrote:
On 5/12/2024 11:54 PM, immibis wrote:
On 10/05/24 19:55, Alan Mackenzie wrote:
[ Followup-To: set ]And the halting problem is about Turing machines, anyway.
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It is clear >>>>> you have never built or run this code, which ironically can't reach
Line
06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an example >>>>>> of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the detailed* >>>>>> *steps of how I am wrong indicates that they are probably liars*
You have said, or at least implied that your code fragment is
runnable.
I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
. These are the diagnostics generated by GCC:
It is sufficiently isomorphic to the Linz machines.
Linz is talking about Turing machines.
My newest examples are anchored directly in Linz.
On 5/13/2024 4:14 AM, Mikko wrote:
On 2024-05-13 04:54:30 +0000, immibis said:
On 10/05/24 19:55, Alan Mackenzie wrote:
[ Followup-To: set ]And the halting problem is about Turing machines, anyway.
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It is clear >>>> you have never built or run this code, which ironically can't reach Line >>>> 06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an example
of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the detailed* >>>>> *steps of how I am wrong indicates that they are probably liars*
You have said, or at least implied that your code fragment is runnable. >>>> I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
. These are the diagnostics generated by GCC:
Not necessarily. The same question can be asked about different machines.
The restriction to Turing machines is just one way to ensure that the
problem is well defined.
Well put. All computable functions even if written in C.
On 5/14/2024 4:52 AM, Mikko wrote:
On 2024-05-13 14:43:09 +0000, olcott said:
On 5/13/2024 4:14 AM, Mikko wrote:
On 2024-05-13 04:54:30 +0000, immibis said:
On 10/05/24 19:55, Alan Mackenzie wrote:
[ Followup-To: set ]And the halting problem is about Turing machines, anyway.
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It is
clear
you have never built or run this code, which ironically can't
reach Line
06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an example >>>>>>> of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the
detailed*
*steps of how I am wrong indicates that they are probably liars*
You have said, or at least implied that your code fragment is
runnable.
I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
. These are the diagnostics generated by GCC:
Not necessarily. The same question can be asked about different
machines.
The restriction to Turing machines is just one way to ensure that the
problem is well defined.
Well put. All computable functions even if written in C.
You still must ensure that the problem is well defined. With C there is
the problem that conforming C programs often fail to be strictly
conforming.
If a program is not strictly conforming it may be interpreted as halting
by some implementation and non-halting or incorrect by another.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
One can correctly determine that every D simulated by H
never reaches past its own line 03.
On 5/14/2024 4:52 AM, Mikko wrote:
On 2024-05-13 14:43:09 +0000, olcott said:
On 5/13/2024 4:14 AM, Mikko wrote:
On 2024-05-13 04:54:30 +0000, immibis said:
On 10/05/24 19:55, Alan Mackenzie wrote:
[ Followup-To: set ]And the halting problem is about Turing machines, anyway.
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It is clear >>>>>> you have never built or run this code, which ironically can't reach Line >>>>>> 06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an example >>>>>>> of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the detailed* >>>>>>> *steps of how I am wrong indicates that they are probably liars*
You have said, or at least implied that your code fragment is runnable. >>>>>> I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
. These are the diagnostics generated by GCC:
Not necessarily. The same question can be asked about different machines. >>>> The restriction to Turing machines is just one way to ensure that the
problem is well defined.
Well put. All computable functions even if written in C.
You still must ensure that the problem is well defined. With C there is
the problem that conforming C programs often fail to be strictly conforming. >> If a program is not strictly conforming it may be interpreted as halting
by some implementation and non-halting or incorrect by another.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
One can correctly determine that every D simulated by H
never reaches past its own line 03.
On 5/15/2024 3:18 AM, Mikko wrote:What is H?
On 2024-05-14 14:35:42 +0000, olcott said:
That is not strictly conforming and hardly conforming at all.What trivial syntactic error that has no effect what-so-ever on the
semantics do you believe remains?
A missing semi-colon?
The example must be simple enough so that people unfamiliar with C willThen you can’t claim knowledge of C is required.
not be overwhelmed by things such as: typedef int (*ptr)();
a return value of 0 from main() also might be a little confusing.
I am trying to fit the essence of my proof on a single page.
On 5/15/2024 11:23 AM, joes wrote:
Am Wed, 15 May 2024 10:24:57 -0500 schrieb olcott:
On 5/15/2024 3:18 AM, Mikko wrote:What is H?
On 2024-05-14 14:35:42 +0000, olcott said:
That is not strictly conforming and hardly conforming at all.What trivial syntactic error that has no effect what-so-ever on the
semantics do you believe remains?
A missing semi-colon?
The example must be simple enough so that people unfamiliar with C willThen you can’t claim knowledge of C is required.
not be overwhelmed by things such as: typedef int (*ptr)();
a return value of 0 from main() also might be a little confusing.
I am trying to fit the essence of my proof on a single page.
Knowledge of C is required to affirm or deny my statement.
Knowledge of programming is required to understand the gist
of what I am saying.
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 }
Any H/D pair matching the above template where
D(D) is simulated by the same H(D,D) that it calls
cannot possibly reach past its own line 03.
This is a simple software engineering verified fact.
On 5/15/2024 3:18 AM, Mikko wrote:
On 2024-05-14 14:35:42 +0000, olcott said:
On 5/14/2024 4:52 AM, Mikko wrote:
On 2024-05-13 14:43:09 +0000, olcott said:
On 5/13/2024 4:14 AM, Mikko wrote:
On 2024-05-13 04:54:30 +0000, immibis said:
On 10/05/24 19:55, Alan Mackenzie wrote:
[ Followup-To: set ]And the halting problem is about Turing machines, anyway.
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It is clear
you have never built or run this code, which ironically can't reach Line
06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an example >>>>>>>>> of D simulated by H:You have said, or at least implied that your code fragment is runnable.
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the detailed* >>>>>>>>> *steps of how I am wrong indicates that they are probably liars* >>>>>>>>
I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
. These are the diagnostics generated by GCC:
Not necessarily. The same question can be asked about different machines.
The restriction to Turing machines is just one way to ensure that the >>>>>> problem is well defined.
Well put. All computable functions even if written in C.
You still must ensure that the problem is well defined. With C there is >>>> the problem that conforming C programs often fail to be strictly conforming.
If a program is not strictly conforming it may be interpreted as halting >>>> by some implementation and non-halting or incorrect by another.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
One can correctly determine that every D simulated by H
never reaches past its own line 03.
That is not strictly conforming and hardly conforming at all.
What trivial syntactic error that has no effect
what-so-ever on the semantics do you believe remains?
A missing semi-colon?
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 }
On 5/16/2024 5:48 AM, Mikko wrote:
On 2024-05-15 15:24:57 +0000, olcott said:
Normal semantics is that the program is not executed.
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.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 5/16/2024 11:15 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/16/2024 5:48 AM, Mikko wrote:
On 2024-05-15 15:24:57 +0000, olcott said:
[ .... ]
Normal semantics is that the program is not executed.
Indeed.
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.
That is another of your lies. It's largely why I despise you so much.
Although you've fixed the missing semicolon on line 0 (at last), it still
fails to compile under any C compiler worthy of the name. With all the
errors in it it still would have failed to compile under Linux or Windows
ever since it was written.
Quit lying. And fix that program fragment, assuming your C skills are up
to it.
There are many postings in this group providing the
actual execution trace output of that program.
It was named H and had input P,P back in 2021.
The record shows that you responded to these posts
that had the actual execution trace output provided.
My code fragment is a program template. I have told you this
countless times and you simply ignore what I say.
On 5/16/2024 5:48 AM, Mikko wrote:
On 2024-05-15 15:24:57 +0000, olcott said:
On 5/15/2024 3:18 AM, Mikko wrote:
On 2024-05-14 14:35:42 +0000, olcott said:
On 5/14/2024 4:52 AM, Mikko wrote:
On 2024-05-13 14:43:09 +0000, olcott said:
On 5/13/2024 4:14 AM, Mikko wrote:
On 2024-05-13 04:54:30 +0000, immibis said:
On 10/05/24 19:55, Alan Mackenzie wrote:
[ Followup-To: set ]And the halting problem is about Turing machines, anyway.
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It is clear
you have never built or run this code, which ironically can't reach Line
06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an example >>>>>>>>>>> of D simulated by H:You have said, or at least implied that your code fragment is runnable.
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the detailed*
*steps of how I am wrong indicates that they are probably liars* >>>>>>>>>>
I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function >>>>>>>>>>> 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 }
. These are the diagnostics generated by GCC:
Not necessarily. The same question can be asked about different machines.
The restriction to Turing machines is just one way to ensure that the >>>>>>>> problem is well defined.
Well put. All computable functions even if written in C.
You still must ensure that the problem is well defined. With C there is >>>>>> the problem that conforming C programs often fail to be strictly conforming.
If a program is not strictly conforming it may be interpreted as halting >>>>>> by some implementation and non-halting or incorrect by another.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
One can correctly determine that every D simulated by H
never reaches past its own line 03.
That is not strictly conforming and hardly conforming at all.
What trivial syntactic error that has no effect
what-so-ever on the semantics do you believe remains?
A trivial sysntactic error means that the program is not strictly
conforming. It may be conforming if some liberal compiler accepts
it.
A missing semi-colon?
Normal semantics is that the program is not executed.
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.
On 5/16/2024 11:15 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/16/2024 5:48 AM, Mikko wrote:
On 2024-05-15 15:24:57 +0000, olcott said:
[ .... ]
Normal semantics is that the program is not executed.
Indeed.
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.
That is another of your lies. It's largely why I despise you so much.
Although you've fixed the missing semicolon on line 0 (at last), it still
fails to compile under any C compiler worthy of the name. With all the
errors in it it still would have failed to compile under Linux or Windows
ever since it was written.
Quit lying. And fix that program fragment, assuming your C skills are up
to it.
There are many postings in this group providing the
actual execution trace output of that program.
It was named H and had input P,P back in 2021.
The record shows that you responded to these posts
that had the actual execution trace output provided.
My code fragment is a program template. I have told you this
countless times and you simply ignore what I say.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 5/17/2024 3:02 PM, Alan Mackenzie wrote:
That "program" doesn't compile. It's ill-formed.
This does compile under C17 and C11
with Microsoft Visual Studio 2022
*Maybe you forgot to take the line numbers out*
*Maybe you forgot to take the line numbers out*
*Maybe you forgot to take the line numbers out*
*Maybe you forgot to take the line numbers out*
typedef int (*ptr)();
int H(ptr P, ptr I);
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:
On 5/15/2024 3:18 AM, Mikko wrote:
On 2024-05-14 14:35:42 +0000, olcott said:
On 5/14/2024 4:52 AM, Mikko wrote:
On 2024-05-13 14:43:09 +0000, olcott said:
On 5/13/2024 4:14 AM, Mikko wrote:
On 2024-05-13 04:54:30 +0000, immibis said:
On 10/05/24 19:55, Alan Mackenzie wrote:Not necessarily. The same question can be asked about
[ Followup-To: set ]And the halting problem is about Turing machines, anyway. >>>>>>>>>>
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). >>>>>>>>>>>> It is clear
you have never built or run this code, which ironically >>>>>>>>>>>> can't reach Line
06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an >>>>>>>>>>>>> example
of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the >>>>>>>>>>>>> detailed*
*steps of how I am wrong indicates that they are probably >>>>>>>>>>>>> liars*
You have said, or at least implied that your code fragment >>>>>>>>>>>> is runnable.
I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function >>>>>>>>>>>>> 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 }
. These are the diagnostics generated by GCC:
different machines.
The restriction to Turing machines is just one way to ensure >>>>>>>>>> that the
problem is well defined.
Well put. All computable functions even if written in C.
You still must ensure that the problem is well defined. With C >>>>>>>> there is
the problem that conforming C programs often fail to be strictly >>>>>>>> conforming.
If a program is not strictly conforming it may be interpreted as >>>>>>>> halting
by some implementation and non-halting or incorrect by another. >>>>>>>>
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
One can correctly determine that every D simulated by H
never reaches past its own line 03.
That is not strictly conforming and hardly conforming at all.
What trivial syntactic error that has no effect
what-so-ever on the semantics do you believe remains?
A trivial sysntactic error means that the program is not strictly
conforming. It may be conforming if some liberal compiler accepts
it.
A missing semi-colon?
Normal semantics is that the program is not executed.
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.
Fully operational software that runs under Widows and Linux
proves that the above is true EMPIRICALLY.
On 5/18/2024 3:54 AM, immibis wrote:
On 16/05/24 16:50, olcott wrote:
On 5/16/2024 5:48 AM, Mikko wrote:
On 2024-05-15 15:24:57 +0000, olcott said:
On 5/15/2024 3:18 AM, Mikko wrote:
On 2024-05-14 14:35:42 +0000, olcott said:
On 5/14/2024 4:52 AM, Mikko wrote:
On 2024-05-13 14:43:09 +0000, olcott said:
On 5/13/2024 4:14 AM, Mikko wrote:
On 2024-05-13 04:54:30 +0000, immibis said:
On 10/05/24 19:55, Alan Mackenzie wrote:Not necessarily. The same question can be asked about
[ Followup-To: set ]And the halting problem is about Turing machines, anyway. >>>>>>>>>>
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). >>>>>>>>>>>> It is clear
you have never built or run this code, which ironically >>>>>>>>>>>> can't reach Line
06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an >>>>>>>>>>>>> example
of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the >>>>>>>>>>>>> detailed*
*steps of how I am wrong indicates that they are probably >>>>>>>>>>>>> liars*
You have said, or at least implied that your code fragment >>>>>>>>>>>> is runnable.
I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function >>>>>>>>>>>>> 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 }
. These are the diagnostics generated by GCC:
different machines.
The restriction to Turing machines is just one way to ensure >>>>>>>>>> that the
problem is well defined.
Well put. All computable functions even if written in C.
You still must ensure that the problem is well defined. With C >>>>>>>> there is
the problem that conforming C programs often fail to be strictly >>>>>>>> conforming.
If a program is not strictly conforming it may be interpreted as >>>>>>>> halting
by some implementation and non-halting or incorrect by another. >>>>>>>>
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
One can correctly determine that every D simulated by H
never reaches past its own line 03.
That is not strictly conforming and hardly conforming at all.
What trivial syntactic error that has no effect
what-so-ever on the semantics do you believe remains?
A trivial sysntactic error means that the program is not strictly
conforming. It may be conforming if some liberal compiler accepts
it.
A missing semi-colon?
Normal semantics is that the program is not executed.
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.
and it halts and it thinks it does not halt
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 }
Explaining how this is incorrect requires the prerequisite knowledge
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.
There are more steps beyond this mandatory prerequisite.
On 5/18/2024 3:54 AM, immibis wrote:Just for fun, what are these steps if we assumed this claim?
On 16/05/24 16:50, olcott wrote:
On 5/16/2024 5:48 AM, Mikko wrote:
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 }
Explaining how this is incorrect requires the prerequisite knowledge
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.
There are more steps beyond this mandatory prerequisite.
On 5/17/2024 6:15 PM, André G. Isaak wrote:
On 2024-05-17 17:00, olcott wrote:
On 5/17/2024 3:02 PM, Alan Mackenzie wrote:
That "program" doesn't compile. It's ill-formed.
This does compile under C17 and C11
with Microsoft Visual Studio 2022
;
*Maybe you forgot to take the line numbers out*
*Maybe you forgot to take the line numbers out*
*Maybe you forgot to take the line numbers out*
*Maybe you forgot to take the line numbers out*
typedef int (*ptr)();
int H(ptr P, ptr I);
But that's not the code you provide in your numerous previous posts
where you insist on
int H(ptr x, ptr x);
Maybe when people point out that there is an error you should actually
proofread what you wrote.
[remaining code deleted].
André
*Whoops my mistake*
*Whoops my mistake*
*Whoops my mistake*
*Whoops my mistake*
Thanks for your review.
I couldn't see my mistake when I tried to compile it
so I used an old trick, refactor from working code.
I still didn't see my mistake, yet got it to compile.
Yes and several people also continue to point out that D
correctly simulated by H can reach its own line 06 and halt
even when an execution trace of H simulating itself simulating
D proves otherwise.
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?
On 5/18/2024 9:58 PM, André G. Isaak wrote:
On 2024-05-17 18:24, olcott wrote:
On 5/17/2024 6:15 PM, André G. Isaak wrote:
On 2024-05-17 17:00, olcott wrote:
On 5/17/2024 3:02 PM, Alan Mackenzie wrote:
That "program" doesn't compile. It's ill-formed.
This does compile under C17 and C11
with Microsoft Visual Studio 2022
;
*Maybe you forgot to take the line numbers out*
*Maybe you forgot to take the line numbers out*
*Maybe you forgot to take the line numbers out*
*Maybe you forgot to take the line numbers out*
typedef int (*ptr)();
int H(ptr P, ptr I);
But that's not the code you provide in your numerous previous posts
where you insist on
int H(ptr x, ptr x);
Maybe when people point out that there is an error you should
actually proofread what you wrote.
[remaining code deleted].
André
*Whoops my mistake*
*Whoops my mistake*
*Whoops my mistake*
*Whoops my mistake*
Thanks for your review.
I couldn't see my mistake when I tried to compile it
so I used an old trick, refactor from working code.
I still didn't see my mistake, yet got it to compile.
You're missing the point. This error had been pointed out to you
multiple times by multiple posters. Alan even pointed out the
*specific* compiler errors which it generated under GCC. Yet you
refused to correct it for weeks on end, insisting that everyone else
was wrong.
Yes and several people also continue to point out that D
correctly simulated by H can reach its own line 06 and halt
even when an execution trace of H simulating itself simulating
D proves otherwise.
A competent C programmer wouldn't have run into this issue since they
would have declared the function as something like:
int H(ptr programDescription, ptr programInput); // no silly x and y
The actual names are P and I.
Yes I agree that meaningful variable names are very important
yet computer scientists don't do it that was when referring
to the halting problem.
Yet you continue to question everyone else's 'C-credentials' when you
are the one making very basic errors. That hardly inspires confidence
in anything else you might say about C.
André
Several people continue to lie about the execution trace
that is proven by H simulating itself simulating D.
On 5/18/2024 10:45 PM, immibis wrote:
On 19/05/24 05:27, olcott wrote:
Yes and several people also continue to point out that D
correctly simulated by H can reach its own line 06 and halt
even when an execution trace of H simulating itself simulating
D proves otherwise.
You don't understand that a correct simulation does the same thing as
the real program. A correct simulation of D doesn't reach line 06 if D
outside of a simulation doesn't reach line 06.
If D outside of a simulation reaches line 06 but D inside of a
simulation doesn't reach line 06 then the simulation is wrong.
*We have not gotten to that point in the dialog yet*
Every element of an infinite set of H/D pairs matching a template
where H correctly simulates 1 to ∞ steps of D thus including
0 to ∞ recursive simulations of H simulating itself simulating D.
*No D correctly simulating by H ever reaches its own line 06 and halts*
On 5/18/2024 10:45 PM, immibis wrote:
On 19/05/24 05:27, olcott wrote:
Yes and several people also continue to point out that D
correctly simulated by H can reach its own line 06 and halt
even when an execution trace of H simulating itself simulating
D proves otherwise.
You don't understand that a correct simulation does the same thing as
the real program. A correct simulation of D doesn't reach line 06 if D
outside of a simulation doesn't reach line 06.
If D outside of a simulation reaches line 06 but D inside of a
simulation doesn't reach line 06 then the simulation is wrong.
*We have not gotten to that point in the dialog yet*
Every element of an infinite set of H/D pairs matching a template
where H correctly simulates 1 to ∞ steps of D thus including
0 to ∞ recursive simulations of H simulating itself simulating D.
*No D correctly simulating by H ever reaches its own line 06 and halts*
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.
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.
On 5/19/24 06:23, Mikko wrote:
...
Which version of the standard do the references refer to? I don't expect
these things vary from one version to the next but section and paragraph
numbers might.
The actual standards cost money, whereas draft standards are free. The
final draft before a new release of the standard is usually almost
identical to that release. I'm using n3096.pdf, which is a draft dated 2023-04-01.
On 5/19/2024 7:15 AM, immibis wrote:
On 19/05/24 05:50, olcott wrote:
On 5/18/2024 10:45 PM, immibis wrote:
On 19/05/24 05:27, olcott wrote:
Yes and several people also continue to point out that D
correctly simulated by H can reach its own line 06 and halt
even when an execution trace of H simulating itself simulating
D proves otherwise.
You don't understand that a correct simulation does the same thing
as the real program. A correct simulation of D doesn't reach line 06
if D outside of a simulation doesn't reach line 06.
If D outside of a simulation reaches line 06 but D inside of a
simulation doesn't reach line 06 then the simulation is wrong.
*We have not gotten to that point in the dialog yet*
we got to it many times before
People glance at a few things that I say and then leap to the
conclusion that I must be wrong without systematically evaluating
every step of my proof.
People call me a liar without ever actually showing that I am incorrect.
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.
On 19/05/24 15:11, olcott wrote:
On 5/19/2024 7:15 AM, immibis wrote:
On 19/05/24 05:50, olcott wrote:
On 5/18/2024 10:45 PM, immibis wrote:
On 19/05/24 05:27, olcott wrote:
Yes and several people also continue to point out that D
correctly simulated by H can reach its own line 06 and halt
even when an execution trace of H simulating itself simulating
D proves otherwise.
You don't understand that a correct simulation does the same thing as >>>>> the real program. A correct simulation of D doesn't reach line 06 if D >>>>> outside of a simulation doesn't reach line 06.
If D outside of a simulation reaches line 06 but D inside of a
simulation doesn't reach line 06 then the simulation is wrong.
*We have not gotten to that point in the dialog yet*
we got to it many times before
People glance at a few things that I say and then leap to the
conclusion that I must be wrong without systematically evaluating
every step of my proof.
we already evaluated them many times before. there is no need to
evaluate the exact same steps again.
People call me a liar without ever actually showing that I am incorrect.
we have shown you are incorrect and you pretend not do see it.
proof: the simulation behaves different from the execution. therefore
it is an incorrect simulation. you say it is a correct simulation.
therefore you are a liar.
On 5/20/2024 3:21 AM, Mikko wrote:
On 2024-05-19 14:03:01 +0000, olcott said:
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:
The standard allows that an program is executed but does nottypedef 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. >>>>>>>>
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?
Oops, I made a typo on the last line. Pro "nor" lege "or".
Fortunately most of the typos are harmless but this one
might be a problem.
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.
As far as I can see, that does not say anything that was not already
said (but there is a minor presentational imporvement) and in particular
does not answer my question.
For two or three years everyone has been claiming that the
above measures of correct simulation are incorrect. Their
"ultimate" measure of a "correct" simulation is that D does
whatever they expect D to do.
For two or three years everyone has been claiming that the
above measures of correct simulation are incorrect. Their
"ultimate" measure of a "correct" simulation is that D does
whatever they expect D to do.
On 5/17/2024 6:15 PM, André G. Isaak wrote:
On 2024-05-17 17:00, olcott wrote:
On 5/17/2024 3:02 PM, Alan Mackenzie wrote:
That "program" doesn't compile. It's ill-formed.
This does compile under C17 and C11
with Microsoft Visual Studio 2022
;
*Maybe you forgot to take the line numbers out*
*Maybe you forgot to take the line numbers out*
*Maybe you forgot to take the line numbers out*
*Maybe you forgot to take the line numbers out*
typedef int (*ptr)();
int H(ptr P, ptr I);
But that's not the code you provide in your numerous previous posts
where you insist on
int H(ptr x, ptr x);
Maybe when people point out that there is an error you should actually
proofread what you wrote.
[remaining code deleted].
André
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 }
When people tell me that I am wrong about the semantics of
that code template I have always known they are wrong because
I have always had empirical proof that D correctly simulated
By H cannot possibly reach its own simulated line 06 and halt.
On 5/16/2024 5:48 AM, Mikko wrote:
On 2024-05-15 15:24:57 +0000, olcott said:
On 5/15/2024 3:18 AM, Mikko wrote:
On 2024-05-14 14:35:42 +0000, olcott said:
On 5/14/2024 4:52 AM, Mikko wrote:
On 2024-05-13 14:43:09 +0000, olcott said:
On 5/13/2024 4:14 AM, Mikko wrote:
On 2024-05-13 04:54:30 +0000, immibis said:
On 10/05/24 19:55, Alan Mackenzie wrote:
[ Followup-To: set ]And the halting problem is about Turing machines, anyway.
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
I've tried out your much spammed code on GCC (see below). It >>>>>>>>>> is clear
you have never built or run this code, which ironically can't >>>>>>>>>> reach Line
06. It can't even reach line 00.
Richard tried to get away with D never simulated by H as an >>>>>>>>>>> exampleYou have said, or at least implied that your code fragment is >>>>>>>>>> runnable.
of D simulated by H:
Message-ID: <v0ummt$2qov3$2@i2pn2.org>
On 5/1/2024 7:28 PM, Richard Damon wrote:
*That people say they know I am wrong yet will not show the >>>>>>>>>>> detailed*
*steps of how I am wrong indicates that they are probably liars* >>>>>>>>>>
I think you are the liar, here.
00 int H(ptr x, ptr x) // ptr is pointer to int function >>>>>>>>>>> 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 }
. These are the diagnostics generated by GCC:
Not necessarily. The same question can be asked about different >>>>>>>> machines.
The restriction to Turing machines is just one way to ensure
that the
problem is well defined.
Well put. All computable functions even if written in C.
You still must ensure that the problem is well defined. With C
there is
the problem that conforming C programs often fail to be strictly
conforming.
If a program is not strictly conforming it may be interpreted as
halting
by some implementation and non-halting or incorrect by another.
00 int H(ptr x, ptr x) // ptr is pointer to int function
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 }
One can correctly determine that every D simulated by H
never reaches past its own line 03.
That is not strictly conforming and hardly conforming at all.
What trivial syntactic error that has no effect
what-so-ever on the semantics do you believe remains?
A trivial sysntactic error means that the program is not strictly
conforming. It may be conforming if some liberal compiler accepts
it.
A missing semi-colon?
Normal semantics is that the program is not executed.
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.
On 5/20/2024 3:21 AM, Mikko wrote:
On 2024-05-19 14:03:01 +0000, olcott said:
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:
The standard allows that an program is executed but does nottypedef 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. >>>>>>>>
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?
Oops, I made a typo on the last line. Pro "nor" lege "or".
Fortunately most of the typos are harmless but this one
might be a problem.
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.
As far as I can see, that does not say anything that was not already
said (but there is a minor presentational imporvement) and in particular
does not answer my question.
For two or three years everyone has been claiming that the
above measures of correct simulation are incorrect. Their
"ultimate" measure of a "correct" simulation is that D does
whatever they expect D to do.
On 5/20/2024 11:49 PM, immibis wrote:
On 20/05/24 19:56, olcott wrote:
For two or three years everyone has been claiming that the
above measures of correct simulation are incorrect. Their
"ultimate" measure of a "correct" simulation is that D does
whatever they expect D to do.
The ultimate measure of a correct simulation is that the simulation
does the same thing the thing that you are simulating does. In other
words, H(D,D) does the same thing that D(D) does.
When I test an electronic circuit in a circuit simulator and then
build it in real life, it should do the same thing that the simulator
said it would do.
*Lying meets the standard of losing defamation cases*
You are a liar to the extent of losing a defamation
case against you. The authorities can hunt you down
by your IP address.
A c function is correctly simulated when its machine language
instructions are emulated with an x86 emulator in the order
that they are specified by the x86 machine language of this
c function. For non-terminating functions we can only correctly
simulate N machine language instructions.
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?
I initially read that as nonsense.
You are asking for the definition of correct simulation
that I have been providing for quite a while recently.
A c function is correctly simulated when its machine language
instructions are emulated with an x86 emulator in the order
that they are specified by the x86 machine language of this
c function. For non-terminating functions we can only correctly
simulate N machine language instructions.
For the H/D pair we can simulate 1 to N instructions of D that
results in 0 to M recursive simulations of H simulating itself
simulating D.
Richard Damon <richard@damon-family.org> writes:
[snip]
Richard, will you *please* drop comp.lang.c from your posts on
this thread, at least for posts with no C content? olcott is not persuadable, but perhaps you are.
On 5/21/2024 10:13 PM, Keith Thompson wrote:
Richard Damon <richard@damon-family.org> writes:
[snip]
Richard, will you *please* drop comp.lang.c from your posts on
this thread, at least for posts with no C content? olcott is not
persuadable, but perhaps you are.
I have stayed focused on the C and people kept totally
ignoring the C so I had to explain what the C is important.
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.
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?
I initially read that as nonsense.
You are asking for the definition of correct simulation
that I have been providing for quite a while recently.
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.
A c function is correctly simulated when its machine language
instructions are emulated with an x86 emulator in the order
that they are specified by the x86 machine language of this
c function.
For non-terminating functions we can only correctly
simulate N machine language instructions.
For the H/D pair we can simulate 1 to N instructions of D that
results in 0 to M recursive simulations of H simulating itself
simulating D.
On 5/20/2024 3:21 AM, Mikko wrote:
On 2024-05-19 14:03:01 +0000, olcott said:
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:
The standard allows that an program is executed but does nottypedef 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. >>>>>>>>
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?
Oops, I made a typo on the last line. Pro "nor" lege "or".
Fortunately most of the typos are harmless but this one
might be a problem.
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.
As far as I can see, that does not say anything that was not already
said (but there is a minor presentational imporvement) and in particular
does not answer my question.
The problem is that people continue to refuse to answer the updated
question and the original question. Everyone spends enormous effort
on not answering either question.
On 5/21/2024 10:13 PM, Keith Thompson wrote:
Richard Damon <richard@damon-family.org> writes:
[snip]
Richard, will you *please* drop comp.lang.c from your posts on
this thread, at least for posts with no C content? olcott is not
persuadable, but perhaps you are.
I have stayed focused on the C and people kept totally
ignoring the C so I had to explain what the C is important.
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.
On 5/22/2024 2:39 AM, Mikko wrote:
On 2024-05-21 13:54:09 +0000, olcott said:
You are asking for the definition of correct simulation
that I have been providing for quite a while recently.
That was not my main intent. I wanted to know why your
statement
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.
exludes every unsimulated or incorrectly simulated D?
That sounds like Richard that assumed that incorrect answers are OK
unless I specifically say that incorrect answers are not OK.
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).
A c function is correctly simulated when its machine language
instructions are emulated with an x86 emulator in the order
that they are specified by the x86 machine language of this
c function.
Does "its machine language instructions" mean all executed instructions
until the progam terminates? Or from the start of the program until
there is no reason to continue? Or from some point to some other point?
It means that 1 to N instructions of D are correctly simulated
by pure function H. Because D correctly simulated by H remains
stuck in recursive simulation D cannot possibly reach is own
line 06 and halt.
For non-terminating functions we can only correctly
simulate N machine language instructions.
But does you definition regard that partial simulation as "correct
simulation"?
When 1 to 2^64 instructions of D are correctly simulated by H
it becomes clear that for every H/D pair of the infinite set
of H/D pairs D correctly simulated by H remains stuck in recursive simulation.
For the H/D pair we can simulate 1 to N instructions of D that
results in 0 to M recursive simulations of H simulating itself
simulating D.
But is this kind of recursive simulation "correc"? Does "correct"
apply to ("correctly" or otherwise) simulated simulations? Does
correctness of simulation of simulation depend on the oorrectness
of simulated simulation?
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 }
When talking about an infinite set of H/D pairs...
A c function is correctly simulated when its machine language
instructions are emulated with an x86 emulator in the order that
they are specified by the x86 machine language of this c function.
For terminating inputs the input is simulated until termination.
This applies to every H/D pair of the infinite set of H/D pairs
matching the above template:
Every D correctly simulated by pure by function H remains stuck in
recursive simulation and can never reach its own line 06 and halt.
On 5/22/2024 2:39 AM, Mikko wrote:
On 2024-05-21 13:54:09 +0000, olcott said:
You are asking for the definition of correct simulation
that I have been providing for quite a while recently.
That was not my main intent. I wanted to know why your
statement
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.
exludes every unsimulated or incorrectly simulated D?
That sounds like Richard that assumed that incorrect answers are OK
unless I specifically say that incorrect answers are not OK.
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).
A c function is correctly simulated when its machine language
instructions are emulated with an x86 emulator in the order
that they are specified by the x86 machine language of this
c function.
Does "its machine language instructions" mean all executed instructions
until the progam terminates? Or from the start of the program until
there is no reason to continue? Or from some point to some other point?
It means that 1 to N instructions of D are correctly simulated
by pure function H. Because D correctly simulated by H remains
stuck in recursive simulation D cannot possibly reach is own
line 06 and halt.
For non-terminating functions we can only correctly
simulate N machine language instructions.
But does you definition regard that partial simulation as "correct
simulation"?
When 1 to 2^64 instructions of D are correctly simulated by H
it becomes clear that for every H/D pair of the infinite set
of H/D pairs D correctly simulated by H remains stuck in recursive simulation.
On 5/23/2024 5:06 AM, Mikko wrote:
On 2024-05-22 14:51:50 +0000, olcott said:
On 5/22/2024 2:39 AM, Mikko wrote:
On 2024-05-21 13:54:09 +0000, olcott said:
You are asking for the definition of correct simulation
that I have been providing for quite a while recently.
That was not my main intent. I wanted to know why your
statement
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.
exludes every unsimulated or incorrectly simulated D?
That sounds like Richard that assumed that incorrect answers are OK
unless I specifically say that incorrect answers are not OK.
Maybe but I don't promise that the response to the incorrect answer
will sound the same.
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).
A c function is correctly simulated when its machine language
instructions are emulated with an x86 emulator in the order
that they are specified by the x86 machine language of this
c function.
Does "its machine language instructions" mean all executed instructions >>>> until the progam terminates? Or from the start of the program until
there is no reason to continue? Or from some point to some other point? >>>>
It means that 1 to N instructions of D are correctly simulated
by pure function H. Because D correctly simulated by H remains
stuck in recursive simulation D cannot possibly reach is own
line 06 and halt.
If you mean that H cannot simulate D to the line 06 then say so.
A D that is simulated by H is D and so is a D that is not simulated
by H so both can do what a D can do. Saying "simulated by H" adds
nothing.
For non-terminating functions we can only correctly
simulate N machine language instructions.
But does you definition regard that partial simulation as "correct
simulation"?
When 1 to 2^64 instructions of D are correctly simulated by H
it becomes clear that for every H/D pair of the infinite set
of H/D pairs D correctly simulated by H remains stuck in recursive
simulation.
If you think that the meaning of "correctly simulate" is not
important you should not use those words.
I must use those words or a standard of incorrect simulation
is assumed. We have been going over the term "correct simulation"
in these forums with dozens of people and hundreds of messages
over several years.
CORRECT SIMULATION DEFINED
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.
On 5/23/2024 5:06 AM, Mikko wrote:
On 2024-05-22 14:51:50 +0000, olcott said:
On 5/22/2024 2:39 AM, Mikko wrote:
On 2024-05-21 13:54:09 +0000, olcott said:
You are asking for the definition of correct simulation
that I have been providing for quite a while recently.
That was not my main intent. I wanted to know why your
statement
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.
exludes every unsimulated or incorrectly simulated D?
That sounds like Richard that assumed that incorrect answers are OK
unless I specifically say that incorrect answers are not OK.
Maybe but I don't promise that the response to the incorrect answer
will sound the same.
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).
A c function is correctly simulated when its machine language
instructions are emulated with an x86 emulator in the order
that they are specified by the x86 machine language of this
c function.
Does "its machine language instructions" mean all executed instructions >>>> until the progam terminates? Or from the start of the program until
there is no reason to continue? Or from some point to some other point? >>>>
It means that 1 to N instructions of D are correctly simulated
by pure function H. Because D correctly simulated by H remains
stuck in recursive simulation D cannot possibly reach is own
line 06 and halt.
If you mean that H cannot simulate D to the line 06 then say so.
A D that is simulated by H is D and so is a D that is not simulated
by H so both can do what a D can do. Saying "simulated by H" adds
nothing.
For non-terminating functions we can only correctly
simulate N machine language instructions.
But does you definition regard that partial simulation as "correct
simulation"?
When 1 to 2^64 instructions of D are correctly simulated by H
it becomes clear that for every H/D pair of the infinite set
of H/D pairs D correctly simulated by H remains stuck in recursive
simulation.
If you think that the meaning of "correctly simulate" is not
important you should not use those words.
I must use those words or a standard of incorrect simulation
is assumed.
We have been going over the term "correct simulation"
in these forums with dozens of people and hundreds of messages
over several years.
CORRECT SIMULATION DEFINED
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.
On 5/24/2024 3:58 AM, Mikko wrote:
On 2024-05-23 13:18:02 +0000, olcott said:
On 5/23/2024 5:06 AM, Mikko wrote:
On 2024-05-22 14:51:50 +0000, olcott said:
On 5/22/2024 2:39 AM, Mikko wrote:
On 2024-05-21 13:54:09 +0000, olcott said:
You are asking for the definition of correct simulation
that I have been providing for quite a while recently.
That was not my main intent. I wanted to know why your
statement
exludes every unsimulated or incorrectly simulated D?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. >>>>>>
That sounds like Richard that assumed that incorrect answers are OK
unless I specifically say that incorrect answers are not OK.
Maybe but I don't promise that the response to the incorrect answer
will sound the same.
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).
A c function is correctly simulated when its machine language
instructions are emulated with an x86 emulator in the order
that they are specified by the x86 machine language of this
c function.
Does "its machine language instructions" mean all executed
instructions
until the progam terminates? Or from the start of the program until >>>>>> there is no reason to continue? Or from some point to some other
point?
It means that 1 to N instructions of D are correctly simulated
by pure function H. Because D correctly simulated by H remains
stuck in recursive simulation D cannot possibly reach is own
line 06 and halt.
If you mean that H cannot simulate D to the line 06 then say so.
A D that is simulated by H is D and so is a D that is not simulated
by H so both can do what a D can do. Saying "simulated by H" adds
nothing.
For non-terminating functions we can only correctly
simulate N machine language instructions.
But does you definition regard that partial simulation as "correct >>>>>> simulation"?
When 1 to 2^64 instructions of D are correctly simulated by H
it becomes clear that for every H/D pair of the infinite set
of H/D pairs D correctly simulated by H remains stuck in recursive
simulation.
If you think that the meaning of "correctly simulate" is not
important you should not use those words.
I must use those words or a standard of incorrect simulation
is assumed.
There is no "standard of incorrect simulation".
We have been going over the term "correct simulation"
in these forums with dozens of people and hundreds of messages
over several years.
That alone is a sufficient reaston to avoid the expression.
CORRECT SIMULATION DEFINED
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.
That is not a definition but perhaps a suffient substitute for paractical
purposes.
It provides a clear and correct criterion measure to utterly
refute each and every reviewer that tries to get away with
the incorrect emulation of the x86 instructions of H or D or
emulating them in the wrong order.
On 5/24/2024 3:58 AM, Mikko wrote:
On 2024-05-23 13:18:02 +0000, olcott said:
On 5/23/2024 5:06 AM, Mikko wrote:
On 2024-05-22 14:51:50 +0000, olcott said:
On 5/22/2024 2:39 AM, Mikko wrote:
On 2024-05-21 13:54:09 +0000, olcott said:
You are asking for the definition of correct simulation
that I have been providing for quite a while recently.
That was not my main intent. I wanted to know why your
statement
exludes every unsimulated or incorrectly simulated D?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. >>>>>>
That sounds like Richard that assumed that incorrect answers are OK
unless I specifically say that incorrect answers are not OK.
Maybe but I don't promise that the response to the incorrect answer
will sound the same.
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).
A c function is correctly simulated when its machine language
instructions are emulated with an x86 emulator in the order
that they are specified by the x86 machine language of this
c function.
Does "its machine language instructions" mean all executed instructions >>>>>> until the progam terminates? Or from the start of the program until >>>>>> there is no reason to continue? Or from some point to some other point? >>>>>>
It means that 1 to N instructions of D are correctly simulated
by pure function H. Because D correctly simulated by H remains
stuck in recursive simulation D cannot possibly reach is own
line 06 and halt.
If you mean that H cannot simulate D to the line 06 then say so.
A D that is simulated by H is D and so is a D that is not simulated
by H so both can do what a D can do. Saying "simulated by H" adds
nothing.
For non-terminating functions we can only correctly
simulate N machine language instructions.
But does you definition regard that partial simulation as "correct >>>>>> simulation"?
When 1 to 2^64 instructions of D are correctly simulated by H
it becomes clear that for every H/D pair of the infinite set
of H/D pairs D correctly simulated by H remains stuck in recursive
simulation.
If you think that the meaning of "correctly simulate" is not
important you should not use those words.
I must use those words or a standard of incorrect simulation
is assumed.
There is no "standard of incorrect simulation".
We have been going over the term "correct simulation"
in these forums with dozens of people and hundreds of messages
over several years.
That alone is a sufficient reaston to avoid the expression.
CORRECT SIMULATION DEFINED
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.
That is not a definition but perhaps a suffient substitute for paractical
purposes.
It provides a clear and correct criterion measure to utterly
refute each and every reviewer that tries to get away with
the incorrect emulation of the x86 instructions of H or D or
emulating them in the wrong order.
On 5/25/2024 3:14 AM, Mikko wrote:
On 2024-05-24 17:13:05 +0000, olcott said:
On 5/24/2024 3:58 AM, Mikko wrote:
On 2024-05-23 13:18:02 +0000, olcott said:
On 5/23/2024 5:06 AM, Mikko wrote:
On 2024-05-22 14:51:50 +0000, olcott said:
On 5/22/2024 2:39 AM, Mikko wrote:
On 2024-05-21 13:54:09 +0000, olcott said:
You are asking for the definition of correct simulation
that I have been providing for quite a while recently.
That was not my main intent. I wanted to know why your
statement
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.
exludes every unsimulated or incorrectly simulated D?
That sounds like Richard that assumed that incorrect answers are OK >>>>>>> unless I specifically say that incorrect answers are not OK.
Maybe but I don't promise that the response to the incorrect answer >>>>>> will sound the same.
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).
A c function is correctly simulated when its machine language >>>>>>>>> instructions are emulated with an x86 emulator in the order
that they are specified by the x86 machine language of this
c function.
Does "its machine language instructions" mean all executed
instructions
until the progam terminates? Or from the start of the program until >>>>>>>> there is no reason to continue? Or from some point to some other >>>>>>>> point?
It means that 1 to N instructions of D are correctly simulated
by pure function H. Because D correctly simulated by H remains
stuck in recursive simulation D cannot possibly reach is own
line 06 and halt.
If you mean that H cannot simulate D to the line 06 then say so.
A D that is simulated by H is D and so is a D that is not simulated >>>>>> by H so both can do what a D can do. Saying "simulated by H" adds
nothing.
For non-terminating functions we can only correctly
simulate N machine language instructions.
But does you definition regard that partial simulation as "correct >>>>>>>> simulation"?
When 1 to 2^64 instructions of D are correctly simulated by H
it becomes clear that for every H/D pair of the infinite set
of H/D pairs D correctly simulated by H remains stuck in recursive >>>>>>> simulation.
If you think that the meaning of "correctly simulate" is not
important you should not use those words.
I must use those words or a standard of incorrect simulation
is assumed.
There is no "standard of incorrect simulation".
We have been going over the term "correct simulation"
in these forums with dozens of people and hundreds of messages
over several years.
That alone is a sufficient reaston to avoid the expression.
CORRECT SIMULATION DEFINED
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.
That is not a definition but perhaps a suffient substitute for
paractical
purposes.
It provides a clear and correct criterion measure to utterly
refute each and every reviewer that tries to get away with
the incorrect emulation of the x86 instructions of H or D or
emulating them in the wrong order.
You may call it a "diagnostic criterion" or just a "criterion" but
it does not define anything. Whether it is clear or sufficient is
another problem.
For over two years I had two dozen people unified in consensus
continue to insist that a correct simulation of D by H did not
require emulating the x86 machine language instructions of D
correctly or in the correct order specified by D.
On 5/25/2024 7:54 AM, Richard Damon wrote:
On 5/25/24 8:09 AM, olcott wrote:This is all explained in my reply to Mike.
On 5/25/2024 3:14 AM, Mikko wrote:
On 2024-05-24 17:13:05 +0000, olcott said:
On 5/24/2024 3:58 AM, Mikko wrote:
On 2024-05-23 13:18:02 +0000, olcott said:
On 5/23/2024 5:06 AM, Mikko wrote:
On 2024-05-22 14:51:50 +0000, olcott said:
On 5/22/2024 2:39 AM, Mikko wrote:
On 2024-05-21 13:54:09 +0000, olcott said:
You are asking for the definition of correct simulation
that I have been providing for quite a while recently.
That was not my main intent. I wanted to know why your
statement
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.
exludes every unsimulated or incorrectly simulated D?
That sounds like Richard that assumed that incorrect answers >>>>>>>>> are OK
unless I specifically say that incorrect answers are not OK.
Maybe but I don't promise that the response to the incorrect answer >>>>>>>> will sound the same.
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).
A c function is correctly simulated when its machine language >>>>>>>>>>> instructions are emulated with an x86 emulator in the order >>>>>>>>>>> that they are specified by the x86 machine language of this >>>>>>>>>>> c function.
Does "its machine language instructions" mean all executed >>>>>>>>>> instructions
until the progam terminates? Or from the start of the program >>>>>>>>>> until
there is no reason to continue? Or from some point to some >>>>>>>>>> other point?
It means that 1 to N instructions of D are correctly simulated >>>>>>>>> by pure function H. Because D correctly simulated by H remains >>>>>>>>> stuck in recursive simulation D cannot possibly reach is own >>>>>>>>> line 06 and halt.
If you mean that H cannot simulate D to the line 06 then say so. >>>>>>>> A D that is simulated by H is D and so is a D that is not simulated >>>>>>>> by H so both can do what a D can do. Saying "simulated by H" adds >>>>>>>> nothing.
For non-terminating functions we can only correctly
simulate N machine language instructions.
But does you definition regard that partial simulation as
"correct
simulation"?
When 1 to 2^64 instructions of D are correctly simulated by H >>>>>>>>> it becomes clear that for every H/D pair of the infinite set >>>>>>>>> of H/D pairs D correctly simulated by H remains stuck in recursive >>>>>>>>> simulation.
If you think that the meaning of "correctly simulate" is not
important you should not use those words.
I must use those words or a standard of incorrect simulation
is assumed.
There is no "standard of incorrect simulation".
We have been going over the term "correct simulation"
in these forums with dozens of people and hundreds of messages
over several years.
That alone is a sufficient reaston to avoid the expression.
CORRECT SIMULATION DEFINED
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.
That is not a definition but perhaps a suffient substitute for
paractical
purposes.
It provides a clear and correct criterion measure to utterly
refute each and every reviewer that tries to get away with
the incorrect emulation of the x86 instructions of H or D or
emulating them in the wrong order.
You may call it a "diagnostic criterion" or just a "criterion" but
it does not define anything. Whether it is clear or sufficient is
another problem.
For over two years I had two dozen people unified in consensus
continue to insist that a correct simulation of D by H did not
require emulating the x86 machine language instructions of D
correctly or in the correct order specified by D.
WHERE?
If you want to talk about it there
(1) Do not link to comp.theory
(2) Do not talk about anything outside the scope of
the semantics of c
(3) Do not talk about anything outside the scope of the subject
of the thread:
[D correctly simulated by pure function H cannot
possibly reach its own line 06]
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv2t859%242vna0%241%40dont-email.me%3E
On 5/25/2024 1:16 PM, Richard Damon wrote:
On 5/25/24 2:03 PM, olcott wrote:
On 5/25/2024 7:54 AM, Richard Damon wrote:
On 5/25/24 8:09 AM, olcott wrote:This is all explained in my reply to Mike.
On 5/25/2024 3:14 AM, Mikko wrote:
On 2024-05-24 17:13:05 +0000, olcott said:
On 5/24/2024 3:58 AM, Mikko wrote:
On 2024-05-23 13:18:02 +0000, olcott said:
On 5/23/2024 5:06 AM, Mikko wrote:
On 2024-05-22 14:51:50 +0000, olcott said:
On 5/22/2024 2:39 AM, Mikko wrote:Maybe but I don't promise that the response to the incorrect >>>>>>>>>> answer
On 2024-05-21 13:54:09 +0000, olcott said:
You are asking for the definition of correct simulation >>>>>>>>>>>>> that I have been providing for quite a while recently. >>>>>>>>>>>>That was not my main intent. I wanted to know why your >>>>>>>>>>>> statement
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.
exludes every unsimulated or incorrectly simulated D?
That sounds like Richard that assumed that incorrect answers >>>>>>>>>>> are OK
unless I specifically say that incorrect answers are not OK. >>>>>>>>>>
will sound the same.
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). >>>>>>>>>>>
A c function is correctly simulated when its machine language >>>>>>>>>>>>> instructions are emulated with an x86 emulator in the order >>>>>>>>>>>>> that they are specified by the x86 machine language of this >>>>>>>>>>>>> c function.
Does "its machine language instructions" mean all executed >>>>>>>>>>>> instructions
until the progam terminates? Or from the start of the
program until
there is no reason to continue? Or from some point to some >>>>>>>>>>>> other point?
It means that 1 to N instructions of D are correctly simulated >>>>>>>>>>> by pure function H. Because D correctly simulated by H remains >>>>>>>>>>> stuck in recursive simulation D cannot possibly reach is own >>>>>>>>>>> line 06 and halt.
If you mean that H cannot simulate D to the line 06 then say so. >>>>>>>>>> A D that is simulated by H is D and so is a D that is not
simulated
by H so both can do what a D can do. Saying "simulated by H" adds >>>>>>>>>> nothing.
For non-terminating functions we can only correctly
simulate N machine language instructions.
But does you definition regard that partial simulation as >>>>>>>>>>>> "correct
simulation"?
When 1 to 2^64 instructions of D are correctly simulated by H >>>>>>>>>>> it becomes clear that for every H/D pair of the infinite set >>>>>>>>>>> of H/D pairs D correctly simulated by H remains stuck in >>>>>>>>>>> recursive
simulation.
If you think that the meaning of "correctly simulate" is not >>>>>>>>>> important you should not use those words.
I must use those words or a standard of incorrect simulation >>>>>>>>> is assumed.
There is no "standard of incorrect simulation".
We have been going over the term "correct simulation"
in these forums with dozens of people and hundreds of messages >>>>>>>>> over several years.
That alone is a sufficient reaston to avoid the expression.
CORRECT SIMULATION DEFINED
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.
That is not a definition but perhaps a suffient substitute for >>>>>>>> paractical
purposes.
It provides a clear and correct criterion measure to utterly
refute each and every reviewer that tries to get away with
the incorrect emulation of the x86 instructions of H or D or
emulating them in the wrong order.
You may call it a "diagnostic criterion" or just a "criterion" but >>>>>> it does not define anything. Whether it is clear or sufficient is
another problem.
For over two years I had two dozen people unified in consensus
continue to insist that a correct simulation of D by H did not
require emulating the x86 machine language instructions of D
correctly or in the correct order specified by D.
WHERE?
If you want to talk about it there
(1) Do not link to comp.theory
(2) Do not talk about anything outside the scope of
the semantics of c
(3) Do not talk about anything outside the scope of the subject
of the thread:
[D correctly simulated by pure function H cannot
possibly reach its own line 06]
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv2t859%242vna0%241%40dont-email.me%3E
And where in that statement did anyone say that the correct simulation
of D by H did not require the simulation of the instructions of D
correctly or in the correct order specifid byu D.
*Go look and see for yourself*
*Go look and see for yourself*
*Go look and see for yourself*
*Go look and see for yourself*
On 5/25/2024 2:23 PM, Richard Damon wrote:
On 5/25/24 2:28 PM, olcott wrote:
On 5/25/2024 1:16 PM, Richard Damon wrote:
On 5/25/24 2:03 PM, olcott wrote:
On 5/25/2024 7:54 AM, Richard Damon wrote:
On 5/25/24 8:09 AM, olcott wrote:This is all explained in my reply to Mike.
On 5/25/2024 3:14 AM, Mikko wrote:
On 2024-05-24 17:13:05 +0000, olcott said:
On 5/24/2024 3:58 AM, Mikko wrote:
On 2024-05-23 13:18:02 +0000, olcott said:
On 5/23/2024 5:06 AM, Mikko wrote:
On 2024-05-22 14:51:50 +0000, olcott said:
On 5/22/2024 2:39 AM, Mikko wrote:Maybe but I don't promise that the response to the incorrect >>>>>>>>>>>> answer
On 2024-05-21 13:54:09 +0000, olcott said:That sounds like Richard that assumed that incorrect >>>>>>>>>>>>> answers are OK
You are asking for the definition of correct simulation >>>>>>>>>>>>>>> that I have been providing for quite a while recently. >>>>>>>>>>>>>>That was not my main intent. I wanted to know why your >>>>>>>>>>>>>> statement
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.
exludes every unsimulated or incorrectly simulated D? >>>>>>>>>>>>>
unless I specifically say that incorrect answers are not OK. >>>>>>>>>>>>
will sound the same.
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). >>>>>>>>>>>>>
A c function is correctly simulated when its machine >>>>>>>>>>>>>>> language
instructions are emulated with an x86 emulator in the order >>>>>>>>>>>>>>> that they are specified by the x86 machine language of this >>>>>>>>>>>>>>> c function.
Does "its machine language instructions" mean all executed >>>>>>>>>>>>>> instructions
until the progam terminates? Or from the start of the >>>>>>>>>>>>>> program until
there is no reason to continue? Or from some point to some >>>>>>>>>>>>>> other point?
It means that 1 to N instructions of D are correctly simulated >>>>>>>>>>>>> by pure function H. Because D correctly simulated by H remains >>>>>>>>>>>>> stuck in recursive simulation D cannot possibly reach is own >>>>>>>>>>>>> line 06 and halt.
If you mean that H cannot simulate D to the line 06 then say >>>>>>>>>>>> so.
A D that is simulated by H is D and so is a D that is not >>>>>>>>>>>> simulated
by H so both can do what a D can do. Saying "simulated by H" >>>>>>>>>>>> adds
nothing.
For non-terminating functions we can only correctly >>>>>>>>>>>>>>> simulate N machine language instructions.
But does you definition regard that partial simulation as >>>>>>>>>>>>>> "correct
simulation"?
When 1 to 2^64 instructions of D are correctly simulated by H >>>>>>>>>>>>> it becomes clear that for every H/D pair of the infinite set >>>>>>>>>>>>> of H/D pairs D correctly simulated by H remains stuck in >>>>>>>>>>>>> recursive
simulation.
If you think that the meaning of "correctly simulate" is not >>>>>>>>>>>> important you should not use those words.
I must use those words or a standard of incorrect simulation >>>>>>>>>>> is assumed.
There is no "standard of incorrect simulation".
We have been going over the term "correct simulation"
in these forums with dozens of people and hundreds of messages >>>>>>>>>>> over several years.
That alone is a sufficient reaston to avoid the expression. >>>>>>>>>>
CORRECT SIMULATION DEFINED
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.
That is not a definition but perhaps a suffient substitute for >>>>>>>>>> paractical
purposes.
It provides a clear and correct criterion measure to utterly >>>>>>>>> refute each and every reviewer that tries to get away with
the incorrect emulation of the x86 instructions of H or D or >>>>>>>>> emulating them in the wrong order.
You may call it a "diagnostic criterion" or just a "criterion" but >>>>>>>> it does not define anything. Whether it is clear or sufficient is >>>>>>>> another problem.
For over two years I had two dozen people unified in consensus
continue to insist that a correct simulation of D by H did not
require emulating the x86 machine language instructions of D
correctly or in the correct order specified by D.
WHERE?
If you want to talk about it there
(1) Do not link to comp.theory
(2) Do not talk about anything outside the scope of
the semantics of c
(3) Do not talk about anything outside the scope of the subject
of the thread:
[D correctly simulated by pure function H cannot
possibly reach its own line 06]
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv2t859%242vna0%241%40dont-email.me%3E
And where in that statement did anyone say that the correct
simulation of D by H did not require the simulation of the
instructions of D correctly or in the correct order specifid byu D.
*Go look and see for yourself*
*Go look and see for yourself*
*Go look and see for yourself*
*Go look and see for yourself*
I did. I didn't see ANY mention of anything like what you claim.
When I read and reread the message a few more times I found that
I did not directly respond to exactly what Mike said so I corrected
this error with this additional reply:
On 5/25/2024 2:41 PM, olcott wrote: http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv2tesk%2430u1r%241%40dont-email.me%3E
I guess this is just another case of Olcott lying about what someone
else has done to try to justify himself.
You are just proven to be an ignorant pathological liar.
I had to read and reread his reply a few times before I totally
understood exactly what he said.
For over two years I had two dozen people unified in consensus
continue to insist that a correct simulation of D by H did not
require emulating the x86 machine language instructions of D
correctly or in the correct order specified by D.
On 5/25/2024 3:14 AM, Mikko wrote:
On 2024-05-24 17:13:05 +0000, olcott said:
On 5/24/2024 3:58 AM, Mikko wrote:
On 2024-05-23 13:18:02 +0000, olcott said:
On 5/23/2024 5:06 AM, Mikko wrote:
On 2024-05-22 14:51:50 +0000, olcott said:
On 5/22/2024 2:39 AM, Mikko wrote:
On 2024-05-21 13:54:09 +0000, olcott said:
You are asking for the definition of correct simulation
that I have been providing for quite a while recently.
That was not my main intent. I wanted to know why your
statement
exludes every unsimulated or incorrectly simulated D?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. >>>>>>>>
That sounds like Richard that assumed that incorrect answers are OK >>>>>>> unless I specifically say that incorrect answers are not OK.
Maybe but I don't promise that the response to the incorrect answer >>>>>> will sound the same.
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).
A c function is correctly simulated when its machine language >>>>>>>>> instructions are emulated with an x86 emulator in the order
that they are specified by the x86 machine language of this
c function.
Does "its machine language instructions" mean all executed instructions
until the progam terminates? Or from the start of the program until >>>>>>>> there is no reason to continue? Or from some point to some other point?
It means that 1 to N instructions of D are correctly simulated
by pure function H. Because D correctly simulated by H remains
stuck in recursive simulation D cannot possibly reach is own
line 06 and halt.
If you mean that H cannot simulate D to the line 06 then say so.
A D that is simulated by H is D and so is a D that is not simulated >>>>>> by H so both can do what a D can do. Saying "simulated by H" adds
nothing.
For non-terminating functions we can only correctly
simulate N machine language instructions.
But does you definition regard that partial simulation as "correct >>>>>>>> simulation"?
When 1 to 2^64 instructions of D are correctly simulated by H
it becomes clear that for every H/D pair of the infinite set
of H/D pairs D correctly simulated by H remains stuck in recursive >>>>>>> simulation.
If you think that the meaning of "correctly simulate" is not
important you should not use those words.
I must use those words or a standard of incorrect simulation
is assumed.
There is no "standard of incorrect simulation".
We have been going over the term "correct simulation"
in these forums with dozens of people and hundreds of messages
over several years.
That alone is a sufficient reaston to avoid the expression.
CORRECT SIMULATION DEFINED
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.
That is not a definition but perhaps a suffient substitute for paractical >>>> purposes.
It provides a clear and correct criterion measure to utterly
refute each and every reviewer that tries to get away with
the incorrect emulation of the x86 instructions of H or D or
emulating them in the wrong order.
You may call it a "diagnostic criterion" or just a "criterion" but
it does not define anything. Whether it is clear or sufficient is
another problem.
For over two years I had two dozen people unified in consensus
continue to insist that a correct simulation of D by H did not
require emulating the x86 machine language instructions of D
correctly or in the correct order specified by D.
On 5/26/2024 3:57 AM, Mikko wrote:
On 2024-05-25 12:09:18 +0000, olcott said:
On 5/25/2024 3:14 AM, Mikko wrote:
On 2024-05-24 17:13:05 +0000, olcott said:
On 5/24/2024 3:58 AM, Mikko wrote:
On 2024-05-23 13:18:02 +0000, olcott said:
On 5/23/2024 5:06 AM, Mikko wrote:
On 2024-05-22 14:51:50 +0000, olcott said:
On 5/22/2024 2:39 AM, Mikko wrote:
On 2024-05-21 13:54:09 +0000, olcott said:
You are asking for the definition of correct simulation
that I have been providing for quite a while recently.
That was not my main intent. I wanted to know why your
statement
exludes every unsimulated or incorrectly simulated D?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. >>>>>>>>>>
That sounds like Richard that assumed that incorrect answers are OK >>>>>>>>> unless I specifically say that incorrect answers are not OK.
Maybe but I don't promise that the response to the incorrect answer >>>>>>>> will sound the same.
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).
A c function is correctly simulated when its machine language >>>>>>>>>>> instructions are emulated with an x86 emulator in the order >>>>>>>>>>> that they are specified by the x86 machine language of this >>>>>>>>>>> c function.
Does "its machine language instructions" mean all executed instructions
until the progam terminates? Or from the start of the program until >>>>>>>>>> there is no reason to continue? Or from some point to some other point?
It means that 1 to N instructions of D are correctly simulated >>>>>>>>> by pure function H. Because D correctly simulated by H remains >>>>>>>>> stuck in recursive simulation D cannot possibly reach is own >>>>>>>>> line 06 and halt.
If you mean that H cannot simulate D to the line 06 then say so. >>>>>>>> A D that is simulated by H is D and so is a D that is not simulated >>>>>>>> by H so both can do what a D can do. Saying "simulated by H" adds >>>>>>>> nothing.
For non-terminating functions we can only correctly
simulate N machine language instructions.
But does you definition regard that partial simulation as "correct >>>>>>>>>> simulation"?
When 1 to 2^64 instructions of D are correctly simulated by H >>>>>>>>> it becomes clear that for every H/D pair of the infinite set >>>>>>>>> of H/D pairs D correctly simulated by H remains stuck in recursive >>>>>>>>> simulation.
If you think that the meaning of "correctly simulate" is not
important you should not use those words.
I must use those words or a standard of incorrect simulation
is assumed.
There is no "standard of incorrect simulation".
We have been going over the term "correct simulation"
in these forums with dozens of people and hundreds of messages
over several years.
That alone is a sufficient reaston to avoid the expression.
CORRECT SIMULATION DEFINED
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.
That is not a definition but perhaps a suffient substitute for paractical
purposes.
It provides a clear and correct criterion measure to utterly
refute each and every reviewer that tries to get away with
the incorrect emulation of the x86 instructions of H or D or
emulating them in the wrong order.
You may call it a "diagnostic criterion" or just a "criterion" but
it does not define anything. Whether it is clear or sufficient is
another problem.
For over two years I had two dozen people unified in consensus
continue to insist that a correct simulation of D by H did not
require emulating the x86 machine language instructions of D
correctly or in the correct order specified by D.
Is the disagreement about the meaning of "correct" or "simulation"
or some other word, or is the disagreement about correctness of the
simulation?
A simulator is an x86 emulator that correctly emulates 1 to N of the
x86 instructions of D in the order specified by the x86 instructions
of D. This may include M recursive emulations of H emulating itself
emulating D.
People disagree with the above definition.
They believe that a correct
simulation requires H to report on the computation that itself is
contained within:
On 5/26/2024 3:57 AM, Mikko wrote:
On 2024-05-25 12:09:18 +0000, olcott said:
On 5/25/2024 3:14 AM, Mikko wrote:
On 2024-05-24 17:13:05 +0000, olcott said:
On 5/24/2024 3:58 AM, Mikko wrote:
On 2024-05-23 13:18:02 +0000, olcott said:
On 5/23/2024 5:06 AM, Mikko wrote:
On 2024-05-22 14:51:50 +0000, olcott said:
On 5/22/2024 2:39 AM, Mikko wrote:
On 2024-05-21 13:54:09 +0000, olcott said:
You are asking for the definition of correct simulation
that I have been providing for quite a while recently.
That was not my main intent. I wanted to know why your
statement
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.
exludes every unsimulated or incorrectly simulated D?
That sounds like Richard that assumed that incorrect answers >>>>>>>>> are OK
unless I specifically say that incorrect answers are not OK.
Maybe but I don't promise that the response to the incorrect answer >>>>>>>> will sound the same.
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).
A c function is correctly simulated when its machine language >>>>>>>>>>> instructions are emulated with an x86 emulator in the order >>>>>>>>>>> that they are specified by the x86 machine language of this >>>>>>>>>>> c function.
Does "its machine language instructions" mean all executed >>>>>>>>>> instructions
until the progam terminates? Or from the start of the program >>>>>>>>>> until
there is no reason to continue? Or from some point to some >>>>>>>>>> other point?
It means that 1 to N instructions of D are correctly simulated >>>>>>>>> by pure function H. Because D correctly simulated by H remains >>>>>>>>> stuck in recursive simulation D cannot possibly reach is own >>>>>>>>> line 06 and halt.
If you mean that H cannot simulate D to the line 06 then say so. >>>>>>>> A D that is simulated by H is D and so is a D that is not simulated >>>>>>>> by H so both can do what a D can do. Saying "simulated by H" adds >>>>>>>> nothing.
For non-terminating functions we can only correctly
simulate N machine language instructions.
But does you definition regard that partial simulation as
"correct
simulation"?
When 1 to 2^64 instructions of D are correctly simulated by H >>>>>>>>> it becomes clear that for every H/D pair of the infinite set >>>>>>>>> of H/D pairs D correctly simulated by H remains stuck in recursive >>>>>>>>> simulation.
If you think that the meaning of "correctly simulate" is not
important you should not use those words.
I must use those words or a standard of incorrect simulation
is assumed.
There is no "standard of incorrect simulation".
We have been going over the term "correct simulation"
in these forums with dozens of people and hundreds of messages
over several years.
That alone is a sufficient reaston to avoid the expression.
CORRECT SIMULATION DEFINED
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.
That is not a definition but perhaps a suffient substitute for
paractical
purposes.
It provides a clear and correct criterion measure to utterly
refute each and every reviewer that tries to get away with
the incorrect emulation of the x86 instructions of H or D or
emulating them in the wrong order.
You may call it a "diagnostic criterion" or just a "criterion" but
it does not define anything. Whether it is clear or sufficient is
another problem.
For over two years I had two dozen people unified in consensus
continue to insist that a correct simulation of D by H did not
require emulating the x86 machine language instructions of D
correctly or in the correct order specified by D.
Is the disagreement about the meaning of "correct" or "simulation"
or some other word, or is the disagreement about correctness of the
simulation?
A simulator is an x86 emulator that correctly emulates 1 to N of the
x86 instructions of D in the order specified by the x86 instructions
of D. This may include M recursive emulations of H emulating itself
emulating D.
People disagree with the above definition. They believe that a correct simulation requires H to report on the computation that itself is
contained within:
int main() { D(D); }
even though this requires simulating the x86 instructions specified by D incorrectly or and/or in the incorrect order.
On 5/26/2024 11:19 AM, Mikko wrote:
On 2024-05-26 13:32:08 +0000, olcott said:
On 5/26/2024 3:57 AM, Mikko wrote:
On 2024-05-25 12:09:18 +0000, olcott said:
On 5/25/2024 3:14 AM, Mikko wrote:
On 2024-05-24 17:13:05 +0000, olcott said:
On 5/24/2024 3:58 AM, Mikko wrote:
On 2024-05-23 13:18:02 +0000, olcott said:
On 5/23/2024 5:06 AM, Mikko wrote:
On 2024-05-22 14:51:50 +0000, olcott said:
On 5/22/2024 2:39 AM, Mikko wrote:Maybe but I don't promise that the response to the incorrect >>>>>>>>>> answer
On 2024-05-21 13:54:09 +0000, olcott said:
You are asking for the definition of correct simulation >>>>>>>>>>>>> that I have been providing for quite a while recently. >>>>>>>>>>>>That was not my main intent. I wanted to know why your >>>>>>>>>>>> statement
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.
exludes every unsimulated or incorrectly simulated D?
That sounds like Richard that assumed that incorrect answers >>>>>>>>>>> are OK
unless I specifically say that incorrect answers are not OK. >>>>>>>>>>
will sound the same.
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). >>>>>>>>>>>
A c function is correctly simulated when its machine language >>>>>>>>>>>>> instructions are emulated with an x86 emulator in the order >>>>>>>>>>>>> that they are specified by the x86 machine language of this >>>>>>>>>>>>> c function.
Does "its machine language instructions" mean all executed >>>>>>>>>>>> instructions
until the progam terminates? Or from the start of the
program until
there is no reason to continue? Or from some point to some >>>>>>>>>>>> other point?
It means that 1 to N instructions of D are correctly simulated >>>>>>>>>>> by pure function H. Because D correctly simulated by H remains >>>>>>>>>>> stuck in recursive simulation D cannot possibly reach is own >>>>>>>>>>> line 06 and halt.
If you mean that H cannot simulate D to the line 06 then say so. >>>>>>>>>> A D that is simulated by H is D and so is a D that is not
simulated
by H so both can do what a D can do. Saying "simulated by H" adds >>>>>>>>>> nothing.
For non-terminating functions we can only correctly
simulate N machine language instructions.
But does you definition regard that partial simulation as >>>>>>>>>>>> "correct
simulation"?
When 1 to 2^64 instructions of D are correctly simulated by H >>>>>>>>>>> it becomes clear that for every H/D pair of the infinite set >>>>>>>>>>> of H/D pairs D correctly simulated by H remains stuck in >>>>>>>>>>> recursive
simulation.
If you think that the meaning of "correctly simulate" is not >>>>>>>>>> important you should not use those words.
I must use those words or a standard of incorrect simulation >>>>>>>>> is assumed.
There is no "standard of incorrect simulation".
We have been going over the term "correct simulation"
in these forums with dozens of people and hundreds of messages >>>>>>>>> over several years.
That alone is a sufficient reaston to avoid the expression.
CORRECT SIMULATION DEFINED
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.
That is not a definition but perhaps a suffient substitute for >>>>>>>> paractical
purposes.
It provides a clear and correct criterion measure to utterly
refute each and every reviewer that tries to get away with
the incorrect emulation of the x86 instructions of H or D or
emulating them in the wrong order.
You may call it a "diagnostic criterion" or just a "criterion" but >>>>>> it does not define anything. Whether it is clear or sufficient is
another problem.
For over two years I had two dozen people unified in consensus
continue to insist that a correct simulation of D by H did not
require emulating the x86 machine language instructions of D
correctly or in the correct order specified by D.
Is the disagreement about the meaning of "correct" or "simulation"
or some other word, or is the disagreement about correctness of the
simulation?
A simulator is an x86 emulator that correctly emulates 1 to N of the >>> x86 instructions of D in the order specified by the x86 instructions >>> of D. This may include M recursive emulations of H emulating itself >>> emulating D.
People disagree with the above definition.
Then you may ask what other word would be better instead of "simulator".
They believe that a correct
simulation requires H to report on the computation that itself is
contained within:
Why should the term "simulation" imply anything about reporting?
There you go an actual mistake that I made.
I will phrase what I mean more accurately.
Everyone reviewing my work agrees that D correctly simulated by H should simulate the behavior of the directly executed D(D) thus not the actual behavior of D correctly simulated by pure function H.
When we see that D correctly simulated by pure simulator H would remain
stuck in recursive simulation then we also know that D never reaches its
own line 06 and halts in less than an infinite number of correctly
simulated steps.
This means that D correctly simulated by pure function H also never
reaches it own line 06 and halts.
On 5/26/2024 11:19 AM, Mikko wrote:
On 2024-05-26 13:32:08 +0000, olcott said:
On 5/26/2024 3:57 AM, Mikko wrote:
On 2024-05-25 12:09:18 +0000, olcott said:
On 5/25/2024 3:14 AM, Mikko wrote:
On 2024-05-24 17:13:05 +0000, olcott said:
On 5/24/2024 3:58 AM, Mikko wrote:
On 2024-05-23 13:18:02 +0000, olcott said:
On 5/23/2024 5:06 AM, Mikko wrote:
On 2024-05-22 14:51:50 +0000, olcott said:
On 5/22/2024 2:39 AM, Mikko wrote:Maybe but I don't promise that the response to the incorrect answer >>>>>>>>>> will sound the same.
On 2024-05-21 13:54:09 +0000, olcott said:
You are asking for the definition of correct simulation >>>>>>>>>>>>> that I have been providing for quite a while recently. >>>>>>>>>>>>That was not my main intent. I wanted to know why your >>>>>>>>>>>> statement
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.
exludes every unsimulated or incorrectly simulated D?
That sounds like Richard that assumed that incorrect answers are OK >>>>>>>>>>> unless I specifically say that incorrect answers are not OK. >>>>>>>>>>
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). >>>>>>>>>>>
A c function is correctly simulated when its machine language >>>>>>>>>>>>> instructions are emulated with an x86 emulator in the order >>>>>>>>>>>>> that they are specified by the x86 machine language of this >>>>>>>>>>>>> c function.
Does "its machine language instructions" mean all executed instructions
until the progam terminates? Or from the start of the program until
there is no reason to continue? Or from some point to some other point?
It means that 1 to N instructions of D are correctly simulated >>>>>>>>>>> by pure function H. Because D correctly simulated by H remains >>>>>>>>>>> stuck in recursive simulation D cannot possibly reach is own >>>>>>>>>>> line 06 and halt.
If you mean that H cannot simulate D to the line 06 then say so. >>>>>>>>>> A D that is simulated by H is D and so is a D that is not simulated >>>>>>>>>> by H so both can do what a D can do. Saying "simulated by H" adds >>>>>>>>>> nothing.
For non-terminating functions we can only correctly
simulate N machine language instructions.
But does you definition regard that partial simulation as "correct >>>>>>>>>>>> simulation"?
When 1 to 2^64 instructions of D are correctly simulated by H >>>>>>>>>>> it becomes clear that for every H/D pair of the infinite set >>>>>>>>>>> of H/D pairs D correctly simulated by H remains stuck in recursive >>>>>>>>>>> simulation.
If you think that the meaning of "correctly simulate" is not >>>>>>>>>> important you should not use those words.
I must use those words or a standard of incorrect simulation >>>>>>>>> is assumed.
There is no "standard of incorrect simulation".
We have been going over the term "correct simulation"
in these forums with dozens of people and hundreds of messages >>>>>>>>> over several years.
That alone is a sufficient reaston to avoid the expression.
CORRECT SIMULATION DEFINED
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.
That is not a definition but perhaps a suffient substitute for paractical
purposes.
It provides a clear and correct criterion measure to utterly
refute each and every reviewer that tries to get away with
the incorrect emulation of the x86 instructions of H or D or
emulating them in the wrong order.
You may call it a "diagnostic criterion" or just a "criterion" but >>>>>> it does not define anything. Whether it is clear or sufficient is
another problem.
For over two years I had two dozen people unified in consensus
continue to insist that a correct simulation of D by H did not
require emulating the x86 machine language instructions of D
correctly or in the correct order specified by D.
Is the disagreement about the meaning of "correct" or "simulation"
or some other word, or is the disagreement about correctness of the
simulation?
A simulator is an x86 emulator that correctly emulates 1 to N of the >>> x86 instructions of D in the order specified by the x86 instructions >>> of D. This may include M recursive emulations of H emulating itself >>> emulating D.
People disagree with the above definition.
Then you may ask what other word would be better instead of "simulator".
They believe that a correct
simulation requires H to report on the computation that itself is
contained within:
Why should the term "simulation" imply anything about reporting?
There you go an actual mistake that I made.
I will phrase what I mean more accurately.
Everyone reviewing my work agrees that D correctly simulated by H should simulate the behavior of the directly executed D(D) thus not the actual behavior of D correctly simulated by pure function H.
When we see that D correctly simulated by pure simulator H would remain
stuck in recursive simulation then we also know that D never reaches its
own line 06 and halts in less than an infinite number of correctly
simulated steps.
This means that D correctly simulated by pure function H also never
reaches it own line 06 and halts.
On 5/27/2024 3:11 AM, Mikko wrote:
On 2024-05-26 16:50:21 +0000, olcott said:
<snip>
So that: *Usenet Article Lookup*
http://al.howardknight.net/
can see the whole message now that
*the Thai spammer killed Google Groups*
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 }
When we see that D correctly simulated by pure simulator H would remain
stuck in recursive simulation then we also know that D never reaches its >>> own line 06 and halts in less than an infinite number of correctly
simulated steps.
Which means that H never terminates. You said that by your definition
a function that never terminates is not a pure function. Therefore
H, if it exists, is not a pure function, and the phrase "pure function
H" does not denote.
*I should have said that more clearly*
*That is why I need reviewers*
*Here it is more clearly*
When we hypothesize that H is a pure simulator we see that D correctly simulated by pure simulator H remains stuck in recursive simulation thus never reaches its own simulated final state at its line 06 and halts. In
this case H does not halt, thus is neither a pure function nor a
decider.
From this we correctly conclude that D correctly simulated by pure
function H never reaches its simulated final state at its own line 06
and halts in Less than an infinite (AKA finite) number of simulated
steps. Here is a concrete example of that:
https://en.wikipedia.org/wiki/Googolplex
When pure function H correctly simulates a Googolplex ^ Googolplex
number of steps of D, then D never reaches its simulated final state
at its own line 06 and halts. Pure function H halts after this finite
number of steps of correct simulation.
In other words when the *INPUT* to H(D,D) is correctly simulated by
either pure simulator H or pure function H this correctly simulated
*INPUT* never halts no matter what, thus the INPUT to H(D,D) is
definitely non halting.
*This is STEP ONE of my four step proof*
STEP TWO applies these same ideas to the Peter Linz HP proof.
STEP THREE shows how the Linz Ĥ.H sees the behavior of its recursive
simulations.
STEP FOUR shows why the behavior of the INPUT is the correct basis.
On 5/27/2024 9:10 AM, Richard Damon wrote:
On 5/27/24 9:52 AM, olcott wrote:
On 5/27/2024 3:11 AM, Mikko wrote:
On 2024-05-26 16:50:21 +0000, olcott said:
<snip>
So that: *Usenet Article Lookup*
http://al.howardknight.net/
can see the whole message now that
*the Thai spammer killed Google Groups*
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 }
When we see that D correctly simulated by pure simulator H would
remain
stuck in recursive simulation then we also know that D never
reaches its
own line 06 and halts in less than an infinite number of correctly
simulated steps.
Which means that H never terminates. You said that by your definition
a function that never terminates is not a pure function. Therefore
H, if it exists, is not a pure function, and the phrase "pure function >>>> H" does not denote.
*I should have said that more clearly*
*That is why I need reviewers*
*Here it is more clearly*
When we hypothesize that H is a pure simulator we see that D correctly
simulated by pure simulator H remains stuck in recursive simulation thus >>> never reaches its own simulated final state at its line 06 and halts. In >>> this case H does not halt, thus is neither a pure function nor a
decider.
But when you hypothesize that H is actually a "pure simulator"
(presumably one that never aborts) then you are creating a D that uses
that pure simulator, and are ONLY deriving conclusions for such a D.
When D correctly simulated by pure simulator H cannot possibly reach
its own simulated final state at line 06 and halt in an infinite number
of simulated steps we can conclude that less than an infinite number of
steps is also not enough steps for D to halt.
On 5/27/2024 9:58 AM, Richard Damon wrote:
On 5/27/24 10:39 AM, olcott wrote:
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 }
The above template refers to an infinite set of H/D pairs where D is correctly simulated by either pure simulator H or pure function H. This
was done because many reviewers used the shell game ploy to endlessly
switch which H/D pair was being referred to.
Correct Simulation Defined
This is provided because many reviewers had a different notion of
correct simulation that diverges from this notion.
A simulator is an x86 emulator that correctly emulates 1 to N of the
x86 instructions of D in the order specified by the x86 instructions
of D. This may include M recursive emulations of H emulating itself
emulating D.
When we see that D correctly simulated by pure simulator H would remain
stuck in infinite recursive simulation then we also know that less than
an infinite number of steps is not enough steps for D correctly
simulated by pure function H to reach its own simulated final state at
line 06 and halt.
When D correctly simulated by pure simulator H cannot possibly reach
its own simulated final state at line 06 and halt in an infinite number
of simulated steps we can conclude that less than an infinite number of
steps is also not enough steps for D to halt.
But ONLY for THAT D, the one built on the pure simulator that never
aborts.
https://en.wikipedia.org/wiki/Shell_game
*I updated my words to address your persistent shell-game ploy*
The above template refers to an infinite set of H/D pairs where D is correctly simulated by either pure simulator H or pure function H. This
was done because many reviewers used the shell game ploy to endlessly
switch which H/D pair was being referred to.
On 5/27/2024 10:56 AM, Richard Damon wrote:
On 5/27/24 11:43 AM, olcott wrote:
On 5/27/2024 9:58 AM, Richard Damon wrote:
On 5/27/24 10:39 AM, olcott wrote:
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 }
The above template refers to an infinite set of H/D pairs where D is
correctly simulated by either pure simulator H or pure function H. This
was done because many reviewers used the shell game ploy to endlessly
switch which H/D pair was being referred to.
Correct Simulation Defined
This is provided because many reviewers had a different notion of >>> correct simulation that diverges from this notion.
A simulator is an x86 emulator that correctly emulates 1 to N of the >>> x86 instructions of D in the order specified by the x86 instructions >>> of D. This may include M recursive emulations of H emulating itself >>> emulating D.
And how do you apply that to a TEMPLATE that doesn't define what a
call H means
*It is completely defined and you are just ignoring this definition*
H correctly simulates 1 to ∞ steps of D with either pure function H
or pure simulator H. In none of these cases does the correctly simulated
D ever reach its own simulated final state and halt.
Do some of these instances of H play a game of poker with themselves
before or after they simulate D? Yes they do because the H/D pairs
are an infinite set.
On 5/27/2024 11:37 AM, Richard Damon wrote:
On 5/27/24 12:06 PM, olcott wrote:
On 5/27/2024 10:56 AM, Richard Damon wrote:
On 5/27/24 11:43 AM, olcott wrote:
On 5/27/2024 9:58 AM, Richard Damon wrote:
On 5/27/24 10:39 AM, olcott wrote:
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 }
The above template refers to an infinite set of H/D pairs where D is >>>>> correctly simulated by either pure simulator H or pure function H.
This
was done because many reviewers used the shell game ploy to endlessly >>>>> switch which H/D pair was being referred to.
Correct Simulation Defined
This is provided because many reviewers had a different notion of >>>>> correct simulation that diverges from this notion.
A simulator is an x86 emulator that correctly emulates 1 to N >>>>> of the
x86 instructions of D in the order specified by the x86
instructions
of D. This may include M recursive emulations of H emulating
itself
emulating D.
And how do you apply that to a TEMPLATE that doesn't define what a
call H means
*It is completely defined and you are just ignoring this definition*
So, what instruction does the call H in D go to to be simulated?
DISHONEST HEAD GAMES. WHEN WE APPLY THIS SAME REASONING TO THE
LINZ TEMPLATE YOUR REASONING CALLS THE LINZ TEMPLATE NONSENSE.
As a template, there is no fixed H, so no instruction to look at.
H correctly simulates 1 to ∞ steps of D with either pure function H
or pure simulator H. In none of these cases does the correctly simulated >>> D ever reach its own simulated final state and halt.
Do some of these instances of H play a game of poker with themselves
before or after they simulate D? Yes they do because the H/D pairs
are an infinite set.
But, how do they correctly simulate something that isn't there?
Either they are simulating an INSTANCE of the template, in which case
each H is looking at a DIFFERENT instance, and you can't relate one
result to the other, or they are trying to simulate the Template, at
which point you have the problem that the code to be simulated hasn't
been defined, and thus you can't do what you define to do.
I AM REFERRING TO THE EXACT SAME SORT OF INFINITE SET
THAT THE LINZ TEMPLATE IS REFERRING TO AND YOU KNOW IT.
WHEN EVERY ELEMENT OF AN INFINITE SET HAS THE SAME NON-HALTING
PROPERTY THEN YOUR SHELL GAME SWITCHEROO IS OBVIOUSLY A HEAD GAME.
IF YOU WOULDN'T HAVE TRIED TO GET AWAY WITH THIS FOR TWO SOLID
YEARS I WOULD NOT BE YELLING.
On 5/27/2024 4:34 PM, Richard Damon wrote:
On 5/27/24 3:52 PM, olcott wrote:
On 5/27/2024 11:37 AM, Richard Damon wrote:
On 5/27/24 12:06 PM, olcott wrote:
On 5/27/2024 10:56 AM, Richard Damon wrote:
On 5/27/24 11:43 AM, olcott wrote:
On 5/27/2024 9:58 AM, Richard Damon wrote:
On 5/27/24 10:39 AM, olcott wrote:
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 }
The above template refers to an infinite set of H/D pairs where D is >>>>>>> correctly simulated by either pure simulator H or pure function
H. This
was done because many reviewers used the shell game ploy to
endlessly
switch which H/D pair was being referred to.
Correct Simulation Defined
This is provided because many reviewers had a different
notion of
correct simulation that diverges from this notion.
A simulator is an x86 emulator that correctly emulates 1 to N >>>>>>> of the
x86 instructions of D in the order specified by the x86
instructions
of D. This may include M recursive emulations of H emulating >>>>>>> itself
emulating D.
And how do you apply that to a TEMPLATE that doesn't define what a >>>>>> call H means
*It is completely defined and you are just ignoring this definition*
So, what instruction does the call H in D go to to be simulated?
DISHONEST HEAD GAMES. WHEN WE APPLY THIS SAME REASONING TO THE
LINZ TEMPLATE YOUR REASONING CALLS THE LINZ TEMPLATE NONSENSE.
Nope, because Linz doesn't try to pass a Template to H, but the
machine built from the template H^.
As I said, if you assume the input is the machine built from the
template you get the ability to define the simulation, you just now
get every decider got a different input, so you can't just do the
logic across them.
YOU are the one trying to do dishonest head games
(And who has been saying that insults are unprofessional?)
As a template, there is no fixed H, so no instruction to look at.
H correctly simulates 1 to ∞ steps of D with either pure function H >>>>> or pure simulator H. In none of these cases does the correctly
simulated
D ever reach its own simulated final state and halt.
Do some of these instances of H play a game of poker with themselves >>>>> before or after they simulate D? Yes they do because the H/D pairs
are an infinite set.
But, how do they correctly simulate something that isn't there?
Either they are simulating an INSTANCE of the template, in which
case each H is looking at a DIFFERENT instance, and you can't relate
one result to the other, or they are trying to simulate the
Template, at which point you have the problem that the code to be
simulated hasn't been defined, and thus you can't do what you define
to do.
I AM REFERRING TO THE EXACT SAME SORT OF INFINITE SET
THAT THE LINZ TEMPLATE IS REFERRING TO AND YOU KNOW IT.
Nope, Linz choose A SPECIFIC H out of the set, and gives it a SPECIFIC
H^ built from that SPECIFIC H, and then works with that set. There is
When you say "specific machine" you don't mean anything like a
100% completely specified sequence of state transitions encoded
as a single unique finite string.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Linz claims that out of the infinite possible implementations of
embedded_H specified by the second ⊢* that none of them get the
right answer.
I would be pretty dumb if Linz took this the way the you are taking it: "there exists a specific implementation of embedded_H that gets the
wrong answer."
On 5/27/2024 3:11 AM, Mikko wrote:
On 2024-05-26 16:50:21 +0000, olcott said:
<snip>
So that: *Usenet Article Lookup*
http://al.howardknight.net/
can see the whole message now that
*the Thai spammer killed Google Groups*
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 }
When we see that D correctly simulated by pure simulator H would remain
stuck in recursive simulation then we also know that D never reaches its >>> own line 06 and halts in less than an infinite number of correctly
simulated steps.
Which means that H never terminates. You said that by your definition
a function that never terminates is not a pure function. Therefore
H, if it exists, is not a pure function, and the phrase "pure function
H" does not denote.
*I should have said that more clearly*
*That is why I need reviewers*
*This is STEP ONE of my four step proof*
STEP TWO applies these same ideas to the Peter Linz HP proof.
STEP THREE shows how the Linz Ĥ.H sees the behavior of its recursive
simulations.
STEP FOUR shows why the behavior of the INPUT is the correct basis.
On 5/27/2024 9:10 AM, Richard Damon wrote:
On 5/27/24 9:52 AM, olcott wrote:
On 5/27/2024 3:11 AM, Mikko wrote:
On 2024-05-26 16:50:21 +0000, olcott said:
<snip>
So that: *Usenet Article Lookup*
http://al.howardknight.net/
can see the whole message now that
*the Thai spammer killed Google Groups*
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 }
When we see that D correctly simulated by pure simulator H would
remain
stuck in recursive simulation then we also know that D never
reaches its
own line 06 and halts in less than an infinite number of correctly
simulated steps.
Which means that H never terminates. You said that by your definition
a function that never terminates is not a pure function. Therefore
H, if it exists, is not a pure function, and the phrase "pure function >>>> H" does not denote.
*I should have said that more clearly*
*That is why I need reviewers*
*Here it is more clearly*
When we hypothesize that H is a pure simulator we see that D correctly
simulated by pure simulator H remains stuck in recursive simulation thus >>> never reaches its own simulated final state at its line 06 and halts. In >>> this case H does not halt, thus is neither a pure function nor a
decider.
But when you hypothesize that H is actually a "pure simulator"
(presumably one that never aborts) then you are creating a D that uses
that pure simulator, and are ONLY deriving conclusions for such a D.
When D correctly simulated by pure simulator H cannot possibly reach
its own simulated final state at line 06 and halt in an infinite number
of simulated steps we can conclude that less than an infinite number of
steps is also not enough steps for D to halt.
On 5/27/2024 9:58 AM, Richard Damon wrote:
On 5/27/24 10:39 AM, olcott wrote:
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 }
The above template refers to an infinite set of H/D pairs where D is correctly simulated by either pure simulator H or pure function H. This
was done because many reviewers used the shell game ploy to endlessly
switch which H/D pair was being referred to.
Correct Simulation Defined
This is provided because many reviewers had a different notion of
correct simulation that diverges from this notion.
A simulator is an x86 emulator that correctly emulates 1 to N of the
x86 instructions of D in the order specified by the x86 instructions
of D. This may include M recursive emulations of H emulating itself
emulating D.
When we see that D correctly simulated by pure simulator H would remain
stuck in infinite recursive simulation then we also know that less than
an infinite number of steps is not enough steps for D correctly
simulated by pure function H to reach its own simulated final state at
line 06 and halt.
On 5/28/2024 4:21 AM, Fred. Zwarts wrote:
Op 27.mei.2024 om 17:43 schreef olcott:
On 5/27/2024 9:58 AM, Richard Damon wrote:
On 5/27/24 10:39 AM, olcott wrote:
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 }
The above template refers to an infinite set of H/D pairs where D is
correctly simulated by either pure simulator H or pure function H. This
was done because many reviewers used the shell game ploy to endlessly
switch which H/D pair was being referred to.
Correct Simulation Defined
This is provided because many reviewers had a different notion of >>> correct simulation that diverges from this notion.
A simulator is an x86 emulator that correctly emulates 1 to N of the >>> x86 instructions of D in the order specified by the x86 instructions >>> of D. This may include M recursive emulations of H emulating itself >>> emulating D.
When we see that D correctly simulated by pure simulator H would remain
stuck in infinite recursive simulation then we also know that less than
an infinite number of steps is not enough steps for D correctly
simulated by pure function H to reach its own simulated final state at
line 06 and halt.
We can equally well replace D with H.
Only if we want to use the DISHONEST DODGE STRAW-MAN DECEPTION CHANGE-THE-SUBJECT FAKE REBUTTAL.
My use of the point-by-pint basis of the Socratic method tosses
such attempts out as Trolling.
On 5/28/2024 2:17 AM, Mikko wrote:
On 2024-05-27 13:52:09 +0000, olcott said:
On 5/27/2024 3:11 AM, Mikko wrote:
On 2024-05-26 16:50:21 +0000, olcott said:
<snip>
So that: *Usenet Article Lookup*
http://al.howardknight.net/
can see the whole message now that
*the Thai spammer killed Google Groups*
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 }
When we see that D correctly simulated by pure simulator H would remain >>>>> stuck in recursive simulation then we also know that D never reaches its >>>>> own line 06 and halts in less than an infinite number of correctly
simulated steps.
Which means that H never terminates. You said that by your definition
a function that never terminates is not a pure function. Therefore
H, if it exists, is not a pure function, and the phrase "pure function >>>> H" does not denote.
*I should have said that more clearly*
*That is why I need reviewers*
What is said here has little significance. You should ask reviewer's
comments about your working draft that you maintain in GitHub or some
other web site. And you should update that draft when a reviewer finds
some something wrong or unclear.
*This is STEP ONE of my four step proof*
STEP TWO applies these same ideas to the Peter Linz HP proof.
STEP THREE shows how the Linz Ĥ.H sees the behavior of its recursive
simulations.
STEP FOUR shows why the behavior of the INPUT is the correct basis.
When discussing individual steps of a proof draft you shold start
at the last step.
I have been at this for twenty years.
Ben Bacarisse has spoken with me for 15 of those years.
What I found out is that exactly one point of one step
must be pursued until complete closure of that one point
of that one step.
On 5/29/2024 4:08 AM, Mikko wrote:
On 2024-05-28 14:37:15 +0000, olcott said:
On 5/28/2024 2:17 AM, Mikko wrote:
On 2024-05-27 13:52:09 +0000, olcott said:
On 5/27/2024 3:11 AM, Mikko wrote:
On 2024-05-26 16:50:21 +0000, olcott said:
<snip>
So that: *Usenet Article Lookup*
http://al.howardknight.net/
can see the whole message now that
*the Thai spammer killed Google Groups*
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 }
When we see that D correctly simulated by pure simulator H would >>>>>>> remain
stuck in recursive simulation then we also know that D never
reaches its
own line 06 and halts in less than an infinite number of correctly >>>>>>> simulated steps.
Which means that H never terminates. You said that by your definition >>>>>> a function that never terminates is not a pure function. Therefore >>>>>> H, if it exists, is not a pure function, and the phrase "pure
function
H" does not denote.
*I should have said that more clearly*
*That is why I need reviewers*
What is said here has little significance. You should ask reviewer's
comments about your working draft that you maintain in GitHub or some
other web site. And you should update that draft when a reviewer finds >>>> some something wrong or unclear.
*This is STEP ONE of my four step proof*
STEP TWO applies these same ideas to the Peter Linz HP proof.
STEP THREE shows how the Linz Ĥ.H sees the behavior of its recursive >>>>> simulations.
STEP FOUR shows why the behavior of the INPUT is the correct basis.
When discussing individual steps of a proof draft you shold start
at the last step.
I have been at this for twenty years.
Ben Bacarisse has spoken with me for 15 of those years.
What I found out is that exactly one point of one step
must be pursued until complete closure of that one point
of that one step.
How long do you think it takes to cover them all, starting
from the first?
How long do you think it would take, starting from the last?
The first point was closed in less than one hour with each of
four people that were not playing head games.
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 }
The above template refers to an infinite set of H/D pairs where D is correctly simulated by either pure simulator H or pure function H. This
was done because many reviewers used the shell game ploy to endlessly
switch which H/D pair was being referred to.
H correctly simulates 1 to ∞ steps of D with either pure function H or
pure simulator H. In none of these cases does the correctly simulated D
ever reach its own simulated final state and halt.
Correct Simulation Defined
This is provided because many reviewers had a different notion of
correct simulation that diverges from this notion.
A simulator is an x86 emulator that correctly emulates 1 to N of the
x86 instructions of D in the order specified by the x86 instructions
of D. This may include M recursive emulations of H emulating itself
emulating D.
When we see that D correctly simulated by pure simulator H would remain
stuck in infinite recursive simulation then we also know that less than
an infinite number of steps is not enough steps for D correctly
simulated by pure function H to reach its own simulated final state at
line 06 and halt.
On 5/28/2024 4:21 AM, Fred. Zwarts wrote:
Op 27.mei.2024 om 17:43 schreef olcott:
On 5/27/2024 9:58 AM, Richard Damon wrote:
On 5/27/24 10:39 AM, olcott wrote:
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 }
The above template refers to an infinite set of H/D pairs where D is
correctly simulated by either pure simulator H or pure function H. This
was done because many reviewers used the shell game ploy to endlessly
switch which H/D pair was being referred to.
Correct Simulation Defined
This is provided because many reviewers had a different notion of >>> correct simulation that diverges from this notion.
A simulator is an x86 emulator that correctly emulates 1 to N of the >>> x86 instructions of D in the order specified by the x86 instructions >>> of D. This may include M recursive emulations of H emulating itself >>> emulating D.
When we see that D correctly simulated by pure simulator H would remain
stuck in infinite recursive simulation then we also know that less than
an infinite number of steps is not enough steps for D correctly
simulated by pure function H to reach its own simulated final state at
line 06 and halt.
We can equally well replace D with H.
Only if we want to use the DISHONEST DODGE STRAW-MAN DECEPTION CHANGE-THE-SUBJECT FAKE REBUTTAL.
My use of the point-by-pint basis of the Socratic method tosses
such attempts out as Trolling.
On 5/29/2024 4:08 AM, Mikko wrote:
On 2024-05-28 14:37:15 +0000, olcott said:
On 5/28/2024 2:17 AM, Mikko wrote:
On 2024-05-27 13:52:09 +0000, olcott said:
On 5/27/2024 3:11 AM, Mikko wrote:
On 2024-05-26 16:50:21 +0000, olcott said:
<snip>
So that: *Usenet Article Lookup*
http://al.howardknight.net/
can see the whole message now that
*the Thai spammer killed Google Groups*
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 }
When we see that D correctly simulated by pure simulator H would >>>>>>> remain
stuck in recursive simulation then we also know that D never
reaches its
own line 06 and halts in less than an infinite number of correctly >>>>>>> simulated steps.
Which means that H never terminates. You said that by your definition >>>>>> a function that never terminates is not a pure function. Therefore >>>>>> H, if it exists, is not a pure function, and the phrase "pure
function
H" does not denote.
*I should have said that more clearly*
*That is why I need reviewers*
What is said here has little significance. You should ask reviewer's
comments about your working draft that you maintain in GitHub or some
other web site. And you should update that draft when a reviewer finds >>>> some something wrong or unclear.
*This is STEP ONE of my four step proof*
STEP TWO applies these same ideas to the Peter Linz HP proof.
STEP THREE shows how the Linz Ĥ.H sees the behavior of its recursive >>>>> simulations.
STEP FOUR shows why the behavior of the INPUT is the correct basis.
When discussing individual steps of a proof draft you shold start
at the last step.
I have been at this for twenty years.
Ben Bacarisse has spoken with me for 15 of those years.
What I found out is that exactly one point of one step
must be pursued until complete closure of that one point
of that one step.
How long do you think it takes to cover them all, starting
from the first?
How long do you think it would take, starting from the last?
The first point was closed in less than one hour with each of
four people that were not playing head games.
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 }
The above template refers to an infinite set of H/D pairs where D is correctly simulated by either pure simulator H or pure function H. This
was done because many reviewers used the shell game ploy to endlessly
switch which H/D pair was being referred to.
H correctly simulates 1 to ∞ steps of D with either pure function H or
pure simulator H. In none of these cases does the correctly simulated D
ever reach its own simulated final state and halt.
Correct Simulation Defined
This is provided because many reviewers had a different notion of
correct simulation that diverges from this notion.
A simulator is an x86 emulator that correctly emulates 1 to N of the
x86 instructions of D in the order specified by the x86 instructions
of D. This may include M recursive emulations of H emulating itself
emulating D.
When we see that D correctly simulated by pure simulator H would remain
stuck in infinite recursive simulation then we also know that less than
an infinite number of steps is not enough steps for D correctly
simulated by pure function H to reach its own simulated final state at
line 06 and halt.
On 5/28/2024 4:17 AM, Fred. Zwarts wrote:
Op 27.mei.2024 om 16:39 schreef olcott:
On 5/27/2024 9:10 AM, Richard Damon wrote:
On 5/27/24 9:52 AM, olcott wrote:
On 5/27/2024 3:11 AM, Mikko wrote:
On 2024-05-26 16:50:21 +0000, olcott said:
<snip>
So that: *Usenet Article Lookup*
http://al.howardknight.net/
can see the whole message now that
*the Thai spammer killed Google Groups*
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 }
When we see that D correctly simulated by pure simulator H would >>>>>>> remain
stuck in recursive simulation then we also know that D never
reaches its
own line 06 and halts in less than an infinite number of correctly >>>>>>> simulated steps.
Which means that H never terminates. You said that by your definition >>>>>> a function that never terminates is not a pure function. Therefore >>>>>> H, if it exists, is not a pure function, and the phrase "pure
function
H" does not denote.
*I should have said that more clearly*
*That is why I need reviewers*
*Here it is more clearly*
When we hypothesize that H is a pure simulator we see that D correctly >>>>> simulated by pure simulator H remains stuck in recursive simulation
thus
never reaches its own simulated final state at its line 06 and
halts. In
this case H does not halt, thus is neither a pure function nor a
decider.
But when you hypothesize that H is actually a "pure simulator"
(presumably one that never aborts) then you are creating a D that
uses that pure simulator, and are ONLY deriving conclusions for such
a D.
When D correctly simulated by pure simulator H cannot possibly reach
its own simulated final state at line 06 and halt in an infinite number
of simulated steps we can conclude that less than an infinite number of
steps is also not enough steps for D to halt.
When H correctly simulated by pure simulator H cannot possibly reach
its own simulated final state and halt in an infinite number
of simulated steps we can conclude that less than an infinite number of
steps is also not enough steps for H to halt.
When D correctly simulated by pure simulator H cannot possibly reach
its own simulated final state at line 06 and halt in an infinite number
of simulated steps we can conclude that less than an infinite number of
steps are also not enough steps for D to halt.
This tells us that when 1 to ∞ steps of D are correctly simulated by
H that D correctly simulated by H never halts under any circumstances what-so-ever
*CONCLUSIVELY PROVING THAT D CORRECTLY SIMULATED BY H DOES NOT HALT*
Once we have mutual agreement and complete closure on this we can
move on to STEP TWO that analyzes these exact same issues with the
Linz proof. The H/D pairs were needed so that people cannot cheat
on the meaning of correct simulation.
*Dozens of people have consistently insisted on cheating on this*
*Dozens of people have consistently insisted on cheating on this*
*Dozens of people have consistently insisted on cheating on this*
On 5/30/2024 5:14 AM, Fred. Zwarts wrote:
Op 28.mei.2024 om 17:10 schreef olcott:
On 5/28/2024 4:17 AM, Fred. Zwarts wrote:
Op 27.mei.2024 om 16:39 schreef olcott:
On 5/27/2024 9:10 AM, Richard Damon wrote:
On 5/27/24 9:52 AM, olcott wrote:
On 5/27/2024 3:11 AM, Mikko wrote:
On 2024-05-26 16:50:21 +0000, olcott said:
<snip>
So that: *Usenet Article Lookup*
http://al.howardknight.net/
can see the whole message now that
*the Thai spammer killed Google Groups*
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 }
When we see that D correctly simulated by pure simulator H
would remain
stuck in recursive simulation then we also know that D never >>>>>>>>> reaches its
own line 06 and halts in less than an infinite number of correctly >>>>>>>>> simulated steps.
Which means that H never terminates. You said that by your
definition
a function that never terminates is not a pure function. Therefore >>>>>>>> H, if it exists, is not a pure function, and the phrase "pure
function
H" does not denote.
*I should have said that more clearly*
*That is why I need reviewers*
*Here it is more clearly*
When we hypothesize that H is a pure simulator we see that D
correctly
simulated by pure simulator H remains stuck in recursive
simulation thus
never reaches its own simulated final state at its line 06 and
halts. In
this case H does not halt, thus is neither a pure function nor a >>>>>>> decider.
But when you hypothesize that H is actually a "pure simulator"
(presumably one that never aborts) then you are creating a D that
uses that pure simulator, and are ONLY deriving conclusions for
such a D.
When D correctly simulated by pure simulator H cannot possibly reach >>>>> its own simulated final state at line 06 and halt in an infinite
number
of simulated steps we can conclude that less than an infinite
number of
steps is also not enough steps for D to halt.
When H correctly simulated by pure simulator H cannot possibly reach
its own simulated final state and halt in an infinite number
of simulated steps we can conclude that less than an infinite number of >>>> steps is also not enough steps for H to halt.
When D correctly simulated by pure simulator H cannot possibly reach
its own simulated final state at line 06 and halt in an infinite number
of simulated steps we can conclude that less than an infinite number of
steps are also not enough steps for D to halt.
This tells us that when 1 to ∞ steps of D are correctly simulated by
H that D correctly simulated by H never halts under any circumstances
what-so-ever
*CONCLUSIVELY PROVING THAT D CORRECTLY SIMULATED BY H DOES NOT HALT*
Once we have mutual agreement and complete closure on this we can
move on to STEP TWO that analyzes these exact same issues with the
Linz proof. The H/D pairs were needed so that people cannot cheat
on the meaning of correct simulation.
*Dozens of people have consistently insisted on cheating on this*
*Dozens of people have consistently insisted on cheating on this*
*Dozens of people have consistently insisted on cheating on this*
When H correctly simulated by pure simulator H cannot possibly reach
its own simulated final state and halt in an infinite number
of simulated steps we can conclude that less than an infinite number of
steps are also not enough steps for H to halt.
This tells us that when 1 to ∞ steps of H are correctly simulated by
H that H correctly simulated by H never halts under any circumstances
what-so-ever
*CONCLUSIVELY PROVING THAT H CORRECTLY SIMULATED BY H DOES NOT HALT*
By this proof, we see that this H contradicts the requirement that it
should halt.
We cannot continue with this before we have agreement about it.
You should put my words in quotes otherwise people will be thinking
that you agree with me word-for-word.
Not at all. When we see that the infinite set of every possible D
simulated by any H cannot possibly reach its own simulated final state
and halt this remains true for D correctly simulated by simulating halt decider H. H halts and correctly simulated D never halts.
On 5/30/2024 5:10 AM, Fred. Zwarts wrote:
Op 28.mei.2024 om 17:13 schreef olcott:
On 5/28/2024 4:21 AM, Fred. Zwarts wrote:
Op 27.mei.2024 om 17:43 schreef olcott:
On 5/27/2024 9:58 AM, Richard Damon wrote:
On 5/27/24 10:39 AM, olcott wrote:
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 }
The above template refers to an infinite set of H/D pairs where D is >>>>> correctly simulated by either pure simulator H or pure function H.
This
was done because many reviewers used the shell game ploy to endlessly >>>>> switch which H/D pair was being referred to.
Correct Simulation Defined
This is provided because many reviewers had a different notion of >>>>> correct simulation that diverges from this notion.
A simulator is an x86 emulator that correctly emulates 1 to N >>>>> of the
x86 instructions of D in the order specified by the x86
instructions
of D. This may include M recursive emulations of H emulating
itself
emulating D.
When we see that D correctly simulated by pure simulator H would
remain
stuck in infinite recursive simulation then we also know that less
than
an infinite number of steps is not enough steps for D correctly
simulated by pure function H to reach its own simulated final state at >>>>> line 06 and halt.
We can equally well replace D with H.
Only if we want to use the DISHONEST DODGE STRAW-MAN DECEPTION
CHANGE-THE-SUBJECT FAKE REBUTTAL.
My use of the point-by-pint basis of the Socratic method tosses
such attempts out as Trolling.
You do not even understand your own subject. I am just showing that
your H does not halt, according to its own judgement. So, your
simulating H is not in agreement with the requirement that it should
halt. If the simulation of H would halt (as is the requirement), then
D would reach line 04. The only reason D, the parameter duplicator,
does not reach line 04 is that H does not halt.
This is incorrect. Only the directly executed outermost H must halt. Everything else is merely data to this directly executed H.
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 }
The above template refers to an infinite set of H/D pairs where D is correctly simulated by either pure simulator H or pure function H. This
was done because many reviewers used the shell game ploy to endlessly
switch which H/D pair was being referred to.
H correctly simulates 1 to ∞ steps of D with either pure function H or
pure simulator H. In none of these cases does the correctly simulated D
ever reach its own simulated final state and halt.
Whenever H is a pure function then H always halts.
On 5/30/2024 9:57 AM, Fred. Zwarts wrote:
Op 30.mei.2024 om 15:16 schreef olcott:
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 }
Not at all. When we see that the infinite set of every possible D
simulated by any H cannot possibly reach its own simulated final state
and halt this remains true for D correctly simulated by simulating halt
decider H. H halts and correctly simulated D never halts.
It is clear for anyone with a little bit of C knowledge, that if H
halts, then D continues with line 04.
*I conclusively prove that is false in my post from 14 minutes ago*
[D correctly simulated by H cannot possibly halt
--- templates and infinite sets --- deciders]
On 5/30/2024 5:14 AM, Fred. Zwarts wrote:Well played:
Op 28.mei.2024 om 17:10 schreef olcott:
On 5/28/2024 4:17 AM, Fred. Zwarts wrote:When H correctly simulated by pure simulator H cannot possibly reach
Op 27.mei.2024 om 16:39 schreef olcott:
On 5/27/2024 9:10 AM, Richard Damon wrote:
On 5/27/24 9:52 AM, olcott wrote:
On 5/27/2024 3:11 AM, Mikko wrote:
On 2024-05-26 16:50:21 +0000, olcott said:
its own simulated final state and halt in an infinite number
of simulated steps we can conclude that less than an infinite number of
steps are also not enough steps for H to halt.
This tells us that when 1 to ∞ steps of H are correctly simulated by
H that H correctly simulated by H never halts under any circumstances
what-so-ever
*CONCLUSIVELY PROVING THAT H CORRECTLY SIMULATED BY H DOES NOT HALT*
By this proof, we see that this H contradicts the requirement that it
should halt.
We cannot continue with this before we have agreement about it.
You should put my words in quotes otherwise people will be thinking
that you agree with me word-for-word.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 495 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 45:15:53 |
| Calls: | 9,745 |
| Calls today: | 5 |
| Files: | 13,742 |
| Messages: | 6,184,218 |