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; // 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.

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

On 11/19/21 3:03 PM, olcott wrote:
> 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;  // 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.

>
> 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
>
>
>

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).

>>
>> 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

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.

For Linz's proof that you keep on talking about, given a 'claimed'
decider H, he creates a Turing Machine H^ by a specific formula, and
then asks that H to decide on the computation of Turing machine H^
applied to a description of that same Turing machine.

BY DEFINITION, the answer to this will be what the actual computation of
applying H^ to the description of H^ will do, which in our notation is
H^(<H^>)

The notation of asking that question is H(<H^>,<H^>)

or in you C notation, H(P,P) is asking what the actual computation P(P)
will do.

Since you are now saying that the the right answer for H(P,P) is NOT
bssed on the actual execution of the actual computation P(P), then BY
DEFINITION you have been lying for the past YEARS that you have actually
been working on the halting problem of Computation theory.

This is a simple fact.

Computation theory says that BY DEFINITION the correct answer for H(P,P)
would be based on the actual execution of P(P). PERIOD.

You claim you have the right answer for this, but your answer disagrees
with this definition.

You claim that you are allowed to change the definition, you can't.

You are thus PROVED be be a pathological liar, EVERYTHING you say can
just to be assumed to be a lie as it seems to be your default method of
speach, you continually use wrong definitions of words.

I don't think you even understand what it means for something to be true.

You yourself have quoted the truth about what happens to those who live
a life of lies, and you are clearly going to suffer that fate. That
seems inescapable at this point.

Sorry, you mind has lost all connection to the real truth.

YOU FAIL.

>
>
>>>
>>> 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
>>>
>>>
>>>
>>
>
>

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

On 11/19/21 11:20 PM, olcott wrote:
> 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.

LIE. There is not exception to the definition of a Halt Decider.

The Input to a Halt Decider is a decsription of the machine to be
decided on. PERIOD.

>
> 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.

Yes, And the input you provide, which by necessity includes ALL the
instructions thatget executed when you directly excute it (which thus
includes all of H) wil Halt.

The fact that you have chosen a system with a trival conversion between
representation and 'executable' form doesn't mean there isn't a logical
disctinction.

>
> 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.
>

Right, and when we directly execute that input, the code for P(P), when
H(P,P) will return 0, we see that it will halt. Thus 'The Input' Halts.

The execution trace in simple words when we do this:

1) P(P) starts

2) P(P) calls H(P,P)

3) The trace here can't be precisely stated as you haven't shown this
part of the input, but we know that H will simulate/execute P(P) for a
bit under its control and then abort this processing and return 0.

4) P(P) gets that returned value of 0

5) P(P) then reaches its end and Halts.

Thus, by your own definition, we have DIRECTLY EXECUTED the input, and
see that it Halts.

Thus the CORRECT answer for H(P,P) must be 1, Halting, but you LIE and
call the non-direct processing that H does a direct execution, which is
a LIE, and thus you INCORRECTLY claim the wrong answer.

You just seem to want to dance around the fact that even by YOUR
versions of the definitions, the behavior of the input is shown by
DIREcT EXECUTION to Halt. You want to try to deceptively call an aborted
simulation / debugger execution of this input a 'Direct Execution',
which is isn't.

You are stuck in a FATAL LIE.

The TRUTH is you are out of your league in this problem but your pride
(a deadly sin) keeps you from accepting it.

FAIL.

>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>