Brain dead Peter Olcott wrote:
> On 9/20/2022 9:47 PM, Richard Damon wrote:
>> On 9/20/22 10:40 PM, olcott wrote:
>>> On 9/20/2022 8:25 PM, Richard Damon wrote:
>>>>
>>>> On 9/20/22 8:53 PM, olcott wrote:
>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>> halting problem provided in the language of software
>>>>>>>>> engineering. Technical computer science terms are explained
>>>>>>>>> using software engineering terms. No knowledge of the halting
>>>>>>>>> problem is required.
>>>>>>>>>
>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>> opposite of whatever the halt decider decides) is the first
>>>>>>>>> argument to a simulating halt decider then this input becomes
>>>>>>>>> decidable as specifying infinitely recursive simulation.
>>>>>>>>
>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION has
>>>>>>>> finite behavior so NO CALL to it can be "infinite"
>>>>>>>>
>>>>>>> Another way that we can say this is that P specifies behavior
>>>>>>> that would never reach its own final state.
>>>>>>>
>>>>>>
>>>>>> No, because P DOES reach its final state when it is run
>>>>>
>>>>> // H(P,P) does not reach a final state when it is run
>>>>> int H(ptr x, ptr y)
>>>>> {
>>>>>    x(y);
>>>>> }
>>>>>
>>>>> I keep correcting you and you keep dishonestly forgetting these
>>>>> corrections. *That is the main reason that it seems you may be a liar*
>>>>>
>>>>
>>>> And you fail to notice that THIS H fails to ever answer when given
>>>> H(P,P) with P built from this H.
>>>
>>> Every H must form its halt status decision on the basis of the
>>> behavior of the above H. The question is what happens when the input
>>> is executed? Thus the above H is the measure of that.
>>>
>>
>> Nope. If the input doesn't call THAT H, then is incorrect to assume
>> the H they call is THAT H.
>
> As long as we can verify that the P of the H/P combination cannot
> possibly reach its final state we know that it is non-halting.

If H report P as non-halting, then P is halting. FAIL.

On 9/20/2022 9:55 PM, Richard Damon wrote:
> On 9/20/22 10:45 PM, olcott wrote:
>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>
>>> On 9/20/22 9:19 PM, olcott wrote:
>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>> Demented crank Peter Olcott wrote:
>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>> engineering. Technical computer science terms are explained
>>>>>>>>>> using software engineering terms. No knowledge of the halting
>>>>>>>>>> problem is required.
>>>>>>>>>>
>>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>>> opposite of whatever the halt decider decides) is the first
>>>>>>>>>> argument to a simulating halt decider then this input becomes
>>>>>>>>>> decidable as specifying infinitely recursive simulation.
>>>>>>>>>
>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION has
>>>>>>>>> finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>
>>>>>>>> Another way that we can say this is that P specifies behavior
>>>>>>>> that would never reach its own final state.
>>>>>>>>
>>>>>>>
>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>
>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>> int H(ptr x, ptr y)
>>>>>> {
>>>>>>    x(y);
>>>>>> }
>>>>>>
>>>>>> I keep correcting you and you keep dishonestly forgetting these
>>>>>> corrections. *That is the main reason that it seems you may be a
>>>>>> liar*
>>>>>
>>>>> The liar is the one who uses H as a unique name to qualify different
>>>>> functions. Make up your mind about how H is supposed to be an halt
>>>>> decider and you'll see that you cannot avoid Richard's objection
>>>>> to your silliness. Which the main argument for such an H not to
>>>>> exist in the first place. Word salad won't help you much.
>>>>>
>>>>> You are the liar, Peter.
>>>>
>>>> Every correct halt decider H must predict the behavior of its own
>>>> direct execution of its input even though it does not perform a
>>>> direct execution of this input.
>>>>
>>>>
>>>>
>>>
>>> And that statement is illogical because it asks what would happen if
>>> something does something that it doesn't do.
>>>
>>
>> A halt decider can correctly predict that an infinite loop never halts
>> without executing it. That you act like you keep forgetting this is
>> either dishonest or you actually keep forgetting it, thus dementia.
>>
>>
>>
>
> Yes, but if the loop isn't infinite (or not even a loop), it is
> incorrect to predict that it is.
>
> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>
Of every input P to every H that either simulates or executes its input
no H ever returns anything to P.

A halt decider must compute the mapping
FROM ITS INPUT
FROM ITS INPUT
FROM ITS INPUT
FROM ITS INPUT
FROM ITS INPUT
To an accept or reject state.

*No halt decider is allowed to give Jack shit about any non-inputs*

// H(P,P) for this H is the only direct execution
// of P(P) that any H is allowed to consider
int H(ptr x, ptr y)
{ x(y);
}

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 9/20/2022 10:04 PM, Python wrote:
> Idiot Peter Olcott wrote:
>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>
>>> On 9/20/22 9:19 PM, olcott wrote:
>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>> Demented crank Peter Olcott wrote:
>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>> engineering. Technical computer science terms are explained
>>>>>>>>>> using software engineering terms. No knowledge of the halting
>>>>>>>>>> problem is required.
>>>>>>>>>>
>>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>>> opposite of whatever the halt decider decides) is the first
>>>>>>>>>> argument to a simulating halt decider then this input becomes
>>>>>>>>>> decidable as specifying infinitely recursive simulation.
>>>>>>>>>
>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION has
>>>>>>>>> finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>
>>>>>>>> Another way that we can say this is that P specifies behavior
>>>>>>>> that would never reach its own final state.
>>>>>>>>
>>>>>>>
>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>
>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>> int H(ptr x, ptr y)
>>>>>> {
>>>>>>    x(y);
>>>>>> }
>>>>>>
>>>>>> I keep correcting you and you keep dishonestly forgetting these
>>>>>> corrections. *That is the main reason that it seems you may be a
>>>>>> liar*
>>>>>
>>>>> The liar is the one who uses H as a unique name to qualify different
>>>>> functions. Make up your mind about how H is supposed to be an halt
>>>>> decider and you'll see that you cannot avoid Richard's objection
>>>>> to your silliness. Which the main argument for such an H not to
>>>>> exist in the first place. Word salad won't help you much.
>>>>>
>>>>> You are the liar, Peter.
>>>>
>>>> Every correct halt decider H must predict the behavior of its own
>>>> direct execution of its input even though it does not perform a
>>>> direct execution of this input.
>>>>
>>>>
>>>>
>>>
>>> And that statement is illogical because it asks what would happen if
>>> something does something that it doesn't do.
>>>
>>
>> A halt decider can correctly predict that an infinite loop never halts
>> without executing it. That you act like you keep forgetting this is
>> either dishonest or you actually keep forgetting it, thus dementia.
>
> Such a halt decider *would* do so.
>
> But for any program of that kind it is trivial to build a counter
> example where whatever answer it provides is wrong.

I have spent 20,000 hours since 2004 showing otherwise.

*complete halt deciding system including*
*(a) x86utm operating system*
*(b) complete x86 emulator*
*(c) All of the various halt deciders and their inputs are contained in
Halt7.c*
https://liarparadox.org/2022_09_07.zip

This system currently only compiles under:
Microsoft Visual Studio Community 2017
https://visualstudio.microsoft.com/vs/older-downloads/

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 9/20/2022 10:08 PM, Python wrote:
> Stupid dying bigot Peter Olcott wrote:
>> On 9/20/2022 8:43 PM, Python wrote:
>>> Demented bigot crank Peter Olcott wrote:
>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>> Demented crank Peter Olcott wrote:
>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>> engineering. Technical computer science terms are explained
>>>>>>>>>> using software engineering terms. No knowledge of the halting
>>>>>>>>>> problem is required.
>>>>>>>>>>
>>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>>> opposite of whatever the halt decider decides) is the first
>>>>>>>>>> argument to a simulating halt decider then this input becomes
>>>>>>>>>> decidable as specifying infinitely recursive simulation.
>>>>>>>>>
>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION has
>>>>>>>>> finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>
>>>>>>>> Another way that we can say this is that P specifies behavior
>>>>>>>> that would never reach its own final state.
>>>>>>>>
>>>>>>>
>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>
>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>> int H(ptr x, ptr y)
>>>>>> {
>>>>>>    x(y);
>>>>>> }
>>>>>>
>>>>>> I keep correcting you and you keep dishonestly forgetting these
>>>>>> corrections. *That is the main reason that it seems you may be a
>>>>>> liar*
>>>>>
>>>>> The liar is the one who uses H as a unique name to qualify different
>>>>> functions. Make up your mind about how H is supposed to be an halt
>>>>> decider and you'll see that you cannot avoid Richard's objection
>>>>> to your silliness. Which the main argument for such an H not to
>>>>> exist in the first place. Word salad won't help you much.
>>>>>
>>>>> You are the liar, Peter.
>>>>
>>>> Every correct halt decider H must predict the behavior of its own
>>>> direct execution of its input even though it does not perform a
>>>> direct execution of this input.
>>>
>>> It must, but it can be shown that it fails for at least one of its
>>> inputs : P. Such an H does not exist. PERIOD.
>> Since no one in the last 12 months has been able to correctly point to
>> a single mistake in my work it is very implausible that it is incorrect.
>
> You are lying. Mistakes in your work have been pointed out.

These "mistakes" were always based on false assumptions.

> Also
> self-contradictions and evasive actions on your part.
>
> Not only you've been exposed as a liar, but also as an incompetent
> and a fool.
>

You don't know the material well enough to make this assessment.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 9/20/2022 10:09 PM, Python wrote:
> Brain dead Peter Olcott wrote:
>> On 9/20/2022 9:47 PM, Richard Damon wrote:
>>> On 9/20/22 10:40 PM, olcott wrote:
>>>> On 9/20/2022 8:25 PM, Richard Damon wrote:
>>>>>
>>>>> On 9/20/22 8:53 PM, olcott wrote:
>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>> engineering. Technical computer science terms are explained
>>>>>>>>>> using software engineering terms. No knowledge of the halting
>>>>>>>>>> problem is required.
>>>>>>>>>>
>>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>>> opposite of whatever the halt decider decides) is the first
>>>>>>>>>> argument to a simulating halt decider then this input becomes
>>>>>>>>>> decidable as specifying infinitely recursive simulation.
>>>>>>>>>
>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION has
>>>>>>>>> finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>
>>>>>>>> Another way that we can say this is that P specifies behavior
>>>>>>>> that would never reach its own final state.
>>>>>>>>
>>>>>>>
>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>
>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>> int H(ptr x, ptr y)
>>>>>> {
>>>>>>    x(y);
>>>>>> }
>>>>>>
>>>>>> I keep correcting you and you keep dishonestly forgetting these
>>>>>> corrections. *That is the main reason that it seems you may be a
>>>>>> liar*
>>>>>>
>>>>>
>>>>> And you fail to notice that THIS H fails to ever answer when given
>>>>> H(P,P) with P built from this H.
>>>>
>>>> Every H must form its halt status decision on the basis of the
>>>> behavior of the above H. The question is what happens when the input
>>>> is executed? Thus the above H is the measure of that.
>>>>
>>>
>>> Nope. If the input doesn't call THAT H, then is incorrect to assume
>>> the H they call is THAT H.
>>
>> As long as we can verify that the P of the H/P combination cannot
>> possibly reach its final state we know that it is non-halting.
>
> If H report P as non-halting, then P is halting. FAIL.

If H reports that P is non-halting then every instance of P has been
aborted and none of them do jack shit.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 9/20/22 11:08 PM, olcott wrote:
> On 9/20/2022 9:55 PM, Richard Damon wrote:
>> On 9/20/22 10:45 PM, olcott wrote:
>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>
>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>> Demented crank Peter Olcott wrote:
>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>>> engineering. Technical computer science terms are explained
>>>>>>>>>>> using software engineering terms. No knowledge of the halting
>>>>>>>>>>> problem is required.
>>>>>>>>>>>
>>>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>>>> opposite of whatever the halt decider decides) is the first
>>>>>>>>>>> argument to a simulating halt decider then this input becomes
>>>>>>>>>>> decidable as specifying infinitely recursive simulation.
>>>>>>>>>>
>>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION has
>>>>>>>>>> finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>>
>>>>>>>>> Another way that we can say this is that P specifies behavior
>>>>>>>>> that would never reach its own final state.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>
>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>> int H(ptr x, ptr y)
>>>>>>> {
>>>>>>>    x(y);
>>>>>>> }
>>>>>>>
>>>>>>> I keep correcting you and you keep dishonestly forgetting these
>>>>>>> corrections. *That is the main reason that it seems you may be a
>>>>>>> liar*
>>>>>>
>>>>>> The liar is the one who uses H as a unique name to qualify different
>>>>>> functions. Make up your mind about how H is supposed to be an halt
>>>>>> decider and you'll see that you cannot avoid Richard's objection
>>>>>> to your silliness. Which the main argument for such an H not to
>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>
>>>>>> You are the liar, Peter.
>>>>>
>>>>> Every correct halt decider H must predict the behavior of its own
>>>>> direct execution of its input even though it does not perform a
>>>>> direct execution of this input.
>>>>>
>>>>>
>>>>>
>>>>
>>>> And that statement is illogical because it asks what would happen if
>>>> something does something that it doesn't do.
>>>>
>>>
>>> A halt decider can correctly predict that an infinite loop never
>>> halts without executing it. That you act like you keep forgetting
>>> this is either dishonest or you actually keep forgetting it, thus
>>> dementia.
>>>
>>>
>>>
>>
>> Yes, but if the loop isn't infinite (or not even a loop), it is
>> incorrect to predict that it is.
>>
>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>
> Of every input P to every H that either simulates or executes its input
> no H ever returns anything to P.
>
> A halt decider must compute the mapping
> FROM ITS INPUT
> FROM ITS INPUT
> FROM ITS INPUT
> FROM ITS INPUT
> FROM ITS INPUT
> To an accept or reject state.

Right, the input is the representation of P and its input P

The RIGHT answer is if that machine P given the input P would Halt.

>
> *No halt decider is allowed to give Jack shit about any non-inputs*

But it isn't. The behavior of P(P) is PRECISELY defined from the input
given to it.

You just don't seem to understand that.

If you want to claim it can't, then you are just DEFINIING that it is
impossible to even define a Halt Decider, so of course they can't exist.

>
> // H(P,P) for this H is the only direct execution
> // of P(P) that any H is allowed to consider
> int H(ptr x, ptr y)
> {
>   x(y);
> }
>
>

And P doesn't call THAT H, so THAT is a "non-input"

FAIL.

Hoisted on your own petard.

You are just PROVING how stupid you are.

FAIL,

On 9/20/22 11:12 PM, olcott wrote:
> On 9/20/2022 10:08 PM, Python wrote:
>> Stupid dying bigot Peter Olcott wrote:
>>> On 9/20/2022 8:43 PM, Python wrote:
>>>> Demented bigot crank Peter Olcott wrote:
>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>> Demented crank Peter Olcott wrote:
>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>>> engineering. Technical computer science terms are explained
>>>>>>>>>>> using software engineering terms. No knowledge of the halting
>>>>>>>>>>> problem is required.
>>>>>>>>>>>
>>>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>>>> opposite of whatever the halt decider decides) is the first
>>>>>>>>>>> argument to a simulating halt decider then this input becomes
>>>>>>>>>>> decidable as specifying infinitely recursive simulation.
>>>>>>>>>>
>>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION has
>>>>>>>>>> finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>>
>>>>>>>>> Another way that we can say this is that P specifies behavior
>>>>>>>>> that would never reach its own final state.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>
>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>> int H(ptr x, ptr y)
>>>>>>> {
>>>>>>>    x(y);
>>>>>>> }
>>>>>>>
>>>>>>> I keep correcting you and you keep dishonestly forgetting these
>>>>>>> corrections. *That is the main reason that it seems you may be a
>>>>>>> liar*
>>>>>>
>>>>>> The liar is the one who uses H as a unique name to qualify different
>>>>>> functions. Make up your mind about how H is supposed to be an halt
>>>>>> decider and you'll see that you cannot avoid Richard's objection
>>>>>> to your silliness. Which the main argument for such an H not to
>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>
>>>>>> You are the liar, Peter.
>>>>>
>>>>> Every correct halt decider H must predict the behavior of its own
>>>>> direct execution of its input even though it does not perform a
>>>>> direct execution of this input.
>>>>
>>>> It must, but it can be shown that it fails for at least one of its
>>>> inputs : P. Such an H does not exist. PERIOD.
>>> Since no one in the last 12 months has been able to correctly point
>>> to a single mistake in my work it is very implausible that it is
>>> incorrect.
>>
>> You are lying. Mistakes in your work have been pointed out.
>
> These "mistakes" were always based on false assumptions.
>
>> Also
>> self-contradictions and evasive actions on your part.
>>
>> Not only you've been exposed as a liar, but also as an incompetent
>> and a fool.
>>
>
> You don't know the material well enough to make this assessment.
>

Neither do you as you have shown.

FAIL.

On 9/20/2022 10:07 PM, Richard Damon wrote:
> On 9/20/22 11:00 PM, olcott wrote:
>> On 9/20/2022 9:47 PM, Richard Damon wrote:
>>> On 9/20/22 10:40 PM, olcott wrote:
>>>> On 9/20/2022 8:25 PM, Richard Damon wrote:
>>>>>
>>>>> On 9/20/22 8:53 PM, olcott wrote:
>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>> engineering. Technical computer science terms are explained
>>>>>>>>>> using software engineering terms. No knowledge of the halting
>>>>>>>>>> problem is required.
>>>>>>>>>>
>>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>>> opposite of whatever the halt decider decides) is the first
>>>>>>>>>> argument to a simulating halt decider then this input becomes
>>>>>>>>>> decidable as specifying infinitely recursive simulation.
>>>>>>>>>
>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION has
>>>>>>>>> finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>
>>>>>>>> Another way that we can say this is that P specifies behavior
>>>>>>>> that would never reach its own final state.
>>>>>>>>
>>>>>>>
>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>
>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>> int H(ptr x, ptr y)
>>>>>> {
>>>>>>    x(y);
>>>>>> }
>>>>>>
>>>>>> I keep correcting you and you keep dishonestly forgetting these
>>>>>> corrections. *That is the main reason that it seems you may be a
>>>>>> liar*
>>>>>>
>>>>>
>>>>> And you fail to notice that THIS H fails to ever answer when given
>>>>> H(P,P) with P built from this H.
>>>>
>>>> Every H must form its halt status decision on the basis of the
>>>> behavior of the above H. The question is what happens when the input
>>>> is executed? Thus the above H is the measure of that.
>>>>
>>>
>>> Nope. If the input doesn't call THAT H, then is incorrect to assume
>>> the H they call is THAT H.
>>
>> As long as we can verify that the P of the H/P combination cannot
>> possibly reach its final state we know that it is non-halting.
>>
>>
>>
>
> Except that we CAN verify that a CORRECT AND COMPLETE simulation of that
> P DOES reach the final state. Its just that the H you propose doesn't do
> that because it aborts.
>

That is the strawman deception. No input to H(P,P) ever reaches the
final state of this simulated or executed input.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 9/20/2022 10:16 PM, Richard Damon wrote:
>
> On 9/20/22 11:08 PM, olcott wrote:
>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>> On 9/20/22 10:45 PM, olcott wrote:
>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>
>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>>>> engineering. Technical computer science terms are explained
>>>>>>>>>>>> using software engineering terms. No knowledge of the
>>>>>>>>>>>> halting problem is required.
>>>>>>>>>>>>
>>>>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>>>>> opposite of whatever the halt decider decides) is the first
>>>>>>>>>>>> argument to a simulating halt decider then this input
>>>>>>>>>>>> becomes decidable as specifying infinitely recursive
>>>>>>>>>>>> simulation.
>>>>>>>>>>>
>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION has
>>>>>>>>>>> finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>>>
>>>>>>>>>> Another way that we can say this is that P specifies behavior
>>>>>>>>>> that would never reach its own final state.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>
>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>> int H(ptr x, ptr y)
>>>>>>>> {
>>>>>>>>    x(y);
>>>>>>>> }
>>>>>>>>
>>>>>>>> I keep correcting you and you keep dishonestly forgetting these
>>>>>>>> corrections. *That is the main reason that it seems you may be a
>>>>>>>> liar*
>>>>>>>
>>>>>>> The liar is the one who uses H as a unique name to qualify different
>>>>>>> functions. Make up your mind about how H is supposed to be an halt
>>>>>>> decider and you'll see that you cannot avoid Richard's objection
>>>>>>> to your silliness. Which the main argument for such an H not to
>>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>>
>>>>>>> You are the liar, Peter.
>>>>>>
>>>>>> Every correct halt decider H must predict the behavior of its own
>>>>>> direct execution of its input even though it does not perform a
>>>>>> direct execution of this input.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> And that statement is illogical because it asks what would happen
>>>>> if something does something that it doesn't do.
>>>>>
>>>>
>>>> A halt decider can correctly predict that an infinite loop never
>>>> halts without executing it. That you act like you keep forgetting
>>>> this is either dishonest or you actually keep forgetting it, thus
>>>> dementia.
>>>>
>>>>
>>>>
>>>
>>> Yes, but if the loop isn't infinite (or not even a loop), it is
>>> incorrect to predict that it is.
>>>
>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>
>> Of every input P to every H that either simulates or executes its
>> input no H ever returns anything to P.
>>
>> A halt decider must compute the mapping
>> FROM ITS INPUT
>> FROM ITS INPUT
>> FROM ITS INPUT
>> FROM ITS INPUT
>> FROM ITS INPUT
>> To an accept or reject state.
>
> Right, the input is the representation of P and its input P
>
It is the actual behavior of the actual executed or simulated input.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 9/20/22 11:20 PM, olcott wrote:
> On 9/20/2022 10:07 PM, Richard Damon wrote:
>> On 9/20/22 11:00 PM, olcott wrote:
>>> On 9/20/2022 9:47 PM, Richard Damon wrote:
>>>> On 9/20/22 10:40 PM, olcott wrote:
>>>>> On 9/20/2022 8:25 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 9/20/22 8:53 PM, olcott wrote:
>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>>> engineering. Technical computer science terms are explained
>>>>>>>>>>> using software engineering terms. No knowledge of the halting
>>>>>>>>>>> problem is required.
>>>>>>>>>>>
>>>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>>>> opposite of whatever the halt decider decides) is the first
>>>>>>>>>>> argument to a simulating halt decider then this input becomes
>>>>>>>>>>> decidable as specifying infinitely recursive simulation.
>>>>>>>>>>
>>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION has
>>>>>>>>>> finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>>
>>>>>>>>> Another way that we can say this is that P specifies behavior
>>>>>>>>> that would never reach its own final state.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>
>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>> int H(ptr x, ptr y)
>>>>>>> {
>>>>>>>    x(y);
>>>>>>> }
>>>>>>>
>>>>>>> I keep correcting you and you keep dishonestly forgetting these
>>>>>>> corrections. *That is the main reason that it seems you may be a
>>>>>>> liar*
>>>>>>>
>>>>>>
>>>>>> And you fail to notice that THIS H fails to ever answer when given
>>>>>> H(P,P) with P built from this H.
>>>>>
>>>>> Every H must form its halt status decision on the basis of the
>>>>> behavior of the above H. The question is what happens when the
>>>>> input is executed? Thus the above H is the measure of that.
>>>>>
>>>>
>>>> Nope. If the input doesn't call THAT H, then is incorrect to assume
>>>> the H they call is THAT H.
>>>
>>> As long as we can verify that the P of the H/P combination cannot
>>> possibly reach its final state we know that it is non-halting.
>>>
>>>
>>>
>>
>> Except that we CAN verify that a CORRECT AND COMPLETE simulation of
>> that P DOES reach the final state. Its just that the H you propose
>> doesn't do that because it aborts.
>>
>
> That is the strawman deception. No input to H(P,P) ever reaches the
> final state of this simulated or executed input.
>

You just don't understand the simulation being asked for.

I HAVE listed the simulation that shows that the simulation of the input
to H(P,P) does reach a final state, and you have not even tried to point
out an error in that listing.

The problem is you don't seem to understand that this simulation doesn't
need to be done by H, and in fact, CAN'T be done by H and have it give
the non-halting answer.

YOUR arguement is the Strawman.

You are just showing you don't understand the basic meanings of the
basic words.

You are just proving you are too stupid to understand what you are
talking about.

FAIL.

On 9/20/22 11:15 PM, olcott wrote:
> On 9/20/2022 10:09 PM, Python wrote:
>> Brain dead Peter Olcott wrote:
>>> On 9/20/2022 9:47 PM, Richard Damon wrote:
>>>> On 9/20/22 10:40 PM, olcott wrote:
>>>>> On 9/20/2022 8:25 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 9/20/22 8:53 PM, olcott wrote:
>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>>> engineering. Technical computer science terms are explained
>>>>>>>>>>> using software engineering terms. No knowledge of the halting
>>>>>>>>>>> problem is required.
>>>>>>>>>>>
>>>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>>>> opposite of whatever the halt decider decides) is the first
>>>>>>>>>>> argument to a simulating halt decider then this input becomes
>>>>>>>>>>> decidable as specifying infinitely recursive simulation.
>>>>>>>>>>
>>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION has
>>>>>>>>>> finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>>
>>>>>>>>> Another way that we can say this is that P specifies behavior
>>>>>>>>> that would never reach its own final state.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>
>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>> int H(ptr x, ptr y)
>>>>>>> {
>>>>>>>    x(y);
>>>>>>> }
>>>>>>>
>>>>>>> I keep correcting you and you keep dishonestly forgetting these
>>>>>>> corrections. *That is the main reason that it seems you may be a
>>>>>>> liar*
>>>>>>>
>>>>>>
>>>>>> And you fail to notice that THIS H fails to ever answer when given
>>>>>> H(P,P) with P built from this H.
>>>>>
>>>>> Every H must form its halt status decision on the basis of the
>>>>> behavior of the above H. The question is what happens when the
>>>>> input is executed? Thus the above H is the measure of that.
>>>>>
>>>>
>>>> Nope. If the input doesn't call THAT H, then is incorrect to assume
>>>> the H they call is THAT H.
>>>
>>> As long as we can verify that the P of the H/P combination cannot
>>> possibly reach its final state we know that it is non-halting.
>>
>> If H report P as non-halting, then P is halting. FAIL.
>
> If H reports that P is non-halting then every instance of P has been
> aborted and none of them do jack shit.
>
>

Nope, the DIRECT execution of P(P), or the running of UTM(P,P) still
exist and show that the input is halting.

You are just PROVING you don't understand anything about computations.

You seem to think that only one computer exists in the universe.

This shows how stupid you are.

On 9/20/22 11:38 PM, olcott wrote:
> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>
>> On 9/20/22 11:08 PM, olcott wrote:
>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>>>>> engineering. Technical computer science terms are explained
>>>>>>>>>>>>> using software engineering terms. No knowledge of the
>>>>>>>>>>>>> halting problem is required.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>>>>>> opposite of whatever the halt decider decides) is the first
>>>>>>>>>>>>> argument to a simulating halt decider then this input
>>>>>>>>>>>>> becomes decidable as specifying infinitely recursive
>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>
>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION has
>>>>>>>>>>>> finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>>>>
>>>>>>>>>>> Another way that we can say this is that P specifies behavior
>>>>>>>>>>> that would never reach its own final state.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>>
>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>> {
>>>>>>>>>    x(y);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> I keep correcting you and you keep dishonestly forgetting these
>>>>>>>>> corrections. *That is the main reason that it seems you may be
>>>>>>>>> a liar*
>>>>>>>>
>>>>>>>> The liar is the one who uses H as a unique name to qualify
>>>>>>>> different
>>>>>>>> functions. Make up your mind about how H is supposed to be an halt
>>>>>>>> decider and you'll see that you cannot avoid Richard's objection
>>>>>>>> to your silliness. Which the main argument for such an H not to
>>>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>>>
>>>>>>>> You are the liar, Peter.
>>>>>>>
>>>>>>> Every correct halt decider H must predict the behavior of its own
>>>>>>> direct execution of its input even though it does not perform a
>>>>>>> direct execution of this input.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> And that statement is illogical because it asks what would happen
>>>>>> if something does something that it doesn't do.
>>>>>>
>>>>>
>>>>> A halt decider can correctly predict that an infinite loop never
>>>>> halts without executing it. That you act like you keep forgetting
>>>>> this is either dishonest or you actually keep forgetting it, thus
>>>>> dementia.
>>>>>
>>>>>
>>>>>
>>>>
>>>> Yes, but if the loop isn't infinite (or not even a loop), it is
>>>> incorrect to predict that it is.
>>>>
>>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>>
>>> Of every input P to every H that either simulates or executes its
>>> input no H ever returns anything to P.
>>>
>>> A halt decider must compute the mapping
>>> FROM ITS INPUT
>>> FROM ITS INPUT
>>> FROM ITS INPUT
>>> FROM ITS INPUT
>>> FROM ITS INPUT
>>> To an accept or reject state.
>>
>> Right, the input is the representation of P and its input P
>>
> It is the actual behavior of the actual executed or simulated input.
>

Which means, for H(P,P) the running of P(P) or UTM(P,P) as independent
computaitons.

Those Halt.

Your understanding of it being only by H is proven to be illogical.

Your instance on it shows that YOU are ILLOGICAL.

You are just too stupid to understand what you are talking about.

You have dug your hole so deep you are stuck in it and you arguement is
buried in your lies.

You have wasted you last 18 years of your life and have proven yourself
to be an ignorant patholgically lying idiot.

FAIL.

On 9/20/2022 10:42 PM, Richard Damon wrote:
> On 9/20/22 11:20 PM, olcott wrote:
>> On 9/20/2022 10:07 PM, Richard Damon wrote:
>>> On 9/20/22 11:00 PM, olcott wrote:
>>>> On 9/20/2022 9:47 PM, Richard Damon wrote:
>>>>> On 9/20/22 10:40 PM, olcott wrote:
>>>>>> On 9/20/2022 8:25 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 9/20/22 8:53 PM, olcott wrote:
>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>>>> engineering. Technical computer science terms are explained
>>>>>>>>>>>> using software engineering terms. No knowledge of the
>>>>>>>>>>>> halting problem is required.
>>>>>>>>>>>>
>>>>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>>>>> opposite of whatever the halt decider decides) is the first
>>>>>>>>>>>> argument to a simulating halt decider then this input
>>>>>>>>>>>> becomes decidable as specifying infinitely recursive
>>>>>>>>>>>> simulation.
>>>>>>>>>>>
>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION has
>>>>>>>>>>> finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>>>
>>>>>>>>>> Another way that we can say this is that P specifies behavior
>>>>>>>>>> that would never reach its own final state.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>
>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>> int H(ptr x, ptr y)
>>>>>>>> {
>>>>>>>>    x(y);
>>>>>>>> }
>>>>>>>>
>>>>>>>> I keep correcting you and you keep dishonestly forgetting these
>>>>>>>> corrections. *That is the main reason that it seems you may be a
>>>>>>>> liar*
>>>>>>>>
>>>>>>>
>>>>>>> And you fail to notice that THIS H fails to ever answer when
>>>>>>> given H(P,P) with P built from this H.
>>>>>>
>>>>>> Every H must form its halt status decision on the basis of the
>>>>>> behavior of the above H. The question is what happens when the
>>>>>> input is executed? Thus the above H is the measure of that.
>>>>>>
>>>>>
>>>>> Nope. If the input doesn't call THAT H, then is incorrect to assume
>>>>> the H they call is THAT H.
>>>>
>>>> As long as we can verify that the P of the H/P combination cannot
>>>> possibly reach its final state we know that it is non-halting.
>>>>
>>>>
>>>>
>>>
>>> Except that we CAN verify that a CORRECT AND COMPLETE simulation of
>>> that P DOES reach the final state. Its just that the H you propose
>>> doesn't do that because it aborts.
>>>
>>
>> That is the strawman deception. No input to H(P,P) ever reaches the
>> final state of this simulated or executed input.
>>
>
> You just don't understand the simulation being asked for.
>
No one can show that it makes any sense that H need examine anything
besides the actual behavior of the directly executed or simulated input
to H.

That you say that it must be some other behavior of something else is
not believable, I do not accept that you really believe this.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 9/20/2022 10:47 PM, Richard Damon wrote:
> On 9/20/22 11:38 PM, olcott wrote:
>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>
>>> On 9/20/22 11:08 PM, olcott wrote:
>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>>>>>> engineering. Technical computer science terms are
>>>>>>>>>>>>>> explained using software engineering terms. No knowledge
>>>>>>>>>>>>>> of the halting problem is required.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>>>>>>> opposite of whatever the halt decider decides) is the
>>>>>>>>>>>>>> first argument to a simulating halt decider then this
>>>>>>>>>>>>>> input becomes decidable as specifying infinitely recursive
>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION
>>>>>>>>>>>>> has finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>>>>>
>>>>>>>>>>>> Another way that we can say this is that P specifies
>>>>>>>>>>>> behavior that would never reach its own final state.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>>>
>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>> {
>>>>>>>>>>    x(y);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> I keep correcting you and you keep dishonestly forgetting
>>>>>>>>>> these corrections. *That is the main reason that it seems you
>>>>>>>>>> may be a liar*
>>>>>>>>>
>>>>>>>>> The liar is the one who uses H as a unique name to qualify
>>>>>>>>> different
>>>>>>>>> functions. Make up your mind about how H is supposed to be an halt
>>>>>>>>> decider and you'll see that you cannot avoid Richard's objection
>>>>>>>>> to your silliness. Which the main argument for such an H not to
>>>>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>>>>
>>>>>>>>> You are the liar, Peter.
>>>>>>>>
>>>>>>>> Every correct halt decider H must predict the behavior of its
>>>>>>>> own direct execution of its input even though it does not
>>>>>>>> perform a direct execution of this input.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> And that statement is illogical because it asks what would happen
>>>>>>> if something does something that it doesn't do.
>>>>>>>
>>>>>>
>>>>>> A halt decider can correctly predict that an infinite loop never
>>>>>> halts without executing it. That you act like you keep forgetting
>>>>>> this is either dishonest or you actually keep forgetting it, thus
>>>>>> dementia.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Yes, but if the loop isn't infinite (or not even a loop), it is
>>>>> incorrect to predict that it is.
>>>>>
>>>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>>>
>>>> Of every input P to every H that either simulates or executes its
>>>> input no H ever returns anything to P.
>>>>
>>>> A halt decider must compute the mapping
>>>> FROM ITS INPUT
>>>> FROM ITS INPUT
>>>> FROM ITS INPUT
>>>> FROM ITS INPUT
>>>> FROM ITS INPUT
>>>> To an accept or reject state.
>>>
>>> Right, the input is the representation of P and its input P
>>>
>> It is the actual behavior of the actual executed or simulated input.
>>
>
> Which means, for H(P,P) the running of P(P) or UTM(P,P) as independent
> computaitons.
>
> Those Halt.

H is only allowed to report on the behavior that it sees.
H is NOT allowed to report on behavior that it does not see.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

Op 20.sep..2022 om 17:43 schreef olcott:
> This is an explanation of a possible new insight into the halting
> problem provided in the language of software engineering. Technical
> computer science terms are explained using software engineering terms.
> No knowledge of the halting problem is required.
>
> When the conventional “pathological” input (that does the opposite of
> whatever the halt decider decides) is the first argument to a simulating
> halt decider then this input becomes decidable as specifying infinitely
> recursive simulation.
>
> This paper is based on fully operational software executed in the x86utm
> operating system. The x86utm operating system (based on an excellent
> open source x86 emulator) was created to study the details of the
> halting problem proof counter-examples at the much higher level of
> abstraction of C/x86.
>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> // P does the opposite of whatever H decides
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)    // if H(P,P) reports that its input halts
>     HERE: goto HERE;  // P loops and never halts
>   return;             // else P halts
> }

It must be said that this P is only an example of a program that does
the opposite of what H decides. There are main other ways to do that. A
decider should not only correctly decide on one such program, but it
should decide on all of them correctly. That is much more difficult to
prove. E.g., if P does not call H directly, but uses a simulator to see
what H does:

void P(ptr x)
{ int Halt_Status = simulate (H, x, x);
if (Halt_Status) // if H(P,P) reports that its input halts
HERE: goto HERE; // P loops and never halts
return; // else P halts
}

where simulate is P's own simulator.

Would your decider be able to decide on this P correctly in finite time,
in order to qualify itself as a decider?

>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> // This H(P,P) specifies the direct execution of P(P)
> // which obviously never stops running
> int H(ptr x, ptr y)
> {
>   x(y);
> }
>
> Halting: is defined as reaching the last instruction (AKA final state)
> and stopping.
>
> When an H is defined that correctly determines that the above direct
> execution of P(P) would never reach its “return” instruction (AKA final
> state) the conventional halting problem proofs are refuted.
>
> All halt deciders are intended to predict the behavior of their inputs
> without actually executing these inputs because the halt decider itself
> must always halt. The method used to determine that the above P(P) never
> halts is a slight adaptation of a similar method that correctly detects
> infinite recursion.
>
> When a correct non-halting behavior pattern is matched a simulating halt
> decider (SHD) aborts its simulation and returns 0. Halting does not mean
> stops running, halting only means reaching the last instruction and
> stops running.
>
> Because we can see that the direct execution of P(P) from H would never
> reach the last “return” instruction of P we know that no complete or
> partial simulation of P by H would ever reach this last instruction of
> P. From this we know that P is non-halting.
>

On 9/20/22 11:57 PM, olcott wrote:
> On 9/20/2022 10:47 PM, Richard Damon wrote:
>> On 9/20/22 11:38 PM, olcott wrote:
>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>
>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>>>>>>> engineering. Technical computer science terms are
>>>>>>>>>>>>>>> explained using software engineering terms. No knowledge
>>>>>>>>>>>>>>> of the halting problem is required.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>>>>>>>> opposite of whatever the halt decider decides) is the
>>>>>>>>>>>>>>> first argument to a simulating halt decider then this
>>>>>>>>>>>>>>> input becomes decidable as specifying infinitely
>>>>>>>>>>>>>>> recursive simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION
>>>>>>>>>>>>>> has finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Another way that we can say this is that P specifies
>>>>>>>>>>>>> behavior that would never reach its own final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>>>>
>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>> {
>>>>>>>>>>>    x(y);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> I keep correcting you and you keep dishonestly forgetting
>>>>>>>>>>> these corrections. *That is the main reason that it seems you
>>>>>>>>>>> may be a liar*
>>>>>>>>>>
>>>>>>>>>> The liar is the one who uses H as a unique name to qualify
>>>>>>>>>> different
>>>>>>>>>> functions. Make up your mind about how H is supposed to be an
>>>>>>>>>> halt
>>>>>>>>>> decider and you'll see that you cannot avoid Richard's objection
>>>>>>>>>> to your silliness. Which the main argument for such an H not to
>>>>>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>>>>>
>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>
>>>>>>>>> Every correct halt decider H must predict the behavior of its
>>>>>>>>> own direct execution of its input even though it does not
>>>>>>>>> perform a direct execution of this input.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> And that statement is illogical because it asks what would
>>>>>>>> happen if something does something that it doesn't do.
>>>>>>>>
>>>>>>>
>>>>>>> A halt decider can correctly predict that an infinite loop never
>>>>>>> halts without executing it. That you act like you keep forgetting
>>>>>>> this is either dishonest or you actually keep forgetting it, thus
>>>>>>> dementia.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Yes, but if the loop isn't infinite (or not even a loop), it is
>>>>>> incorrect to predict that it is.
>>>>>>
>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>>>>
>>>>> Of every input P to every H that either simulates or executes its
>>>>> input no H ever returns anything to P.
>>>>>
>>>>> A halt decider must compute the mapping
>>>>> FROM ITS INPUT
>>>>> FROM ITS INPUT
>>>>> FROM ITS INPUT
>>>>> FROM ITS INPUT
>>>>> FROM ITS INPUT
>>>>> To an accept or reject state.
>>>>
>>>> Right, the input is the representation of P and its input P
>>>>
>>> It is the actual behavior of the actual executed or simulated input.
>>>
>>
>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as independent
>> computaitons.
>>
>> Those Halt.
>
> H is only allowed to report on the behavior that it sees.
> H is NOT allowed to report on behavior that it does not see.
>
>

Nope. That isn't the definition.

If that WAS the definition, then you can't even define a Halting decider.

Even the definition you are putting forward for H is having it reporting
on behavior that it doesn't see, that is the behavior of the OTHER
version of H, that it doesn't actually see happen, only presume.

You are just showing your ignorance of the field, and the illogic of
your thoughts. Your ideas are NOT consistent but a fantasy of your mind.

You have wasted the last 18 years of your life and buried your
reputation under your pile of lies.

You have proven that you are an ignorant pathological lying idiot.

You have Failed.

On 9/20/22 11:55 PM, olcott wrote:
> On 9/20/2022 10:42 PM, Richard Damon wrote:
>> On 9/20/22 11:20 PM, olcott wrote:
>>> On 9/20/2022 10:07 PM, Richard Damon wrote:
>>>> On 9/20/22 11:00 PM, olcott wrote:
>>>>> On 9/20/2022 9:47 PM, Richard Damon wrote:
>>>>>> On 9/20/22 10:40 PM, olcott wrote:
>>>>>>> On 9/20/2022 8:25 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 9/20/22 8:53 PM, olcott wrote:
>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>> This is an explanation of a possible new insight into the
>>>>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>>>>> engineering. Technical computer science terms are explained
>>>>>>>>>>>>> using software engineering terms. No knowledge of the
>>>>>>>>>>>>> halting problem is required.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When the conventional “pathological” input (that does the
>>>>>>>>>>>>> opposite of whatever the halt decider decides) is the first
>>>>>>>>>>>>> argument to a simulating halt decider then this input
>>>>>>>>>>>>> becomes decidable as specifying infinitely recursive
>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>
>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION has
>>>>>>>>>>>> finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>>>>
>>>>>>>>>>> Another way that we can say this is that P specifies behavior
>>>>>>>>>>> that would never reach its own final state.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>>
>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>> {
>>>>>>>>>    x(y);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> I keep correcting you and you keep dishonestly forgetting these
>>>>>>>>> corrections. *That is the main reason that it seems you may be
>>>>>>>>> a liar*
>>>>>>>>>
>>>>>>>>
>>>>>>>> And you fail to notice that THIS H fails to ever answer when
>>>>>>>> given H(P,P) with P built from this H.
>>>>>>>
>>>>>>> Every H must form its halt status decision on the basis of the
>>>>>>> behavior of the above H. The question is what happens when the
>>>>>>> input is executed? Thus the above H is the measure of that.
>>>>>>>
>>>>>>
>>>>>> Nope. If the input doesn't call THAT H, then is incorrect to
>>>>>> assume the H they call is THAT H.
>>>>>
>>>>> As long as we can verify that the P of the H/P combination cannot
>>>>> possibly reach its final state we know that it is non-halting.
>>>>>
>>>>>
>>>>>
>>>>
>>>> Except that we CAN verify that a CORRECT AND COMPLETE simulation of
>>>> that P DOES reach the final state. Its just that the H you propose
>>>> doesn't do that because it aborts.
>>>>
>>>
>>> That is the strawman deception. No input to H(P,P) ever reaches the
>>> final state of this simulated or executed input.
>>>
>>
>> You just don't understand the simulation being asked for.
>>
> No one can show that it makes any sense that H need examine anything
> besides the actual behavior of the directly executed or simulated input
> to H.
>

That is what it needs to etry to examine and report on. The
INDEPENDENTLY directly executed or simulated input.

It needs to be the INDEPENDENT operation, as it can take infinite time,
and being a decider, H can't do that. And any definition that says it
must is illogical and invalid.

> That you say that it must be some other behavior of something else is
> not believable, I do not accept that you really believe this.
>
>

It isn't some other behavir, it just is behavior done by an independent
entity, becaue H can't do it and meet its requirements.

It is IMPOSSIBLE to build a machine to simulataniously simulate an input
for an infinite number of steps and also return an answer in finite time.

Your thinking that is what H needs to do just shows your ignorance of
the field, and your stupidity to think it is even possible.

On 9/21/2022 3:14 AM, Fred. Zwarts wrote:
> Op 20.sep..2022 om 17:43 schreef olcott:
>> This is an explanation of a possible new insight into the halting
>> problem provided in the language of software engineering. Technical
>> computer science terms are explained using software engineering terms.
>> No knowledge of the halting problem is required.
>>
>> When the conventional “pathological” input (that does the opposite of
>> whatever the halt decider decides) is the first argument to a
>> simulating halt decider then this input becomes decidable as
>> specifying infinitely recursive simulation.
>>
>> This paper is based on fully operational software executed in the
>> x86utm operating system. The x86utm operating system (based on an
>> excellent open source x86 emulator) was created to study the details
>> of the halting problem proof counter-examples at the much higher level
>> of abstraction of C/x86.
>>
>> typedef void (*ptr)();
>> int H(ptr p, ptr i); // simulating halt decider
>>
>> // P does the opposite of whatever H decides
>> void P(ptr x)
>> {
>>    int Halt_Status = H(x, x);
>>    if (Halt_Status)    // if H(P,P) reports that its input halts
>>      HERE: goto HERE;  // P loops and never halts
>>    return;             // else P halts
>> }
>
> It must be said that this P is only an example of a program that does
> the opposite of what H decides. There are main other ways to do that. A
> decider should not only correctly decide on one such program, but it
> should decide on all of them correctly. That is much more difficult to
> prove. E.g., if P does not call H directly, but uses a simulator to see
> what H does:
>
> void P(ptr x)
> {
>   int Halt_Status = simulate (H, x, x);
>   if (Halt_Status)    // if H(P,P) reports that its input halts
>     HERE: goto HERE;  // P loops and never halts
>   return;             // else P halts
> }
>
> where simulate is P's own simulator.
>
> Would your decider be able to decide on this P correctly in finite time,
> in order to qualify itself as a decider?
>

Using direct execution as a proxy for simulation, YES.

int Simulate3(ptr2 x, ptr y, ptr z)
{ return x(y,z);
}

void P(ptr x)
{ int Halt_Status = Simulate3(H, x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

>>
>> int main()
>> {
>>    Output("Input_Halts = ", H(P, P));
>> }
>>
>> // This H(P,P) specifies the direct execution of P(P)
>> // which obviously never stops running
>> int H(ptr x, ptr y)
>> {
>>    x(y);
>> }
>>
>> Halting: is defined as reaching the last instruction (AKA final state)
>> and stopping.
>>
>> When an H is defined that correctly determines that the above direct
>> execution of P(P) would never reach its “return” instruction (AKA
>> final state) the conventional halting problem proofs are refuted.
>>
>> All halt deciders are intended to predict the behavior of their inputs
>> without actually executing these inputs because the halt decider
>> itself must always halt. The method used to determine that the above
>> P(P) never halts is a slight adaptation of a similar method that
>> correctly detects infinite recursion.
>>
>> When a correct non-halting behavior pattern is matched a simulating
>> halt decider (SHD) aborts its simulation and returns 0. Halting does
>> not mean stops running, halting only means reaching the last
>> instruction and stops running.
>>
>> Because we can see that the direct execution of P(P) from H would
>> never reach the last “return” instruction of P we know that no
>> complete or partial simulation of P by H would ever reach this last
>> instruction of P. From this we know that P is non-halting.
>>
>

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 9/21/2022 6:16 AM, Richard Damon wrote:
> On 9/20/22 11:57 PM, olcott wrote:
>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>> On 9/20/22 11:38 PM, olcott wrote:
>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>
>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>> This is an explanation of a possible new insight into
>>>>>>>>>>>>>>>> the halting problem provided in the language of software
>>>>>>>>>>>>>>>> engineering. Technical computer science terms are
>>>>>>>>>>>>>>>> explained using software engineering terms. No knowledge
>>>>>>>>>>>>>>>> of the halting problem is required.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When the conventional “pathological” input (that does
>>>>>>>>>>>>>>>> the opposite of whatever the halt decider decides) is
>>>>>>>>>>>>>>>> the first argument to a simulating halt decider then
>>>>>>>>>>>>>>>> this input becomes decidable as specifying infinitely
>>>>>>>>>>>>>>>> recursive simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION
>>>>>>>>>>>>>>> has finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Another way that we can say this is that P specifies
>>>>>>>>>>>>>> behavior that would never reach its own final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>>>>>
>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>> {
>>>>>>>>>>>>    x(y);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> I keep correcting you and you keep dishonestly forgetting
>>>>>>>>>>>> these corrections. *That is the main reason that it seems
>>>>>>>>>>>> you may be a liar*
>>>>>>>>>>>
>>>>>>>>>>> The liar is the one who uses H as a unique name to qualify
>>>>>>>>>>> different
>>>>>>>>>>> functions. Make up your mind about how H is supposed to be an
>>>>>>>>>>> halt
>>>>>>>>>>> decider and you'll see that you cannot avoid Richard's objection
>>>>>>>>>>> to your silliness. Which the main argument for such an H not to
>>>>>>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>>>>>>
>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>
>>>>>>>>>> Every correct halt decider H must predict the behavior of its
>>>>>>>>>> own direct execution of its input even though it does not
>>>>>>>>>> perform a direct execution of this input.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> And that statement is illogical because it asks what would
>>>>>>>>> happen if something does something that it doesn't do.
>>>>>>>>>
>>>>>>>>
>>>>>>>> A halt decider can correctly predict that an infinite loop never
>>>>>>>> halts without executing it. That you act like you keep
>>>>>>>> forgetting this is either dishonest or you actually keep
>>>>>>>> forgetting it, thus dementia.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Yes, but if the loop isn't infinite (or not even a loop), it is
>>>>>>> incorrect to predict that it is.
>>>>>>>
>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>>>>>
>>>>>> Of every input P to every H that either simulates or executes its
>>>>>> input no H ever returns anything to P.
>>>>>>
>>>>>> A halt decider must compute the mapping
>>>>>> FROM ITS INPUT
>>>>>> FROM ITS INPUT
>>>>>> FROM ITS INPUT
>>>>>> FROM ITS INPUT
>>>>>> FROM ITS INPUT
>>>>>> To an accept or reject state.
>>>>>
>>>>> Right, the input is the representation of P and its input P
>>>>>
>>>> It is the actual behavior of the actual executed or simulated input.
>>>>
>>>
>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>> independent computaitons.
>>>
>>> Those Halt.
>>
>> H is only allowed to report on the behavior that it sees.
>> H is NOT allowed to report on behavior that it does not see.
>>
>>
>
> Nope. That isn't the definition.

Sure it is. A halt decider must compute the mapping from its input to an
accept or reject state based on the actual behavior specified by the
direct execution of this input.

This is not the input thus not a direct execution of the input:
int main() { P(P); }

// This is the direct execution of the input.
int x(ptr x, ptr y)
{ x(y);
}

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

Op 21.sep..2022 om 17:30 schreef olcott:
> On 9/21/2022 3:14 AM, Fred. Zwarts wrote:
>> Op 20.sep..2022 om 17:43 schreef olcott:
>>> This is an explanation of a possible new insight into the halting
>>> problem provided in the language of software engineering. Technical
>>> computer science terms are explained using software engineering
>>> terms. No knowledge of the halting problem is required.
>>>
>>> When the conventional “pathological” input (that does the opposite of
>>> whatever the halt decider decides) is the first argument to a
>>> simulating halt decider then this input becomes decidable as
>>> specifying infinitely recursive simulation.
>>>
>>> This paper is based on fully operational software executed in the
>>> x86utm operating system. The x86utm operating system (based on an
>>> excellent open source x86 emulator) was created to study the details
>>> of the halting problem proof counter-examples at the much higher
>>> level of abstraction of C/x86.
>>>
>>> typedef void (*ptr)();
>>> int H(ptr p, ptr i); // simulating halt decider
>>>
>>> // P does the opposite of whatever H decides
>>> void P(ptr x)
>>> {
>>>    int Halt_Status = H(x, x);
>>>    if (Halt_Status)    // if H(P,P) reports that its input halts
>>>      HERE: goto HERE;  // P loops and never halts
>>>    return;             // else P halts
>>> }
>>
>> It must be said that this P is only an example of a program that does
>> the opposite of what H decides. There are main other ways to do that.
>> A decider should not only correctly decide on one such program, but it
>> should decide on all of them correctly. That is much more difficult to
>> prove. E.g., if P does not call H directly, but uses a simulator to
>> see what H does:
>>
>> void P(ptr x)
>> {
>>    int Halt_Status = simulate (H, x, x);
>>    if (Halt_Status)    // if H(P,P) reports that its input halts
>>      HERE: goto HERE;  // P loops and never halts
>>    return;             // else P halts
>> }
>>
>> where simulate is P's own simulator.
>>
>> Would your decider be able to decide on this P correctly in finite
>> time, in order to qualify itself as a decider?
>>
>
> Using direct execution as a proxy for simulation, YES.
>
> int Simulate3(ptr2 x, ptr y, ptr z)
> {
>   return x(y,z);
> }
>
> void P(ptr x)
> {
>   int Halt_Status = Simulate3(H, x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }

So, do I understand correctly that your decider only works for direct
execution of H? But not if H is simulated in P in another way, e.g.,
with an x86 code simulator, similar (but not equal) to the one you use
in H itself?

On 9/21/2022 11:14 AM, Fred. Zwarts wrote:
> Op 21.sep..2022 om 17:30 schreef olcott:
>> On 9/21/2022 3:14 AM, Fred. Zwarts wrote:
>>> Op 20.sep..2022 om 17:43 schreef olcott:
>>>> This is an explanation of a possible new insight into the halting
>>>> problem provided in the language of software engineering. Technical
>>>> computer science terms are explained using software engineering
>>>> terms. No knowledge of the halting problem is required.
>>>>
>>>> When the conventional “pathological” input (that does the opposite
>>>> of whatever the halt decider decides) is the first argument to a
>>>> simulating halt decider then this input becomes decidable as
>>>> specifying infinitely recursive simulation.
>>>>
>>>> This paper is based on fully operational software executed in the
>>>> x86utm operating system. The x86utm operating system (based on an
>>>> excellent open source x86 emulator) was created to study the details
>>>> of the halting problem proof counter-examples at the much higher
>>>> level of abstraction of C/x86.
>>>>
>>>> typedef void (*ptr)();
>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>
>>>> // P does the opposite of whatever H decides
>>>> void P(ptr x)
>>>> {
>>>>    int Halt_Status = H(x, x);
>>>>    if (Halt_Status)    // if H(P,P) reports that its input halts
>>>>      HERE: goto HERE;  // P loops and never halts
>>>>    return;             // else P halts
>>>> }
>>>
>>> It must be said that this P is only an example of a program that does
>>> the opposite of what H decides. There are main other ways to do that.
>>> A decider should not only correctly decide on one such program, but
>>> it should decide on all of them correctly. That is much more
>>> difficult to prove. E.g., if P does not call H directly, but uses a
>>> simulator to see what H does:
>>>
>>> void P(ptr x)
>>> {
>>>    int Halt_Status = simulate (H, x, x);
>>>    if (Halt_Status)    // if H(P,P) reports that its input halts
>>>      HERE: goto HERE;  // P loops and never halts
>>>    return;             // else P halts
>>> }
>>>
>>> where simulate is P's own simulator.
>>>
>>> Would your decider be able to decide on this P correctly in finite
>>> time, in order to qualify itself as a decider?
>>>
>>
>> Using direct execution as a proxy for simulation, YES.
>>
>> int Simulate3(ptr2 x, ptr y, ptr z)
>> {
>>    return x(y,z);
>> }
>>
>> void P(ptr x)
>> {
>>    int Halt_Status = Simulate3(H, x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return;
>> }
>
> So, do I understand correctly that your decider only works for direct
> execution of H? But not if H is simulated in P in another way, e.g.,

In the mean time I got it to work with H1(P,P), which simulates its
input. I spent 20,000 hours on this you are not going to be able to find
any mistake without a similar degree of effort.

> with an x86 code simulator, similar (but not equal) to the one you use
> in H itself?
>
>

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On Wed, 21 Sep 2022 11:46:59 -0500
olcott <polcott2@gmail.com> wrote:

> On 9/21/2022 11:14 AM, Fred. Zwarts wrote:
> > Op 21.sep..2022 om 17:30 schreef olcott:
> >> On 9/21/2022 3:14 AM, Fred. Zwarts wrote:
> >>> Op 20.sep..2022 om 17:43 schreef olcott:
> >>>> This is an explanation of a possible new insight into the
> >>>> halting problem provided in the language of software
> >>>> engineering. Technical computer science terms are explained
> >>>> using software engineering terms. No knowledge of the halting
> >>>> problem is required.
> >>>>
> >>>> When the conventional “pathological” input (that does the
> >>>> opposite of whatever the halt decider decides) is the first
> >>>> argument to a simulating halt decider then this input becomes
> >>>> decidable as specifying infinitely recursive simulation.
> >>>>
> >>>> This paper is based on fully operational software executed in
> >>>> the x86utm operating system. The x86utm operating system (based
> >>>> on an excellent open source x86 emulator) was created to study
> >>>> the details of the halting problem proof counter-examples at the
> >>>> much higher level of abstraction of C/x86.
> >>>>
> >>>> typedef void (*ptr)();
> >>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>
> >>>> // P does the opposite of whatever H decides
> >>>> void P(ptr x)
> >>>> {
> >>>>    int Halt_Status = H(x, x);
> >>>>    if (Halt_Status)    // if H(P,P) reports that its input halts
> >>>>      HERE: goto HERE;  // P loops and never halts
> >>>>    return;             // else P halts
> >>>> }
> >>>
> >>> It must be said that this P is only an example of a program that
> >>> does the opposite of what H decides. There are main other ways to
> >>> do that. A decider should not only correctly decide on one such
> >>> program, but it should decide on all of them correctly. That is
> >>> much more difficult to prove. E.g., if P does not call H
> >>> directly, but uses a simulator to see what H does:
> >>>
> >>> void P(ptr x)
> >>> {
> >>>    int Halt_Status = simulate (H, x, x);
> >>>    if (Halt_Status)    // if H(P,P) reports that its input halts
> >>>      HERE: goto HERE;  // P loops and never halts
> >>>    return;             // else P halts
> >>> }
> >>>
> >>> where simulate is P's own simulator.
> >>>
> >>> Would your decider be able to decide on this P correctly in
> >>> finite time, in order to qualify itself as a decider?
> >>>
> >>
> >> Using direct execution as a proxy for simulation, YES.
> >>
> >> int Simulate3(ptr2 x, ptr y, ptr z)
> >> {
> >>    return x(y,z);
> >> }
> >>
> >> void P(ptr x)
> >> {
> >>    int Halt_Status = Simulate3(H, x, x);
> >>    if (Halt_Status)
> >>      HERE: goto HERE;
> >>    return;
> >> }
> >
> > So, do I understand correctly that your decider only works for
> > direct execution of H? But not if H is simulated in P in another
> > way, e.g.,
>
> In the mean time I got it to work with H1(P,P), which simulates its
> input. I spent 20,000 hours on this you are not going to be able to
> find any mistake without a similar degree of effort.

We have found mistakes already and in considerably less time than the
20,000 hours of your life that you have wasted.

/Flibble

On 9/21/2022 12:15 PM, Mr Flibble wrote:
> On Wed, 21 Sep 2022 11:46:59 -0500
> olcott <polcott2@gmail.com> wrote:
>
>> On 9/21/2022 11:14 AM, Fred. Zwarts wrote:
>>> Op 21.sep..2022 om 17:30 schreef olcott:
>>>> On 9/21/2022 3:14 AM, Fred. Zwarts wrote:
>>>>> Op 20.sep..2022 om 17:43 schreef olcott:
>>>>>> This is an explanation of a possible new insight into the
>>>>>> halting problem provided in the language of software
>>>>>> engineering. Technical computer science terms are explained
>>>>>> using software engineering terms. No knowledge of the halting
>>>>>> problem is required.
>>>>>>
>>>>>> When the conventional “pathological” input (that does the
>>>>>> opposite of whatever the halt decider decides) is the first
>>>>>> argument to a simulating halt decider then this input becomes
>>>>>> decidable as specifying infinitely recursive simulation.
>>>>>>
>>>>>> This paper is based on fully operational software executed in
>>>>>> the x86utm operating system. The x86utm operating system (based
>>>>>> on an excellent open source x86 emulator) was created to study
>>>>>> the details of the halting problem proof counter-examples at the
>>>>>> much higher level of abstraction of C/x86.
>>>>>>
>>>>>> typedef void (*ptr)();
>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>
>>>>>> // P does the opposite of whatever H decides
>>>>>> void P(ptr x)
>>>>>> {
>>>>>>    int Halt_Status = H(x, x);
>>>>>>    if (Halt_Status)    // if H(P,P) reports that its input halts
>>>>>>      HERE: goto HERE;  // P loops and never halts
>>>>>>    return;             // else P halts
>>>>>> }
>>>>>
>>>>> It must be said that this P is only an example of a program that
>>>>> does the opposite of what H decides. There are main other ways to
>>>>> do that. A decider should not only correctly decide on one such
>>>>> program, but it should decide on all of them correctly. That is
>>>>> much more difficult to prove. E.g., if P does not call H
>>>>> directly, but uses a simulator to see what H does:
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>    int Halt_Status = simulate (H, x, x);
>>>>>    if (Halt_Status)    // if H(P,P) reports that its input halts
>>>>>      HERE: goto HERE;  // P loops and never halts
>>>>>    return;             // else P halts
>>>>> }
>>>>>
>>>>> where simulate is P's own simulator.
>>>>>
>>>>> Would your decider be able to decide on this P correctly in
>>>>> finite time, in order to qualify itself as a decider?
>>>>>
>>>>
>>>> Using direct execution as a proxy for simulation, YES.
>>>>
>>>> int Simulate3(ptr2 x, ptr y, ptr z)
>>>> {
>>>>    return x(y,z);
>>>> }
>>>>
>>>> void P(ptr x)
>>>> {
>>>>    int Halt_Status = Simulate3(H, x, x);
>>>>    if (Halt_Status)
>>>>      HERE: goto HERE;
>>>>    return;
>>>> }
>>>
>>> So, do I understand correctly that your decider only works for
>>> direct execution of H? But not if H is simulated in P in another
>>> way, e.g.,
>>
>> In the mean time I got it to work with H1(P,P), which simulates its
>> input. I spent 20,000 hours on this you are not going to be able to
>> find any mistake without a similar degree of effort.
>
> We have found mistakes already and in considerably less time than the
> 20,000 hours of your life that you have wasted.
>
> /Flibble
>

I should have said no one has correctly found any mistakes. Many people
thought they found mistakes, yet all of the "mistakes" were entirely
based on their own false assumptions.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 9/21/22 11:39 AM, olcott wrote:
> On 9/21/2022 6:16 AM, Richard Damon wrote:
>> On 9/20/22 11:57 PM, olcott wrote:
>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>> This is an explanation of a possible new insight into
>>>>>>>>>>>>>>>>> the halting problem provided in the language of
>>>>>>>>>>>>>>>>> software engineering. Technical computer science terms
>>>>>>>>>>>>>>>>> are explained using software engineering terms. No
>>>>>>>>>>>>>>>>> knowledge of the halting problem is required.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When the conventional “pathological” input (that does
>>>>>>>>>>>>>>>>> the opposite of whatever the halt decider decides) is
>>>>>>>>>>>>>>>>> the first argument to a simulating halt decider then
>>>>>>>>>>>>>>>>> this input becomes decidable as specifying infinitely
>>>>>>>>>>>>>>>>> recursive simulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE DEFINITION
>>>>>>>>>>>>>>>> has finite behavior so NO CALL to it can be "infinite"
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Another way that we can say this is that P specifies
>>>>>>>>>>>>>>> behavior that would never reach its own final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>>>>>>
>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>> {
>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> I keep correcting you and you keep dishonestly forgetting
>>>>>>>>>>>>> these corrections. *That is the main reason that it seems
>>>>>>>>>>>>> you may be a liar*
>>>>>>>>>>>>
>>>>>>>>>>>> The liar is the one who uses H as a unique name to qualify
>>>>>>>>>>>> different
>>>>>>>>>>>> functions. Make up your mind about how H is supposed to be
>>>>>>>>>>>> an halt
>>>>>>>>>>>> decider and you'll see that you cannot avoid Richard's
>>>>>>>>>>>> objection
>>>>>>>>>>>> to your silliness. Which the main argument for such an H not to
>>>>>>>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>>>>>>>
>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>
>>>>>>>>>>> Every correct halt decider H must predict the behavior of its
>>>>>>>>>>> own direct execution of its input even though it does not
>>>>>>>>>>> perform a direct execution of this input.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And that statement is illogical because it asks what would
>>>>>>>>>> happen if something does something that it doesn't do.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A halt decider can correctly predict that an infinite loop
>>>>>>>>> never halts without executing it. That you act like you keep
>>>>>>>>> forgetting this is either dishonest or you actually keep
>>>>>>>>> forgetting it, thus dementia.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, but if the loop isn't infinite (or not even a loop), it is
>>>>>>>> incorrect to predict that it is.
>>>>>>>>
>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>>>>>>
>>>>>>> Of every input P to every H that either simulates or executes its
>>>>>>> input no H ever returns anything to P.
>>>>>>>
>>>>>>> A halt decider must compute the mapping
>>>>>>> FROM ITS INPUT
>>>>>>> FROM ITS INPUT
>>>>>>> FROM ITS INPUT
>>>>>>> FROM ITS INPUT
>>>>>>> FROM ITS INPUT
>>>>>>> To an accept or reject state.
>>>>>>
>>>>>> Right, the input is the representation of P and its input P
>>>>>>
>>>>> It is the actual behavior of the actual executed or simulated input.
>>>>>
>>>>
>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>> independent computaitons.
>>>>
>>>> Those Halt.
>>>
>>> H is only allowed to report on the behavior that it sees.
>>> H is NOT allowed to report on behavior that it does not see.
>>>
>>>
>>
>> Nope. That isn't the definition.
>
> Sure it is. A halt decider must compute the mapping from its input to an
> accept or reject state based on the actual behavior specified by the
> direct execution of this input.

Right *THE* not *ITS* direct execution of its input.

That is the behavior of executing its input as a totally independent
machine.

>
> This is not the input thus not a direct execution of the input:
> int main() { P(P); }

No, That IS the direct execution of its input per your model.

You are just showing that you don't understand what you are talking about,

>
>
> // This is the direct execution of the input.
> int x(ptr x, ptr y)
> {
>   x(y);
> }
>
>

Nope, because that isn't the H defined.

Try putting that definition in the same file as your H that you claim
gets the right answer.

You just don't understand what you are talking about.

You don't seem to understand the diference between requirements and
abilities.

H may be only ABLE to answer about the simulation that it does.

The REQUIREMENTS is to answer about the independent execution of the
machine specified (or the independent simulation of its input by a
compatible UTM).

The fact that H is UNABLE to meet the requirements just says that the
requirements are not a computable function, and thus the answer to the
Halting Problem is that no such machine is possible.

On 9/21/2022 5:43 PM, Richard Damon wrote:
> On 9/21/22 11:39 AM, olcott wrote:
>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>> On 9/20/22 11:57 PM, olcott wrote:
>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>> This is an explanation of a possible new insight into
>>>>>>>>>>>>>>>>>> the halting problem provided in the language of
>>>>>>>>>>>>>>>>>> software engineering. Technical computer science terms
>>>>>>>>>>>>>>>>>> are explained using software engineering terms. No
>>>>>>>>>>>>>>>>>> knowledge of the halting problem is required.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When the conventional “pathological” input (that does
>>>>>>>>>>>>>>>>>> the opposite of whatever the halt decider decides) is
>>>>>>>>>>>>>>>>>> the first argument to a simulating halt decider then
>>>>>>>>>>>>>>>>>> this input becomes decidable as specifying infinitely
>>>>>>>>>>>>>>>>>> recursive simulation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to it can be
>>>>>>>>>>>>>>>>> "infinite"
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Another way that we can say this is that P specifies
>>>>>>>>>>>>>>>> behavior that would never reach its own final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly forgetting
>>>>>>>>>>>>>> these corrections. *That is the main reason that it seems
>>>>>>>>>>>>>> you may be a liar*
>>>>>>>>>>>>>
>>>>>>>>>>>>> The liar is the one who uses H as a unique name to qualify
>>>>>>>>>>>>> different
>>>>>>>>>>>>> functions. Make up your mind about how H is supposed to be
>>>>>>>>>>>>> an halt
>>>>>>>>>>>>> decider and you'll see that you cannot avoid Richard's
>>>>>>>>>>>>> objection
>>>>>>>>>>>>> to your silliness. Which the main argument for such an H
>>>>>>>>>>>>> not to
>>>>>>>>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>
>>>>>>>>>>>> Every correct halt decider H must predict the behavior of
>>>>>>>>>>>> its own direct execution of its input even though it does
>>>>>>>>>>>> not perform a direct execution of this input.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> And that statement is illogical because it asks what would
>>>>>>>>>>> happen if something does something that it doesn't do.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> A halt decider can correctly predict that an infinite loop
>>>>>>>>>> never halts without executing it. That you act like you keep
>>>>>>>>>> forgetting this is either dishonest or you actually keep
>>>>>>>>>> forgetting it, thus dementia.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, but if the loop isn't infinite (or not even a loop), it is
>>>>>>>>> incorrect to predict that it is.
>>>>>>>>>
>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>>>>>>>
>>>>>>>> Of every input P to every H that either simulates or executes
>>>>>>>> its input no H ever returns anything to P.
>>>>>>>>
>>>>>>>> A halt decider must compute the mapping
>>>>>>>> FROM ITS INPUT
>>>>>>>> FROM ITS INPUT
>>>>>>>> FROM ITS INPUT
>>>>>>>> FROM ITS INPUT
>>>>>>>> FROM ITS INPUT
>>>>>>>> To an accept or reject state.
>>>>>>>
>>>>>>> Right, the input is the representation of P and its input P
>>>>>>>
>>>>>> It is the actual behavior of the actual executed or simulated input.
>>>>>>
>>>>>
>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>>> independent computaitons.
>>>>>
>>>>> Those Halt.
>>>>
>>>> H is only allowed to report on the behavior that it sees.
>>>> H is NOT allowed to report on behavior that it does not see.
>>>>
>>>>
>>>
>>> Nope. That isn't the definition.
>>
>> Sure it is. A halt decider must compute the mapping from its input to
>> an accept or reject state based on the actual behavior specified by
>> the direct execution of this input.
>
> Right *THE* not *ITS* direct execution of its input.
>
> That is the behavior of executing its input as a totally independent
> machine.
>
>>
>> This is not the input thus not a direct execution of the input:
>> int main() { P(P); }
>
> No, That IS the direct execution of its input per your model.

Because this is not the actual input to H, and its behavior is not the
same as the behavior of this actual input to H then it violates the
principle that a halt decider must report on the actual behavior of its
actual input.