XPost: comp.theory, sci.logic, sci.math
On 11/17/2021 5:23 AM, Richard Damon wrote:
On 11/16/21 11:52 PM, olcott wrote:
On 11/16/2021 10:01 PM, Richard Damon wrote:
On 11/16/21 10:31 PM, olcott wrote:
#include <stdint.h>
typedef void (*ptr)();
int H(ptr x, ptr y)
{
x(y); // direct execution of P(P)
return 1;
}
// Minimal essence of Linz(1990) Ĥ
// and Strachey(1965) P
int P(ptr x)
{
H(x, x);
return 1;
}
int main(void)
{
H(P, P);
}
For every H that simulates or executes its input and aborts or does
not abort its input P never reaches its last instruction.
LIE.
First, the H you have defined above can NOT abort its processing of
its input, so you have a LIE in your specification.
The only one that came to mind is executing in as debugger.
Your H as Shown is NOT "executing in as a debugger", so still lying.
I show one H and the list the rest as hypothetical possibilities:
For every H that simulates or executes its input and aborts or does
not abort its input P never reaches its last instruction.
This allows be to correctly analyze the behavior of P that is executed / simulated by an infinite set of differently encoded x86 machine language representations of H. This whole [categorically exhaustively complete reasoning] thing seems far far too difficult for you to understand.
Second, By your own definition, the 'Halting' property of the input
needs to be determined by a PURE SIMULATION or DIRECT EXECUTION of
that input.
Not at all. I am only talking about a human bench checking what would
occur under the infinite set of specified H/P
Right, and you LIE, as if H is one of the H's that does abort its input
so it can return 0, and thus be a finite execution itself, that the P
that corresponds to that H is also finite, and thus the answer 0 is WRONG.
This is easily seen by just applying YOUR DEFINITION of halting, and
directly executing P(P) which YOU LIE by calling that a strawman.
An H that aborts its processing does NOT meet that requirement.
For every H that
simulates or
executes its input and
aborts or
does not abort its input
P never reaches its last instruction.
LIE.
If you statement refers to the ACTUAL behavior of the input, then it is
a LIE as I have previosly shown, as P(P) WILL halt for any H that does
aborts its input.
If you statement refers to the behavior of the input as seen by H, then
the statement is a LIE because you subject says you are talking about
the Halting Problem, and that behavior has nothing to do with the
Halting Problem if H does abort its operation.
If you do have an H that aborts its processing and returns 0, then if
we follow your definition and check that input by pure simulation or
direct execution (using something like you H above, but not changing
the H that P uses) then we see that P(P) will Halt.
If H does NOT abort its processing then yes, H does show that the
input for this case is non-halting, but never returns that value, so
fails to be a decider.
Your 'PROOF' that H is correct is just a LIE.
Yes, no H sees its processing of its input get to the last
instruction, but if H actually does say that P(P) is non-halting then
that P(P) will be halting.
--
Copyright 2021 Pete Olcott
Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)