On 6/7/22 8:52 PM, olcott wrote:
On 6/7/2022 7:42 PM, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have determined that
his so called refutation of the HP proofs is based around the
behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being detected (i.e. Q
invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) simulation
however that wouldn't be the case for non-simulating decider for which
there would be no such recursion.
I propose a way to correctly decide the impossible input and your
"rebuttal" is that there are still other wrong ways to do this that
don't work.
Nope, you propose that if you can make a machine that both RUNS FOREVER
and also STOPS PART WAY at the same time with the same input, that you
can solve the problem.
On 6/7/2022 8:05 PM, Richard Damon wrote:
On 6/7/22 8:52 PM, olcott wrote:
On 6/7/2022 7:42 PM, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have determined that
his so called refutation of the HP proofs is based around the
behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being detected (i.e. Q >>>> invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) simulation >>>> however that wouldn't be the case for non-simulating decider for which >>>> there would be no such recursion.
I propose a way to correctly decide the impossible input and your
"rebuttal" is that there are still other wrong ways to do this that
don't work.
Nope, you propose that if you can make a machine that both RUNS
FOREVER and also STOPS PART WAY at the same time with the same input,
that you can solve the problem.
RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL SIMULATION OF
AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE SIMULATION WOULD NEVER
HALT.
It is an easily verified fact that a partial simulation of
Infinite_Loop() conclusively proves that it never halts.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6842130000 push 00001342
[0000137a](05) e833fdffff call 000010b2
[0000137f](03) 83c404 add esp,+04
[00001382](01) 50 push eax
[00001383](05) 6823040000 push 00000423
[00001388](05) e8e5f0ffff call 00000472
[0000138d](03) 83c408 add esp,+08
[00001390](02) 33c0 xor eax,eax
[00001392](01) 5d pop ebp
[00001393](01) c3 ret
Size in bytes:(0034) [00001393]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [00001372][0010228f][00000000] 55 push ebp [00001373][0010228f][00000000] 8bec mov ebp,esp [00001375][0010228b][00001342] 6842130000 push 00001342 // push _Infinite_Loop
[0000137a][00102287][0000137f] e833fdffff call 000010b2 // call H0
Begin Local Halt Decider Simulation Execution Trace Stored at:212343 [00001342][00212333][00212337] 55 push ebp [00001343][00212333][00212337] 8bec mov ebp,esp [00001345][00212333][00212337] ebfe jmp 00001345 [00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped
[0000137f][0010228f][00000000] 83c404 add esp,+04 [00001382][0010228b][00000000] 50 push eax [00001383][00102287][00000423] 6823040000 push 00000423 [00001388][00102287][00000423] e8e5f0ffff call 00000472
Input_Halts = 0
[0000138d][0010228f][00000000] 83c408 add esp,+08 [00001390][0010228f][00000000] 33c0 xor eax,eax [00001392][00102293][00100000] 5d pop ebp [00001393][00102297][00000004] c3 ret
Number of Instructions Executed(680)
On 6/7/2022 9:50 PM, Richard Damon wrote:
On 6/7/22 10:25 PM, olcott wrote:
On 6/7/2022 8:05 PM, Richard Damon wrote:
On 6/7/22 8:52 PM, olcott wrote:
On 6/7/2022 7:42 PM, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have determined that >>>>>> his so called refutation of the HP proofs is based around the
behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being detected
(i.e. Q
invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
simulation
however that wouldn't be the case for non-simulating decider for
which
there would be no such recursion.
I propose a way to correctly decide the impossible input and your
"rebuttal" is that there are still other wrong ways to do this that
don't work.
Nope, you propose that if you can make a machine that both RUNS
FOREVER and also STOPS PART WAY at the same time with the same
input, that you can solve the problem.
RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL SIMULATION
OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE SIMULATION WOULD
NEVER HALT.
No, Peter Olcott shows he is too stupid to understand the fallacy of
Proof by Example.
You are too stupid to know that this does not apply.
When one is 100% specific there is no generalization at all thus making inappropriate generalization impossible.
In logic and mathematics, proof by example (sometimes known as
inappropriate generalization)
https://en.wikipedia.org/wiki/Proof_by_example
On 6/7/22 10:25 PM, olcott wrote:
On 6/7/2022 8:05 PM, Richard Damon wrote:
On 6/7/22 8:52 PM, olcott wrote:
On 6/7/2022 7:42 PM, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have determined that >>>>> his so called refutation of the HP proofs is based around the
behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being detected
(i.e. Q
invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) simulation >>>>> however that wouldn't be the case for non-simulating decider for which >>>>> there would be no such recursion.
I propose a way to correctly decide the impossible input and your
"rebuttal" is that there are still other wrong ways to do this that
don't work.
Nope, you propose that if you can make a machine that both RUNS
FOREVER and also STOPS PART WAY at the same time with the same input,
that you can solve the problem.
RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL SIMULATION
OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE SIMULATION WOULD
NEVER HALT.
No, Peter Olcott shows he is too stupid to understand the fallacy of
Proof by Example.
On 6/7/22 11:17 PM, olcott wrote:
On 6/7/2022 9:50 PM, Richard Damon wrote:
On 6/7/22 10:25 PM, olcott wrote:
On 6/7/2022 8:05 PM, Richard Damon wrote:
On 6/7/22 8:52 PM, olcott wrote:
On 6/7/2022 7:42 PM, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have determined that >>>>>>> his so called refutation of the HP proofs is based around the
behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being detected
(i.e. Q
invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
simulation
however that wouldn't be the case for non-simulating decider for >>>>>>> which
there would be no such recursion.
I propose a way to correctly decide the impossible input and your
"rebuttal" is that there are still other wrong ways to do this
that don't work.
Nope, you propose that if you can make a machine that both RUNS
FOREVER and also STOPS PART WAY at the same time with the same
input, that you can solve the problem.
RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
SIMULATION WOULD NEVER HALT.
No, Peter Olcott shows he is too stupid to understand the fallacy of
Proof by Example.
You are too stupid to know that this does not apply.
When one is 100% specific there is no generalization at all thus
making inappropriate generalization impossible.
In logic and mathematics, proof by example (sometimes known as
inappropriate generalization)
https://en.wikipedia.org/wiki/Proof_by_example
Right, and showing that an algorith works to detect
On 6/7/22 11:17 PM, olcott wrote:
On 6/7/2022 9:50 PM, Richard Damon wrote:
On 6/7/22 10:25 PM, olcott wrote:
On 6/7/2022 8:05 PM, Richard Damon wrote:
On 6/7/22 8:52 PM, olcott wrote:
On 6/7/2022 7:42 PM, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have determined that >>>>>>> his so called refutation of the HP proofs is based around the
behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being detected
(i.e. Q
invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
simulation
however that wouldn't be the case for non-simulating decider for >>>>>>> which
there would be no such recursion.
I propose a way to correctly decide the impossible input and your
"rebuttal" is that there are still other wrong ways to do this
that don't work.
Nope, you propose that if you can make a machine that both RUNS
FOREVER and also STOPS PART WAY at the same time with the same
input, that you can solve the problem.
RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
SIMULATION WOULD NEVER HALT.
No, Peter Olcott shows he is too stupid to understand the fallacy of
Proof by Example.
You are too stupid to know that this does not apply.
When one is 100% specific there is no generalization at all thus
making inappropriate generalization impossible.
In logic and mathematics, proof by example (sometimes known as
inappropriate generalization)
https://en.wikipedia.org/wiki/Proof_by_example
Right, and showing that an algorith works to detect a infinite
recursion, even with a conditional simulation in the loop, by looking at
a program that does a jump to self is an inappropriate generalization.
The fact that you don't see that just proves how stupid you are,
You don't even know what they mean by "Generalization" there it seems.
On 6/7/2022 10:25 PM, Richard Damon wrote:
On 6/7/22 11:17 PM, olcott wrote:
On 6/7/2022 9:50 PM, Richard Damon wrote:
On 6/7/22 10:25 PM, olcott wrote:
On 6/7/2022 8:05 PM, Richard Damon wrote:
On 6/7/22 8:52 PM, olcott wrote:
On 6/7/2022 7:42 PM, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have determined >>>>>>>> that
his so called refutation of the HP proofs is based around the
behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q)); >>>>>>>> }
He asserts H(Q,Q)=0 based on a nested simulation being detected >>>>>>>> (i.e. Q
invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
simulation
however that wouldn't be the case for non-simulating decider for >>>>>>>> which
there would be no such recursion.
I propose a way to correctly decide the impossible input and your >>>>>>> "rebuttal" is that there are still other wrong ways to do this
that don't work.
Nope, you propose that if you can make a machine that both RUNS
FOREVER and also STOPS PART WAY at the same time with the same
input, that you can solve the problem.
RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
SIMULATION WOULD NEVER HALT.
No, Peter Olcott shows he is too stupid to understand the fallacy of
Proof by Example.
You are too stupid to know that this does not apply.
When one is 100% specific there is no generalization at all thus
making inappropriate generalization impossible.
In logic and mathematics, proof by example (sometimes known as
inappropriate generalization)
https://en.wikipedia.org/wiki/Proof_by_example
Right, and showing that an algorith works to detect
A single 100% specific instance of infinitely nested simulation is not
any freaking generalization at all. You actually might be stupid in
which case I take it back. It is rude to call stupid people stupid
because it is not their fault. I called you stupid because I thought you
were playing sadistic head games.
On 6/7/2022 10:25 PM, Richard Damon wrote:
On 6/7/22 11:17 PM, olcott wrote:
On 6/7/2022 9:50 PM, Richard Damon wrote:
On 6/7/22 10:25 PM, olcott wrote:
On 6/7/2022 8:05 PM, Richard Damon wrote:
On 6/7/22 8:52 PM, olcott wrote:
On 6/7/2022 7:42 PM, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have determined >>>>>>>> that
his so called refutation of the HP proofs is based around the
behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q)); >>>>>>>> }
He asserts H(Q,Q)=0 based on a nested simulation being detected >>>>>>>> (i.e. Q
invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
simulation
however that wouldn't be the case for non-simulating decider for >>>>>>>> which
there would be no such recursion.
I propose a way to correctly decide the impossible input and your >>>>>>> "rebuttal" is that there are still other wrong ways to do this
that don't work.
Nope, you propose that if you can make a machine that both RUNS
FOREVER and also STOPS PART WAY at the same time with the same
input, that you can solve the problem.
RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
SIMULATION WOULD NEVER HALT.
No, Peter Olcott shows he is too stupid to understand the fallacy of
Proof by Example.
You are too stupid to know that this does not apply.
When one is 100% specific there is no generalization at all thus
making inappropriate generalization impossible.
In logic and mathematics, proof by example (sometimes known as
inappropriate generalization)
https://en.wikipedia.org/wiki/Proof_by_example
Right, and showing that an algorith works to detect a infinite
recursion, even with a conditional simulation in the loop, by looking
at a program that does a jump to self is an inappropriate generalization.
The fact that you don't see that just proves how stupid you are,
You don't even know what they mean by "Generalization" there it seems.
When I show every single step of the execution trace of P there is no freaking generalization at all nitwit, it is all 100% specific.
On 6/7/22 11:43 PM, olcott wrote:
On 6/7/2022 10:25 PM, Richard Damon wrote:
On 6/7/22 11:17 PM, olcott wrote:
On 6/7/2022 9:50 PM, Richard Damon wrote:
On 6/7/22 10:25 PM, olcott wrote:
On 6/7/2022 8:05 PM, Richard Damon wrote:
On 6/7/22 8:52 PM, olcott wrote:
On 6/7/2022 7:42 PM, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have determined >>>>>>>>> that
his so called refutation of the HP proofs is based around the >>>>>>>>> behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q)); >>>>>>>>> }
He asserts H(Q,Q)=0 based on a nested simulation being detected >>>>>>>>> (i.e. Q
invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
simulation
however that wouldn't be the case for non-simulating decider >>>>>>>>> for which
there would be no such recursion.
I propose a way to correctly decide the impossible input and
your "rebuttal" is that there are still other wrong ways to do >>>>>>>> this that don't work.
Nope, you propose that if you can make a machine that both RUNS
FOREVER and also STOPS PART WAY at the same time with the same
input, that you can solve the problem.
RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
SIMULATION WOULD NEVER HALT.
No, Peter Olcott shows he is too stupid to understand the fallacy
of Proof by Example.
You are too stupid to know that this does not apply.
When one is 100% specific there is no generalization at all thus
making inappropriate generalization impossible.
In logic and mathematics, proof by example (sometimes known as
inappropriate generalization)
https://en.wikipedia.org/wiki/Proof_by_example
Right, and showing that an algorith works to detect
A single 100% specific instance of infinitely nested simulation is not
any freaking generalization at all. You actually might be stupid in
which case I take it back. It is rude to call stupid people stupid
because it is not their fault. I called you stupid because I thought
you were playing sadistic head games.
WHAT 100% specific instanc of infintely nested simualtions.
On 6/7/22 11:32 PM, olcott wrote:
On 6/7/2022 10:25 PM, Richard Damon wrote:
On 6/7/22 11:17 PM, olcott wrote:
On 6/7/2022 9:50 PM, Richard Damon wrote:
On 6/7/22 10:25 PM, olcott wrote:
On 6/7/2022 8:05 PM, Richard Damon wrote:
On 6/7/22 8:52 PM, olcott wrote:
On 6/7/2022 7:42 PM, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have determined >>>>>>>>> that
his so called refutation of the HP proofs is based around the >>>>>>>>> behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q)); >>>>>>>>> }
He asserts H(Q,Q)=0 based on a nested simulation being detected >>>>>>>>> (i.e. Q
invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
simulation
however that wouldn't be the case for non-simulating decider >>>>>>>>> for which
there would be no such recursion.
I propose a way to correctly decide the impossible input and
your "rebuttal" is that there are still other wrong ways to do >>>>>>>> this that don't work.
Nope, you propose that if you can make a machine that both RUNS
FOREVER and also STOPS PART WAY at the same time with the same
input, that you can solve the problem.
RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
SIMULATION WOULD NEVER HALT.
No, Peter Olcott shows he is too stupid to understand the fallacy
of Proof by Example.
You are too stupid to know that this does not apply.
When one is 100% specific there is no generalization at all thus
making inappropriate generalization impossible.
In logic and mathematics, proof by example (sometimes known as
inappropriate generalization)
https://en.wikipedia.org/wiki/Proof_by_example
Right, and showing that an algorith works to detect a infinite
recursion, even with a conditional simulation in the loop, by looking
at a program that does a jump to self is an inappropriate
generalization.
The fact that you don't see that just proves how stupid you are,
You don't even know what they mean by "Generalization" there it seems.
When I show every single step of the execution trace of P there is no
freaking generalization at all nitwit, it is all 100% specific.
Except that is a lie.
You don't show the instruction that the x86 processor executes
immediately after the 7th instruction.
On 6/7/2022 10:54 PM, Richard Damon wrote:
On 6/7/22 11:43 PM, olcott wrote:
On 6/7/2022 10:25 PM, Richard Damon wrote:
On 6/7/22 11:17 PM, olcott wrote:
On 6/7/2022 9:50 PM, Richard Damon wrote:
On 6/7/22 10:25 PM, olcott wrote:
On 6/7/2022 8:05 PM, Richard Damon wrote:
On 6/7/22 8:52 PM, olcott wrote:
On 6/7/2022 7:42 PM, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have
determined that
his so called refutation of the HP proofs is based around the >>>>>>>>>> behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q)); >>>>>>>>>> }
He asserts H(Q,Q)=0 based on a nested simulation being
detected (i.e. Q
invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) >>>>>>>>>> simulation
however that wouldn't be the case for non-simulating decider >>>>>>>>>> for which
there would be no such recursion.
I propose a way to correctly decide the impossible input and >>>>>>>>> your "rebuttal" is that there are still other wrong ways to do >>>>>>>>> this that don't work.
Nope, you propose that if you can make a machine that both RUNS >>>>>>>> FOREVER and also STOPS PART WAY at the same time with the same >>>>>>>> input, that you can solve the problem.
RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
SIMULATION WOULD NEVER HALT.
No, Peter Olcott shows he is too stupid to understand the fallacy
of Proof by Example.
You are too stupid to know that this does not apply.
When one is 100% specific there is no generalization at all thus
making inappropriate generalization impossible.
In logic and mathematics, proof by example (sometimes known as
inappropriate generalization)
https://en.wikipedia.org/wiki/Proof_by_example
Right, and showing that an algorith works to detect
A single 100% specific instance of infinitely nested simulation is
not any freaking generalization at all. You actually might be stupid
in which case I take it back. It is rude to call stupid people stupid
because it is not their fault. I called you stupid because I thought
you were playing sadistic head games.
WHAT 100% specific instanc of infintely nested simualtions.
#include <stdint.h>
#define u32 uint32_t
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P [0000135d](05) e840feffff call 000011a2 // call H [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P [0000137a](05) 6852130000 push 00001352 // push P [0000137f](05) e81efeffff call 000011a2 // call H [00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = " [0000138d](05) e8e0f0ffff call 00000472 // call Output [00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= ...[00001372][0010229e][00000000] 55 push ebp ...[00001373][0010229e][00000000] 8bec mov ebp,esp ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
Begin Local Halt Decider Simulation Execution Trace Stored at:212352
// H emulates the first seven instructions of P ...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08] ...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08] ...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
// The emulated H emulates the first seven instructions of P ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08] ...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08] ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.
...[00001384][0010229e][00000000] 83c408 add esp,+08 ...[00001387][0010229a][00000000] 50 push eax ...[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output Input_Halts = 0
...[00001392][0010229e][00000000] 83c408 add esp,+08 ...[00001395][0010229e][00000000] 33c0 xor eax,eax ...[00001397][001022a2][00100000] 5d pop ebp ...[00001398][001022a6][00000004] c3 ret
Number of Instructions Executed(15892) = 237 pages
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
H_Hat((u32)H_Hat);
}
_H_Hat()
[00000b98](01) 55 push ebp
[00000b99](02) 8bec mov ebp,esp
[00000b9c](03) 8b4508 mov eax,[ebp+08]
[00000b9f](01) 50 push eax
[00000ba0](03) 8b4d08 mov ecx,[ebp+08]
[00000ba3](01) 51 push ecx
[00000ba4](05) e88ffdffff call 00000938
[00000ba9](03) 83c408 add esp,+08
[00000bac](03) 8945fc mov [ebp-04],eax
[00000baf](04) 837dfc00 cmp dword [ebp-04],+00
[00000bb3](02) 7402 jz 00000bb7
[00000bb5](02) ebfe jmp 00000bb5
[00000bb7](02) 8be5 mov esp,ebp
[00000bb9](01) 5d pop ebp
[00000bba](01) c3 ret
Size in bytes:(0035) [00000bba]
_main()
[00000bc8](01) 55 push ebp
[00000bc9](02) 8bec mov ebp,esp
[00000bcb](05) 68980b0000 push 00000b98
[00000bd0](05) e8c3ffffff call 00000b98
[00000bd5](03) 83c404 add esp,+04
[00000bd8](02) 33c0 xor eax,eax
[00000bda](01) 5d pop ebp
[00000bdb](01) c3 ret
Size in bytes:(0020) [00000bdb]
===============================
...[00000bc8][001015d4][00000000](01) 55 push ebp ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98 ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98 ...[00000b98][001015c8][001015d4](01) 55 push ebp ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp ...[00000b9b][001015c4][00000000](01) 51 push ecx ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][001015c0][00000b98](01) 50 push eax ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][001015bc][00000b98](01) 51 push ecx ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
Begin Local Halt Decider Simulation at Machine Address:b98 ...[00000b98][00211674][00211678](01) 55 push ebp ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp ...[00000b9b][00211670][00201644](01) 51 push ecx ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][0021166c][00000b98](01) 50 push eax ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][00211668][00000b98](01) 51 push ecx ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938 ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp ...[00000b9b][0025c098][0024c06c](01) 51 push ecx ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][0025c094][00000b98](01) 50 push eax ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][0025c090][00000b98](01) 51 push ecx ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08 ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00 ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7 ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp ...[00000bba][001015d0][00000b98](01) c3 ret ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04 ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax ...[00000bda][001015d8][00100000](01) 5d pop ebp ...[00000bdb][001015dc][00000098](01) c3 ret
Number_of_User_Instructions(39)
Number of Instructions Executed(26567)
On 6/7/2022 10:52 PM, Richard Damon wrote:
On 6/7/22 11:32 PM, olcott wrote:
On 6/7/2022 10:25 PM, Richard Damon wrote:
On 6/7/22 11:17 PM, olcott wrote:
On 6/7/2022 9:50 PM, Richard Damon wrote:
On 6/7/22 10:25 PM, olcott wrote:
On 6/7/2022 8:05 PM, Richard Damon wrote:
On 6/7/22 8:52 PM, olcott wrote:
On 6/7/2022 7:42 PM, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have
determined that
his so called refutation of the HP proofs is based around the >>>>>>>>>> behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q)); >>>>>>>>>> }
He asserts H(Q,Q)=0 based on a nested simulation being
detected (i.e. Q
invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) >>>>>>>>>> simulation
however that wouldn't be the case for non-simulating decider >>>>>>>>>> for which
there would be no such recursion.
I propose a way to correctly decide the impossible input and >>>>>>>>> your "rebuttal" is that there are still other wrong ways to do >>>>>>>>> this that don't work.
Nope, you propose that if you can make a machine that both RUNS >>>>>>>> FOREVER and also STOPS PART WAY at the same time with the same >>>>>>>> input, that you can solve the problem.
RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
SIMULATION WOULD NEVER HALT.
No, Peter Olcott shows he is too stupid to understand the fallacy
of Proof by Example.
You are too stupid to know that this does not apply.
When one is 100% specific there is no generalization at all thus
making inappropriate generalization impossible.
In logic and mathematics, proof by example (sometimes known as
inappropriate generalization)
https://en.wikipedia.org/wiki/Proof_by_example
Right, and showing that an algorith works to detect a infinite
recursion, even with a conditional simulation in the loop, by
looking at a program that does a jump to self is an inappropriate
generalization.
The fact that you don't see that just proves how stupid you are,
You don't even know what they mean by "Generalization" there it seems.
When I show every single step of the execution trace of P there is no
freaking generalization at all nitwit, it is all 100% specific.
Except that is a lie.
You don't show the instruction that the x86 processor executes
immediately after the 7th instruction.
I show every single step of the execution trace of P
of P
of P
of P
of P
of P
Even if you aren't very smart you could pay much better attention.
On very very difficult things such as the change document for the VISA
credit card processing system I had to read through the document 15
times before I was sure that I caught every single change.
VISA was the most difficult Discover card was the clearest.
On 6/7/22 11:59 PM, olcott wrote:
On 6/7/2022 10:54 PM, Richard Damon wrote:
On 6/7/22 11:43 PM, olcott wrote:
On 6/7/2022 10:25 PM, Richard Damon wrote:
On 6/7/22 11:17 PM, olcott wrote:
On 6/7/2022 9:50 PM, Richard Damon wrote:
On 6/7/22 10:25 PM, olcott wrote:
On 6/7/2022 8:05 PM, Richard Damon wrote:
On 6/7/22 8:52 PM, olcott wrote:
On 6/7/2022 7:42 PM, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have
determined that
his so called refutation of the HP proofs is based around the >>>>>>>>>>> behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q)); >>>>>>>>>>> }
He asserts H(Q,Q)=0 based on a nested simulation being
detected (i.e. Q
invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) >>>>>>>>>>> simulation
however that wouldn't be the case for non-simulating decider >>>>>>>>>>> for which
there would be no such recursion.
I propose a way to correctly decide the impossible input and >>>>>>>>>> your "rebuttal" is that there are still other wrong ways to do >>>>>>>>>> this that don't work.
Nope, you propose that if you can make a machine that both RUNS >>>>>>>>> FOREVER and also STOPS PART WAY at the same time with the same >>>>>>>>> input, that you can solve the problem.
RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
SIMULATION WOULD NEVER HALT.
No, Peter Olcott shows he is too stupid to understand the fallacy >>>>>>> of Proof by Example.
You are too stupid to know that this does not apply.
When one is 100% specific there is no generalization at all thus
making inappropriate generalization impossible.
In logic and mathematics, proof by example (sometimes known as
inappropriate generalization)
https://en.wikipedia.org/wiki/Proof_by_example
Right, and showing that an algorith works to detect
A single 100% specific instance of infinitely nested simulation is
not any freaking generalization at all. You actually might be stupid
in which case I take it back. It is rude to call stupid people
stupid because it is not their fault. I called you stupid because I
thought you were playing sadistic head games.
WHAT 100% specific instanc of infintely nested simualtions.
#include <stdint.h>
#define u32 uint32_t
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P >> [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P >> [0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001372][0010229e][00000000] 55 push ebp
...[00001373][0010229e][00000000] 8bec mov ebp,esp
...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
Begin Local Halt Decider Simulation Execution Trace Stored at:212352
// H emulates the first seven instructions of P
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
// The emulated H emulates the first seven instructions of P
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with
complete certainty that the emulated P never reaches its final “ret”
instruction, thus never halts.
...[00001384][0010229e][00000000] 83c408 add esp,+08
...[00001387][0010229a][00000000] 50 push eax
...[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
...[00001392][0010229e][00000000] 83c408 add esp,+08
...[00001395][0010229e][00000000] 33c0 xor eax,eax
...[00001397][001022a2][00100000] 5d pop ebp
...[00001398][001022a6][00000004] c3 ret
Number of Instructions Executed(15892) = 237 pages
Except that H is wrong, because it didn't actually emulate the input correctly.
On 6/7/22 11:57 PM, olcott wrote:
On 6/7/2022 10:52 PM, Richard Damon wrote:
On 6/7/22 11:32 PM, olcott wrote:
On 6/7/2022 10:25 PM, Richard Damon wrote:
When I show every single step of the execution trace of P there is
On 6/7/22 11:17 PM, olcott wrote:
On 6/7/2022 9:50 PM, Richard Damon wrote:
On 6/7/22 10:25 PM, olcott wrote:
On 6/7/2022 8:05 PM, Richard Damon wrote:
On 6/7/22 8:52 PM, olcott wrote:
On 6/7/2022 7:42 PM, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have
determined that
his so called refutation of the HP proofs is based around the >>>>>>>>>>> behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q)); >>>>>>>>>>> }
He asserts H(Q,Q)=0 based on a nested simulation being
detected (i.e. Q
invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) >>>>>>>>>>> simulation
however that wouldn't be the case for non-simulating decider >>>>>>>>>>> for which
there would be no such recursion.
I propose a way to correctly decide the impossible input and >>>>>>>>>> your "rebuttal" is that there are still other wrong ways to do >>>>>>>>>> this that don't work.
Nope, you propose that if you can make a machine that both RUNS >>>>>>>>> FOREVER and also STOPS PART WAY at the same time with the same >>>>>>>>> input, that you can solve the problem.
RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
SIMULATION WOULD NEVER HALT.
No, Peter Olcott shows he is too stupid to understand the fallacy >>>>>>> of Proof by Example.
You are too stupid to know that this does not apply.
When one is 100% specific there is no generalization at all thus
making inappropriate generalization impossible.
In logic and mathematics, proof by example (sometimes known as
inappropriate generalization)
https://en.wikipedia.org/wiki/Proof_by_example
Right, and showing that an algorith works to detect a infinite
recursion, even with a conditional simulation in the loop, by
looking at a program that does a jump to self is an inappropriate
generalization.
The fact that you don't see that just proves how stupid you are,
You don't even know what they mean by "Generalization" there it seems. >>>>
no freaking generalization at all nitwit, it is all 100% specific.
Except that is a lie.
You don't show the instruction that the x86 processor executes
immediately after the 7th instruction.
I show every single step of the execution trace of P
of P
of P
of P
of P
of P
Nope, You just show that you don't even know what is in the program P.
The PROGRAM P includes the code of H that is calls, which you don't seem
to understand.
Even if you aren't very smart you could pay much better attention.
Maybe, but I do know what makes up a program that you don't seem to understand.
On Wednesday, 8 June 2022 at 13:35:50 UTC+1, olcott wrote:
You're drawing a distinction between "P(P)" and "the input P,P". I don't understand it and I suspect you don't either.
Except that H is wrong, because it didn't actually emulate the inputH(P,P) correctly emulates 14 steps of its input providing H the
correctly.
sufficient basis to determine that a complete emulation of its input
never reaches the "ret" instruction of this input.
On 6/8/2022 6:08 AM, Richard Damon wrote:
On 6/7/22 11:57 PM, olcott wrote:
On 6/7/2022 10:52 PM, Richard Damon wrote:
On 6/7/22 11:32 PM, olcott wrote:
On 6/7/2022 10:25 PM, Richard Damon wrote:
On 6/7/22 11:17 PM, olcott wrote:
On 6/7/2022 9:50 PM, Richard Damon wrote:
On 6/7/22 10:25 PM, olcott wrote:
On 6/7/2022 8:05 PM, Richard Damon wrote:
On 6/7/22 8:52 PM, olcott wrote:
On 6/7/2022 7:42 PM, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have
determined that
his so called refutation of the HP proofs is based around the >>>>>>>>>>>> behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q)); >>>>>>>>>>>> }
He asserts H(Q,Q)=0 based on a nested simulation being >>>>>>>>>>>> detected (i.e. Q
invoking H) irregardless of whether FUBAR halts or not. >>>>>>>>>>>>
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) >>>>>>>>>>>> simulation
however that wouldn't be the case for non-simulating decider >>>>>>>>>>>> for which
there would be no such recursion.
I propose a way to correctly decide the impossible input and >>>>>>>>>>> your "rebuttal" is that there are still other wrong ways to >>>>>>>>>>> do this that don't work.
Nope, you propose that if you can make a machine that both >>>>>>>>>> RUNS FOREVER and also STOPS PART WAY at the same time with the >>>>>>>>>> same input, that you can solve the problem.
RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE >>>>>>>>> SIMULATION WOULD NEVER HALT.
No, Peter Olcott shows he is too stupid to understand the
fallacy of Proof by Example.
You are too stupid to know that this does not apply.
When one is 100% specific there is no generalization at all thus >>>>>>> making inappropriate generalization impossible.
In logic and mathematics, proof by example (sometimes known as
inappropriate generalization)
https://en.wikipedia.org/wiki/Proof_by_example
Right, and showing that an algorith works to detect a infinite
recursion, even with a conditional simulation in the loop, by
looking at a program that does a jump to self is an inappropriate
generalization.
The fact that you don't see that just proves how stupid you are,
You don't even know what they mean by "Generalization" there it
seems.
When I show every single step of the execution trace of P there is
no freaking generalization at all nitwit, it is all 100% specific.
Except that is a lie.
You don't show the instruction that the x86 processor executes
immediately after the 7th instruction.
I show every single step of the execution trace of P
of P
of P
of P
of P
of P
Nope, You just show that you don't even know what is in the program P.
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P [0000135d](05) e840feffff call 000011a2 // call H [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
The PROGRAM P includes the code of H that is calls, which you don't
seem to understand.
Even if you aren't very smart you could pay much better attention.
Maybe, but I do know what makes up a program that you don't seem to
understand.
It is freaking stipulated that P is the C function under test and H is
the test function.
On 6/8/2022 8:27 AM, Malcolm McLean wrote:
On Wednesday, 8 June 2022 at 13:35:50 UTC+1, olcott wrote:
You're drawing a distinction between "P(P)" and "the input P,P". I don't
Except that H is wrong, because it didn't actually emulate the inputH(P,P) correctly emulates 14 steps of its input providing H the
correctly.
sufficient basis to determine that a complete emulation of its input
never reaches the "ret" instruction of this input.
understand it and I suspect you don't either.
It is an easily verified fact that the correctly simulated input to
H(P,P) never halts and P(P) does halt.
Do you care about verified facts?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 102:13:21 |
| Calls: | 6,660 |
| Calls today: | 2 |
| Files: | 12,209 |
| Messages: | 5,334,982 |