XPost: comp.theory, sci.logic, sci.math
On 11/19/2021 9:43 PM, Richard Damon wrote:
On 11/19/21 10:14 PM, olcott wrote:
On 11/19/2021 8:27 PM, Richard Damon wrote:
On 11/19/21 3:03 PM, olcott wrote:
typedef int (*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; // Give P a last instruction at the "c" level
}
int main(void)
{
H(P, P);
}
computation that halts
a computation is said to halt whenever it enters a final state.
(Linz:1990:234)
PSR set:
Combinations of H/P having pathological self-reference
For every possible H of H(P,P) invoked from main() where P(P) calls
this same H(P,P) and H simulates or executes its input and aborts or
does not abort its input P never reaches its last instruction.
PSR subset:
Because we know that the input to H(P,P) never halts for the whole
PSR set and a subset of these H/P combinations aborts the execution
or simulation of its input then we know that for this entire subset
the input to H(P,P) never halts and P(P) halts.
This conclusively proves when the input to H(P,P) never halts and
the same P(P) does halt that this does not form a contradiction.
??? Since the input to H(P,P) IS P(P) it can't do both.
You seem to mean that if the partial simulation done by H while
processing H(P,P) never reaches its halting state is not a
contradiction to the execution of P(P) reaching such a halting state.
That is true, but since the definition of the right answer to the
halting problem is the latter, claiming the the partial simulation
gives the right answer isn't a contradiction, it is just a out and
out LIE and a FALSEHOOD.
Fundamentally, you just don't understand what this 'input' stuff means.
FAIL you liar.
I have finally specified my point precisely and clearly enough that
any competent software engineer can totally understand what I am
saying even
with no knowledge of computer science or the halting problem.
On this basis I have totally proved that I know what "input" is in that
the above H(P,P) does directly invoke P(P).
So, I guess you are lying about working on the Halting Problem of
Computation theory and that your results apply to it.
The 'Input' to a Halt Decider MUST BE a description of the Computation
that the decider is to answer about.
Actually this is incorrect in the case where the input to the halt
decider specifies a [sequence of configurations] that never halts.
computation
The sequence of configurations leading to a halt state will be called a computation. (Linz:1990:238)
In the case of the x86 language we could provide the assembly language
source code as the "description" of a [sequence of configurations] or we
could simply provide the actual x86 machine code. Thus this description
is also directly executable.
In any case the input to H is shown to be directly executed and any
competent software engineer like you can tell that this same input could
also be simulated by an x86 emulator.
Halting problem undecidability and infinitely nested simulation (V2)
November 2021 PL Olcott
https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
--
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)