Halting problem proofs refuted on the basis of software engineering ?

5 views
Skip to first unread message

olcott

unread,
Sep 20, 2022, 11:43:31 AMSep 20
to
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

Mr Flibble

unread,
Sep 20, 2022, 1:54:58 PMSep 20
to
On Tue, 20 Sep 2022 10:43:26 -0500
olcott <polc...@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

olcott

unread,
Sep 20, 2022, 2:39:50 PMSep 20
to
On 9/20/2022 12:54 PM, Mr Flibble wrote:
> On Tue, 20 Sep 2022 10:43:26 -0500
> olcott <polc...@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
>

Mr Flibble

unread,
Sep 20, 2022, 2:59:46 PMSep 20
to
On Tue, 20 Sep 2022 13:39:47 -0500
olcott <polc...@gmail.com> wrote:

> On 9/20/2022 12:54 PM, Mr Flibble wrote:
> > On Tue, 20 Sep 2022 10:43:26 -0500
> > olcott <polc...@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


olcott

unread,
Sep 20, 2022, 3:45:24 PMSep 20
to
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.

Mr Flibble

unread,
Sep 20, 2022, 4:29:34 PMSep 20
to
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


Richard Damon

unread,
Sep 20, 2022, 6:50:15 PMSep 20
to

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.

olcott

unread,
Sep 20, 2022, 7:19:17 PMSep 20
to
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.

Richard Damon

unread,
Sep 20, 2022, 8:41:40 PMSep 20
to
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.

olcott

unread,
Sep 20, 2022, 8:53:42 PMSep 20
to
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*

Python

unread,
Sep 20, 2022, 9:09:24 PMSep 20
to
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.



olcott

unread,
Sep 20, 2022, 9:20:01 PMSep 20
to
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.

Richard Damon

unread,
Sep 20, 2022, 9:25:37 PMSep 20
to

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.

Richard Damon

unread,
Sep 20, 2022, 9:27:52 PMSep 20
to
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.

Python

unread,
Sep 20, 2022, 9:41:38 PMSep 20
to
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.



olcott

unread,
Sep 20, 2022, 10:40:35 PMSep 20
to
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.

olcott

unread,
Sep 20, 2022, 10:45:26 PMSep 20
to
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.

Richard Damon

unread,
Sep 20, 2022, 10:47:41 PMSep 20
to
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.

Richard Damon

unread,
Sep 20, 2022, 10:55:17 PMSep 20
to
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.

olcott

unread,
Sep 20, 2022, 10:57:22 PMSep 20
to
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.

olcott

unread,
Sep 20, 2022, 11:00:04 PMSep 20
to
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.

Python

unread,
Sep 20, 2022, 11:03:37 PMSep 20
to
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.


Richard Damon

unread,
Sep 20, 2022, 11:04:01 PMSep 20
to
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.

Python

unread,
Sep 20, 2022, 11:07:11 PMSep 20
to
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.




Richard Damon

unread,
Sep 20, 2022, 11:07:28 PMSep 20
to
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.

Python

unread,
Sep 20, 2022, 11:08:34 PMSep 20
to
If H report P as non-halting, then P is halting. FAIL.



olcott

unread,
Sep 20, 2022, 11:08:55 PMSep 20
to
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);
}


olcott

unread,
Sep 20, 2022, 11:11:22 PMSep 20
to
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/

olcott

unread,
Sep 20, 2022, 11:12:59 PMSep 20
to
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.

olcott

unread,
Sep 20, 2022, 11:15:10 PMSep 20
to
If H reports that P is non-halting then every instance of P has been
aborted and none of them do jack shit.

Richard Damon

unread,
Sep 20, 2022, 11:16:47 PMSep 20
to
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,

Richard Damon

unread,
Sep 20, 2022, 11:17:16 PMSep 20
to
Neither do you as you have shown.

FAIL.

Richard Damon

unread,
Sep 20, 2022, 11:44:37 PMSep 20
to
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.

Fred. Zwarts

unread,
Sep 21, 2022, 4:15:02 AMSep 21
to
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.
>

olcott

unread,
Sep 21, 2022, 11:30:13 AMSep 21
to
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.
>>
>

Fred. Zwarts

unread,
Sep 21, 2022, 12:14:12 PMSep 21
to
Op 21.sep..2022 om 17:30 schreef olcott:
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?


olcott

unread,
Sep 21, 2022, 12:47:03 PMSep 21
to
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?
>
>

Mr Flibble

unread,
Sep 21, 2022, 1:16:02 PMSep 21
to
We have found mistakes already and in considerably less time than the
20,000 hours of your life that you have wasted.

/Flibble

olcott

unread,
Sep 21, 2022, 1:22:39 PMSep 21
to
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.

olcott

unread,
Sep 22, 2022, 9:46:02 PMSep 22
to
On 9/22/2022 8:09 PM, Richard Damon wrote:
> On 9/22/22 7:33 PM, olcott wrote:
>> On 9/22/2022 5:43 PM, Richard Damon wrote:
>>> On 9/22/22 12:23 PM, olcott wrote:
>>>> On 9/21/2022 7:33 PM, Richard Damon wrote:
>>>>> On 9/21/22 8:13 PM, olcott wrote:
>>>>>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 9/21/22 7:48 PM, olcott wrote:
>>>>>>>> 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:
>>>>>>>>>>>>>> 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.
>>>>>>>
>>>>>>> No, it IS its actual input, as specified by its representation.
>>>>>> All that "representation" actually means is that the halt decider
>>>>>> examines a finite string encoding of a Turing Machine thus not the
>>>>>> Turing machine itself.
>>>>>>
>>>>>> It certainly does not mean that the halt decider must examine the
>>>>>> mental idea that you have about what the input does.
>>>>>>
>>>>>
>>>>> Except that it does.
>>>>>
>>>>> Remember the DEFINITION that you are quoting from Linz.
>>>>>
>>>>
>>>> The actual behavior of the actual input is not specified by the
>>>> behavior of non-inputs.
>>>
>>> Thus not by the simulation of the input with a different version of
>>> H, like your "Set of H" does.
>> Zero elements of Hx/Px pairs correctly simulated by Hx reach their
>> final state thus zero elements of the Hx/Px pairs halt.
>>
>>
>
> SO?
>

void Px(ptr x)
{
int Halt_Status = Hx(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

Zero Px elements of Hx/Px pairs correctly simulated by Hx reach their
final state thus zero Px elements of the Hx/Px pairs halt.

Thus the conventional "impossible" input is correctly determined to be
non-halting, thus not proof of HP undecidability.

olcott

unread,
Sep 22, 2022, 10:36:41 PMSep 22
to
On 9/22/2022 8:56 PM, Richard Damon wrote:
> So?

All of the HP proofs fail to prove undecidability.

Richard Damon

unread,
Sep 22, 2022, 10:43:58 PMSep 22
to
Why do you say that?

You still don't have an H that decides CORRECTLY on the P built on it.

So, you are just LYING agian.

You are just showing that you are an ignorant pathological lying idiot.

YOU HAVE WASTED the last 18 years of your life just burying your
reputation under your pile of lies and errors.

olcott

unread,
Sep 23, 2022, 11:23:52 AMSep 23
to
I showed all of the details required to correctly determine the halt
status of the "impossible" input. This "impossible" input is the basis
of all of these proofs.

Complete halt deciding system
https://liarparadox.org/2022_09_07.zip

Compiles under Microsoft Visual Studio Community 2017
https://visualstudio.microsoft.com/vs/older-downloads/

The provided infinite recursion detector and corresponding test code has
been slightly adapted so that this slightly adapted behavior pattern can
be applied to P. This H/P are one element of the infinite set of Hx/Px
pairs.

Richard Damon

unread,
Sep 23, 2022, 6:30:40 PMSep 23
to
Exce[t that it says the input is non-halting when it halts.

Thus, it give s the wrong answer.

>
> Complete halt deciding system
> https://liarparadox.org/2022_09_07.zip
>
> Compiles under Microsoft Visual Studio Community 2017
> https://visualstudio.microsoft.com/vs/older-downloads/
>
> The provided infinite recursion detector and corresponding test code has
> been slightly adapted so that this slightly adapted behavior pattern can
> be applied to P. This H/P are one element of the infinite set of Hx/Px
> pairs.
>
>
>

Edcept that P(P) does Halt if H(P,P) returns 0, so that H is wrong.

FAIL.

Sergi o

unread,
Oct 18, 2022, 4:29:33 PMOct 18
to
On 9/20/2022 10: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.
>