5 views

Skip to first unread message

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

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

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

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

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

>

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

nature".

/Flibble

Sep 20, 2022, 3:45:24 PMSep 20

to

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.

Sep 20, 2022, 4:29:34 PMSep 20

to

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

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.

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

> }

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.

>

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

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.

>

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.

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
>

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

>

never reach its own final state.

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

>

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.

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

int H(ptr x, ptr y)

{

x(y);

}

I keep correcting you and you keep dishonestly forgetting these
{

x(y);

}

corrections. *That is the main reason that it seems you may be a liar*

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

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.

Sep 20, 2022, 9:20:01 PMSep 20

to

execution of its input even though it does not perform a direct

execution of this input.

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*

>

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.

Sep 20, 2022, 9:27:52 PMSep 20

to

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.

Sep 20, 2022, 9:41:38 PMSep 20

to

inputs : P. Such an H does not exist. PERIOD.

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

Sep 20, 2022, 10:40:35 PMSep 20

to

of the above H. The question is what happens when the input is executed?

Thus the above H is the measure of that.

Sep 20, 2022, 10:45:26 PMSep 20

to

without executing it. That you act like you keep forgetting this is

either dishonest or you actually keep forgetting it, thus dementia.

Sep 20, 2022, 10:47:41 PMSep 20

to

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.

Sep 20, 2022, 10:55:17 PMSep 20

to

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.

Sep 20, 2022, 10:57:22 PMSep 20

to

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.

Sep 20, 2022, 11:00:04 PMSep 20

to

possibly reach its final state we know that it is non-halting.

Sep 20, 2022, 11:03:37 PMSep 20

to

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.

Sep 20, 2022, 11:04:01 PMSep 20

to

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.

Sep 20, 2022, 11:07:11 PMSep 20

to

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.

Sep 20, 2022, 11:07:28 PMSep 20

to

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.

Sep 20, 2022, 11:08:34 PMSep 20

to

Sep 20, 2022, 11:08:55 PMSep 20

to

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

}

{

x(y);

}

Sep 20, 2022, 11:11:22 PMSep 20

to

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

Sep 20, 2022, 11:12:59 PMSep 20

to

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

>

Sep 20, 2022, 11:15:10 PMSep 20

to

aborted and none of them do jack shit.

Sep 20, 2022, 11:16:47 PMSep 20

to

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*

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

> }

>

>

FAIL.

Hoisted on your own petard.

You are just PROVING how stupid you are.

FAIL,

Sep 20, 2022, 11:17:16 PMSep 20

to

FAIL.

Sep 20, 2022, 11:44:37 PMSep 20

to

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.

Sep 21, 2022, 4:15:02 AMSep 21

to

Op 20.sep..2022 om 17:43 schreef olcott:

> 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

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

>

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

>

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

> x(y);

> }

>

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

>

Sep 21, 2022, 11:30:13 AMSep 21

to

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.

>>

>

>>

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

>>

>

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?

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?

Sep 21, 2022, 12:47:03 PMSep 21

to

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?

>

>

Sep 21, 2022, 1:16:02 PMSep 21

to

20,000 hours of your life that you have wasted.

/Flibble

Sep 21, 2022, 1:22:39 PMSep 21

to

thought they found mistakes, yet all of the "mistakes" were entirely

based on their own false assumptions.

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

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.

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

>>>>>>>>>>>>>> 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
HERE: goto HERE;

return;

}

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.

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.

All of the HP proofs fail to prove undecidability.

Sep 22, 2022, 10:43:58 PMSep 22

to

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.

Sep 23, 2022, 11:23:52 AMSep 23

to

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.

Sep 23, 2022, 6:30:40 PMSep 23

to

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.

>

>

>

FAIL.

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.

>

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

>