On 08/06/2022 14:31, olcott wrote:
On 6/8/2022 8:27 AM, Malcolm McLean 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.It is an easily verified fact that the correctly simulated input to
H(P,P) never halts and P(P) does halt.
That seems to be as succinct a statement as you have achieved over these many years and thousands of articles, showing that your "H" is not in fact a correct simulator.
I suggest you correct "H" before continuing your quest.
On 08/06/2022 14:31, olcott wrote:
On 6/8/2022 8:27 AM, Malcolm McLean 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.It is an easily verified fact that the correctly simulated input to
H(P,P) never halts and P(P) does halt.
That seems to be as succinct a statement as you have achieved over these many years and thousands of articles, showing that your "H" is not in fact a correct simulator.
I suggest you correct "H" before continuing your quest.
On Wednesday, 8 June 2022 at 08:43:00 UTC+8, 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.
Can we finally put this to bed and change the fucking topic?
/Flibble
+-----------------------------------------------------------------+
| The HP proof has nothing to do with how the 'H' is constructed. | +-----------------------------------------------------------------+
Many such liar's-paradox-like examples are for easy comprehension (for educational purpose).
The real 'H' inside P is an algorithm computationally equivalent to 'H' (so, no
any 'call' is there, and the pattern matching tech. is very difficult, by now to say.
And, this 'H' is also allowed given by some super intelligent god.... whatever).
+------------------------------------------------+
| olcott's brain is incapable of logic function. |
| (other kind of functions seem quite excellent) | +------------------------------------------------+
It should be safe to say any concept involves logical operation, olcott cannot
make it formally correct (he relies on his "language's logic").
For example, I doubt he can handle several lines of inter-connected codes. ...
All should be fine... except olcott now insists "H(P,P)==0" is correct while there is no definition of H shown.
On 6/8/2022 9:08 AM, Andy Walker wrote:
On 08/06/2022 14:31, olcott wrote:
On 6/8/2022 8:27 AM, Malcolm McLean wrote:
You're drawing a distinction between "P(P)" and "the input P,P". IIt is an easily verified fact that the correctly simulated input to
don't
understand it and I suspect you don't either.
H(P,P) never halts and P(P) does halt.
That seems to be as succinct a statement as you have achieved over >> these many years and thousands of articles, showing that your "H" is
not in
fact a correct simulator.
I suggest you correct "H" before continuing your quest.
Everyone here seems to believe that the x86 language itself is incorrect
and that P should magically jump to its "ret" instruction even though
that is not what is specified by the x86 source-code of P.
This leads me to believe that these people are simply despicable lying bastards because no one would be stupid enough to actually disagree with
the x86 language.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
P(P);
}
_P()
[000012e7](01) 55 push ebp
[000012e8](02) 8bec mov ebp,esp
[000012ea](03) 8b4508 mov eax,[ebp+08]
[000012ed](01) 50 push eax
[000012ee](03) 8b4d08 mov ecx,[ebp+08]
[000012f1](01) 51 push ecx
[000012f2](05) e880feffff call 00001177
[000012f7](03) 83c408 add esp,+08
[000012fa](02) 85c0 test eax,eax
[000012fc](02) 7402 jz 00001300
[000012fe](02) ebfe jmp 000012fe
[00001300](01) 5d pop ebp
[00001301](01) c3 ret
Size in bytes:(0027) [00001301]
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.
On 6/8/2022 10:37 AM, wij wrote:
On Wednesday, 8 June 2022 at 08:43:00 UTC+8, 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.
Can we finally put this to bed and change the fucking topic?
/Flibble
+-----------------------------------------------------------------+
| The HP proof has nothing to do with how the 'H' is constructed. |
+-----------------------------------------------------------------+
Many such liar's-paradox-like examples are for easy comprehension (for
educational purpose).
The real 'H' inside P is an algorithm computationally equivalent to
'H' (so, no
any 'call' is there, and the pattern matching tech. is very difficult,
by now to say.
And, this 'H' is also allowed given by some super intelligent god....
whatever).
It is the pathological self reference(Olcott 2004) relationship between
H and P that has previously been considered to make P undecidable for H.
For any program H that might determine if programs halt, a "pathological"
program P, called with some input, can pass its own source and its input to
H and then specifically do the opposite of what H predicts P will do. No H
can exist that handles this case. https://en.wikipedia.org/wiki/Halting_problem
+------------------------------------------------+
| olcott's brain is incapable of logic function. |
| (other kind of functions seem quite excellent) |
+------------------------------------------------+
It should be safe to say any concept involves logical operation,
olcott cannot
make it formally correct (he relies on his "language's logic").
For example, I doubt he can handle several lines of inter-connected
codes.
...
All should be fine... except olcott now insists "H(P,P)==0" is correct
while
there is no definition of H shown.
I am not claiming that H(P,P) correctly determines the halt status of
its input. I am claiming that non-halting is the correct halt status of
its input.
If you have to reread this 10,000 times to notice what the difference is
then do that.
To determine the correct halt status for the input to H(P,P) we don't
need to know anything about H besides that fact H uses an x86 emulator
to emulate its input.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
P(P);
}
_P()
[000012e7](01) 55 push ebp
[000012e8](02) 8bec mov ebp,esp
[000012ea](03) 8b4508 mov eax,[ebp+08]
[000012ed](01) 50 push eax
[000012ee](03) 8b4d08 mov ecx,[ebp+08]
[000012f1](01) 51 push ecx
[000012f2](05) e880feffff call 00001177
[000012f7](03) 83c408 add esp,+08
[000012fa](02) 85c0 test eax,eax
[000012fc](02) 7402 jz 00001300
[000012fe](02) ebfe jmp 000012fe
[00001300](01) 5d pop ebp
[00001301](01) c3 ret
Size in bytes:(0027) [00001301]
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 103:28:27 |
| Calls: | 6,660 |
| Calls today: | 2 |
| Files: | 12,209 |
| Messages: | 5,335,074 |