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
}

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 Tue, 20 Sep 2022 10:43:26 -0500
olcott <polcott2@gmail.com> 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.

The conventional "pathological" input isn't recursive in nature, the
Flibble Signaling Simulating Halt Decider (SHD) isn't recursive in
nature, the only thing which is recursive in nature is your broken
non-decider. A decider cannot be infinitely recursive as it needs to
return a result to its caller (i.e. the input in this case) in finite
time.

/Flibble

On 9/20/2022 12:54 PM, Mr Flibble wrote:
> On Tue, 20 Sep 2022 10:43:26 -0500
> olcott <polcott2@gmail.com> 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.
>
> The conventional "pathological" input isn't recursive in nature, the

Unless H is a simulating halt decider, then it is recursive in nature.

> Flibble Signaling Simulating Halt Decider (SHD) isn't recursive in
> nature, the only thing which is recursive in nature is your broken
> non-decider. A decider cannot be infinitely recursive as it needs to
> return a result to its caller (i.e. the input in this case) in finite
> time.
>
> /Flibble
>

--
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 Tue, 20 Sep 2022 13:39:47 -0500
olcott <polcott2@gmail.com> wrote:

> On 9/20/2022 12:54 PM, Mr Flibble wrote:
> > On Tue, 20 Sep 2022 10:43:26 -0500
> > olcott <polcott2@gmail.com> 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.
> >
> > The conventional "pathological" input isn't recursive in nature,
> > the
>
> Unless H is a simulating halt decider, then it is recursive in nature.

"The Flibble Signaling Simulating Halt Decider (SHD) isn't recursive in
nature".

/Flibble

On 9/20/2022 1:59 PM, Mr Flibble wrote:
> On Tue, 20 Sep 2022 13:39:47 -0500
> olcott <polcott2@gmail.com> wrote:
>
>> On 9/20/2022 12:54 PM, Mr Flibble wrote:
>>> On Tue, 20 Sep 2022 10:43:26 -0500
>>> olcott <polcott2@gmail.com> 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.
>>>
>>> The conventional "pathological" input isn't recursive in nature,
>>> the
>>
>> Unless H is a simulating halt decider, then it is recursive in nature.
>
> "The Flibble Signaling Simulating Halt Decider (SHD) isn't recursive in
> nature".
>
> /Flibble
>

The adapted H halt decider also does not do recursive simulation because
it correctly recognizes this otherwise recursive simulation before it
ever actually begins. None-the-less The conventional "impossible" input
to the halting problem does specify recursive simulation to every
simulating halt decider that it invokes.

--
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 Tue, 20 Sep 2022 14:45:15 -0500
olcott <none-ya@beez-waxes.com> wrote:

> On 9/20/2022 1:59 PM, Mr Flibble wrote:
> > On Tue, 20 Sep 2022 13:39:47 -0500
> > olcott <polcott2@gmail.com> wrote:
> >
> >> On 9/20/2022 12:54 PM, Mr Flibble wrote:
> >>> On Tue, 20 Sep 2022 10:43:26 -0500
> >>> olcott <polcott2@gmail.com> 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.
> >>>
> >>> The conventional "pathological" input isn't recursive in nature,
> >>> the
> >>
> >> Unless H is a simulating halt decider, then it is recursive in
> >> nature.
> >
> > "The Flibble Signaling Simulating Halt Decider (SHD) isn't
> > recursive in nature".
> >
> > /Flibble
> >
>
> The adapted H halt decider also does not do recursive simulation
> because it correctly recognizes this otherwise recursive simulation
> before it ever actually begins. None-the-less The conventional
> "impossible" input to the halting problem does specify recursive
> simulation to every simulating halt decider that it invokes.

Your decider does not return a decision to the input that invokes it so
it is effectively still infinitely recursive as far as the input is
concerned. The conventional "impossible" input does not specify
recursive simulation at all; it only specifies that it calls some
decider the details of which are not specified.

/Flibble

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"

All you are doing is admitting that your H doesn't meet the requirements
to be a Decider.

>
> 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
> }
>
> 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);
> }

So, is this your H, or is the other one your H?

If you P calls this one, but this isn't the H you claim to be deciding,
then you are just admitting that you are lying that P is the defined
"Impossible program".

(Burn baby burn).

>
> Halting: is defined as reaching the last instruction (AKA final state)
> and stopping.

Right, of the ACTUAL EXECUTION of the program.

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

Except either this P isn't the P specified by the proof, or H is not
determining the actual behavior of that P.

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

Since, BY DEFINITION, the impossible program P calls the H that is
claimed to be correctly deciding it, your "refution proo0f" is found to
be incorrect, and based on outright DECEIT.

If your P calls the H that just calls its input, then your "proof" fails
as the P isn't the one defined in the proof you are trying to refute,
and you are shown to be a liar.

If you P does call the H that is deciding on it, then H's answer is
shown to be incorrect as H is using unsound logic to decide its answer,
and if we look at the actual direct execution, or complete and correct
simulation, we find that this operation will halt after seeing P call
H(P,P), then H returning 0, and P halting. Thus, you are sohown to be
lying that H was correct about its input.

THus, the only that you have proven is that you are a Liar.

FAIL.

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.

--
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 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 if the H that it
is built on returns 0 for the call to H(P,P).

This is true for ANY H, that the "Impossible program" (you call P) when
built on THAT H, will be IMPOSSIBLE for that decider to return the right
answer to.

You are just proving you don't understand what that even means, and that
you practice deception (badly) to try and make a (bad) argument that
your H is rignt.

You are just proving you are an ignorant pathologically lying idiot.

FAIL.

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*

--
Copyright 2022 Pete Olcott

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

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.

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.

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

Also, your H(P,P) that returns 0, is supposed to be answering not about
the P that calls the above H, but the H that is returning 0.

Thus, when we built the P from the H that you claim is "correctly"
returning 0, then we have the case that when we ask that H if this P
would Halt if it is run as P(P), and it answers that it doesn't halt
because when I just partially simulate it (instead of looking at what
happens if it is run) I stop it before it gets to the final state, and I
must be correct because this OTHER function that I will deceptively also
call P that calls this other function I will deceptively call H t at
behaves differently than me, when run won't halt.

It answer the wrong question and justifies that answer by looking at the
worng machine.

In other words, it is just WRONG.

And YOU are a LIAR for claiming it is right.

You have WASTED the LAST 18 years of your life and have BURIED your
reputation with your lies and deceit. You have PROVED that you are
ignorant of the topic and too stupid to understand when people point out
your errors.

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.

Since it doesn't happen, it can't be predicted.

You H is just answering about an input it isn't given.

FAIL.

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.

Word salad and delusions on your side cannot change that, die with it.

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.

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

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

The input is what the input was defined to be, and the DEFINITION of P
includes what "version" of H it is calling.

If you encoding doesn't preserve that, then you your "decider" just
fails to meet the very basic detail of what it needs to do.

I guess you are just proving that you are even more ignorant of the
basic facts then it first seems, and are totally unaware of how programs
are defined.

Sorry that you are so dumb, but you are just showing how STUPID your
logic is.

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.

THus the RIGHT answer has to be 1, but you don't seem to understand that.

Remember, when we actually run P(P), we NEVER get any nested
simulations, as H aborts it simulation as soon as it sees its simulated
P call H(P,P).

Unless you think that 1 is infinity, you have a problem here.

The H that P calls is DEFINED to do that, so that is what it does, and
thus there is NO "infinite loop" that H must abort. IT aborts the loop
not because it needs to in order to avoid an infinite loop, but because
it makes a mistake and does so.

You can't change that behavior impropertly changing the input.

This is because you have INCORRECTLY set up your decider to not be
independent of its input.

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 may not understand these things well enough to know what a mistake
would look like.

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

--
Copyright 2022 Pete Olcott

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

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.

So such a decider program does not exist.

You are bragging about the property of a program that can be proven
to be impossible. Word salad about simulation won't help.

On 9/20/22 10:57 PM, 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 may not understand these things well enough to know what a mistake
> would look like.
>

No, there have been MANY correct rebutals to your statements, and you
have shown yourself to be to ignorant and stupid to understand them.

It seems you wouldn't know what the truth was, or a correct proof, if it
walked up to you and bit you.

Note, NO ONE has agreed with your statements and kept to that agreement,
showing that it isn't that a few people don't understand your logic, but
that your logic isn't understandable because it just isn't true.

Great minds may come up with ideas that are hard to understand, but they
are able to show at least some people they are true.

IDIOTS come up with ideas they think are great, but only in their own
minds, and everyone else sees they are wrong.

THAT IS WHERE YOU ARE, EVERYONE sees you are wring, and you are just
being too stupid to understand it.

FAIL.

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

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.

ANY H you define that give the non-halting answer can be shown to fail
in exactly this same way.

You are just too stupid to see this because you can't keep your machine
straight because you have lied to yourself too much and have addled your
brain.

Sorry, you are just showing that you are too dumb to understand what you
are saying.

Your last 18 years just down the drain, buried under a pile of lies and
deceit.