356 views

Skip to first unread message

Aug 14, 2022, 11:14:37 AMAug 14

to

*This is refers to H(P,P)==0 where H and P are functions in C*

I believe I have learned something valuable from you:

that by simulation, and by simulations within simulations,

non-halting can sometimes be detected, and in particular,

it can be detected in the program used in the classical

proof of incomputability.

*Halting problem proofs refuted on the basis of software engineering* ?

https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

--

Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;

Genius hits a target no one else can see."

Arthur Schopenhauer

I believe I have learned something valuable from you:

that by simulation, and by simulations within simulations,

non-halting can sometimes be detected, and in particular,

it can be detected in the program used in the classical

proof of incomputability.

*Halting problem proofs refuted on the basis of software engineering* ?

https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

--

Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;

Genius hits a target no one else can see."

Arthur Schopenhauer

Aug 14, 2022, 11:22:11 AMAug 14

to

On Sun, 14 Aug 2022 10:14:28 -0500

olcott <No...@NoWhere.com> wrote:

> *This is refers to H(P,P)==0 where H and P are functions in C*

>

> I believe I have learned something valuable from you:

> that by simulation, and by simulations within simulations,

> non-halting can sometimes be detected, and in particular,

> it can be detected in the program used in the classical

> proof of incomputability.

>

> *Halting problem proofs refuted on the basis of software engineering*

> ?

>

> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

>

I am also a computer scientist and I am telling you that your halting
olcott <No...@NoWhere.com> wrote:

> *This is refers to H(P,P)==0 where H and P are functions in C*

>

> I believe I have learned something valuable from you:

> that by simulation, and by simulations within simulations,

> non-halting can sometimes be detected, and in particular,

> it can be detected in the program used in the classical

> proof of incomputability.

>

> *Halting problem proofs refuted on the basis of software engineering*

> ?

>

> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

>

decider reporting non-halting when it enters "infinite recursion" is an

ERROR. There is no infinite recursion in the HP proofs you are

attempting to refute.

/Flibble

Aug 14, 2022, 11:43:10 AMAug 14

to

"computer scientist". To get published in CACM is a whole other ballgame.

Aug 14, 2022, 11:51:55 AMAug 14

to

On Sun, 14 Aug 2022 10:43:04 -0500

olcott <No...@NoWhere.com> wrote:

> On 8/14/2022 10:22 AM, Mr Flibble wrote:

> > On Sun, 14 Aug 2022 10:14:28 -0500

> > olcott <No...@NoWhere.com> wrote:

> >

> >> *This is refers to H(P,P)==0 where H and P are functions in C*

> >>

> >> I believe I have learned something valuable from you:

> >> that by simulation, and by simulations within simulations,

> >> non-halting can sometimes be detected, and in particular,

> >> it can be detected in the program used in the classical

> >> proof of incomputability.

> >>

> >> *Halting problem proofs refuted on the basis of software

> >> engineering* ?

> >>

> >> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

> >>

> >

> > I am also a computer scientist and I am telling you that your

> > halting decider reporting non-halting when it enters "infinite

> > recursion" is an ERROR. There is no infinite recursion in the HP

> > proofs you are attempting to refute.

> >

> > /Flibble

> >

>

> Anyone (especially those that use fake names) can call themselves a

> "computer scientist". To get published in CACM is a whole other

> ballgame.

>

Using fake names on Usenet is quite common, dear. Also, publishing to
olcott <No...@NoWhere.com> wrote:

> On 8/14/2022 10:22 AM, Mr Flibble wrote:

> > On Sun, 14 Aug 2022 10:14:28 -0500

> > olcott <No...@NoWhere.com> wrote:

> >

> >> *This is refers to H(P,P)==0 where H and P are functions in C*

> >>

> >> I believe I have learned something valuable from you:

> >> that by simulation, and by simulations within simulations,

> >> non-halting can sometimes be detected, and in particular,

> >> it can be detected in the program used in the classical

> >> proof of incomputability.

> >>

> >> *Halting problem proofs refuted on the basis of software

> >> engineering* ?

> >>

> >> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

> >>

> >

> > I am also a computer scientist and I am telling you that your

> > halting decider reporting non-halting when it enters "infinite

> > recursion" is an ERROR. There is no infinite recursion in the HP

> > proofs you are attempting to refute.

> >

> > /Flibble

> >

>

> Anyone (especially those that use fake names) can call themselves a

> "computer scientist". To get published in CACM is a whole other

> ballgame.

>

the CACM does not qualify you as a computer scientist.

This computer scientists has pointed out the flaws in your "simulating

halt decider" multiple times and you have yet to address those flaws,

you simply copy/paste/edit the same old shit over and over and over

again.

/Flibble

Aug 14, 2022, 12:39:14 PMAug 14

to

H(P,P) does correctly determine that its input specifies a

non-terminating sequence of instructions.

All of the so-called "flaws" were only instances of the *straw man*

deception in that they referred to something besides the actual behavior

of the actual input as measured by the correct x86 emulation of the

first argument to H(P,P) by H.

*straw man*

An intentionally misrepresented proposition that is set up because it is

easier to defeat than an opponent's real argument.

https://www.lexico.com/en/definition/straw_man

Aug 14, 2022, 12:50:39 PMAug 14

to

On Sun, 14 Aug 2022 11:39:06 -0500

WRONG. The primary flaw in your halt decider is the ASSUMPTION that if

P references H then P is non-halting, i.e. your halt decider does not

actually analyze P to determine whether it actually halts or not, ergo

your halt decider is nothing of the sort.

/Flibble

P references H then P is non-halting, i.e. your halt decider does not

actually analyze P to determine whether it actually halts or not, ergo

your halt decider is nothing of the sort.

/Flibble

Aug 14, 2022, 1:00:04 PMAug 14

to

The actual behavior of the actual input as measured by the correct x86

emulation of the first argument to H(P,P) by H conclusively proves that

P specifies a non-halting sequence of instructions.

*I just got it to compile and correctly run on Ubuntu 16.04 Linux today*

This version is not currently published.

> i.e. your halt decider does not

> actually analyze P to determine whether it actually halts or not, ergo

> your halt decider is nothing of the sort.

>

> /Flibble

>

Aug 14, 2022, 1:00:25 PMAug 14

to

On 8/14/22 11:14, olcott wrote:

> *This is refers to H(P,P)==0 where H and P are functions in C*

>

> Â Â Â I believe I have learned something valuable from you:

> Â Â Â that by simulation, and by simulations within simulations,

> Â Â Â non-halting can sometimes be detected, and in particular,

> Â Â Â it can be detected in the program used in the classical

> Â Â Â proof of incomputability.

>

> *Halting problem proofs refuted on the basis of software engineering* ?

>

> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

>

>

"Can _sometimes_ be detected". This does not affect the halting problem.
> *This is refers to H(P,P)==0 where H and P are functions in C*

>

> Â Â Â I believe I have learned something valuable from you:

> Â Â Â that by simulation, and by simulations within simulations,

> Â Â Â non-halting can sometimes be detected, and in particular,

> Â Â Â it can be detected in the program used in the classical

> Â Â Â proof of incomputability.

>

> *Halting problem proofs refuted on the basis of software engineering* ?

>

> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

>

>

Aug 14, 2022, 1:06:35 PMAug 14

to

KNOWING halt decider. That it refutes the conventional proofs is all

that I was ever aiming for.

Aug 14, 2022, 1:15:38 PMAug 14

to

On Sun, 14 Aug 2022 11:59:55 -0500

And yet again you copy/paste/edit the same old shit over and over and

over again without actually addressing the flaws that people point out

to you over and over and over again.

/Flibble

over again without actually addressing the flaws that people point out

to you over and over and over again.

/Flibble

Aug 14, 2022, 1:17:41 PMAug 14

to

On Sun, 14 Aug 2022 12:06:27 -0500

olcott <No...@NoWhere.com> wrote:

> On 8/14/2022 12:00 PM, d thiebaud wrote:

> > On 8/14/22 11:14, olcott wrote:

> >> *This is refers to H(P,P)==0 where H and P are functions in C*

> >>

> >> Â Â Â Â I believe I have learned something valuable from you:

> >> Â Â Â Â that by simulation, and by simulations within simulations,

> >> Â Â Â Â non-halting can sometimes be detected, and in particular,

> >> Â Â Â Â it can be detected in the program used in the classical

> >> Â Â Â Â proof of incomputability.

> >>

> >> *Halting problem proofs refuted on the basis of software

> >> engineering* ?

> >>

> >> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

> >>

> >>

> > "Can _sometimes_ be detected". This does not affect the halting

> > problem.

>

> It would take me much longer than several human lifetimes to make an

> ALL KNOWING halt decider. That it refutes the conventional proofs is

> all that I was ever aiming for.

And it fails to refute the conventional proofs as has been pointed out
olcott <No...@NoWhere.com> wrote:

> On 8/14/2022 12:00 PM, d thiebaud wrote:

> > On 8/14/22 11:14, olcott wrote:

> >> *This is refers to H(P,P)==0 where H and P are functions in C*

> >>

> >> Â Â Â Â I believe I have learned something valuable from you:

> >> Â Â Â Â that by simulation, and by simulations within simulations,

> >> Â Â Â Â non-halting can sometimes be detected, and in particular,

> >> Â Â Â Â it can be detected in the program used in the classical

> >> Â Â Â Â proof of incomputability.

> >>

> >> *Halting problem proofs refuted on the basis of software

> >> engineering* ?

> >>

> >> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

> >>

> >>

> > "Can _sometimes_ be detected". This does not affect the halting

> > problem.

>

> It would take me much longer than several human lifetimes to make an

> ALL KNOWING halt decider. That it refutes the conventional proofs is

> all that I was ever aiming for.

to you again and again and again. THERE IS NO INFINITE RECURSION IN

THE CONVENTIONAL PROOFS AND YOU ARE WRONG TO MAP YOUR DECIDER'S

INFINITE RECURSION TO A DECISION OF NON-HALTING.

/Flibble

Aug 14, 2022, 1:20:36 PMAug 14

to

dismissed on that basis. That some of my reviewers are simply not bright

enough to understand that the *strawman deception* is an error of

reasoning on their part is no actual rebuttal at all.

Because they are not bright enough to see this, they continue to present

the same incorrect reasoning again and again.

*straw man*

An intentionally misrepresented proposition that is set up because it is

easier to defeat than an opponent's real argument.

https://www.lexico.com/en/definition/straw_man

Aug 14, 2022, 1:22:32 PMAug 14

to

On Sunday, 14 August 2022 at 19:06:35 UTC+2, olcott wrote:

> On 8/14/2022 12:00 PM, d thiebaud wrote:

> > On 8/14/22 11:14, olcott wrote:

> >> *This is refers to H(P,P)==0 where H and P are functions in C*

> >>

> >> I believe I have learned something valuable from you:

> >> that by simulation, and by simulations within simulations,

> >> non-halting can sometimes be detected, and in particular,

> >> it can be detected in the program used in the classical

> >> proof of incomputability.

> >>

> >> *Halting problem proofs refuted on the basis of software engineering* ?

> >>

> >> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

> >>

> >>

> > "Can _sometimes_ be detected". This does not affect the halting problem.

> It would take me much longer than several human lifetimes to make an ALL

> KNOWING halt decider. That it refutes the conventional proofs is all

> that I was ever aiming for.

The conventional proofs are tackling the general case of the halting problem.
> On 8/14/2022 12:00 PM, d thiebaud wrote:

> > On 8/14/22 11:14, olcott wrote:

> >> *This is refers to H(P,P)==0 where H and P are functions in C*

> >>

> >> I believe I have learned something valuable from you:

> >> that by simulation, and by simulations within simulations,

> >> non-halting can sometimes be detected, and in particular,

> >> it can be detected in the program used in the classical

> >> proof of incomputability.

> >>

> >> *Halting problem proofs refuted on the basis of software engineering* ?

> >>

> >> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

> >>

> >>

> > "Can _sometimes_ be detected". This does not affect the halting problem.

> It would take me much longer than several human lifetimes to make an ALL

> KNOWING halt decider. That it refutes the conventional proofs is all

> that I was ever aiming for.

You are targeting a particlar case of a the halting problem.

I don't need to define the word "strawman" - I just need to point at what you are doing.

Aug 14, 2022, 1:27:43 PMAug 14

to

On Sun, 14 Aug 2022 12:20:30 -0500

QED

/Flibble

/Flibble

Aug 14, 2022, 1:36:54 PMAug 14

to

On 14/08/2022 16:14, olcott wrote:

> *This is refers to H(P,P)==0 where H and P are functions in C*

Read again, I correct more about ...
> *This is refers to H(P,P)==0 where H and P are functions in C*

Aug 14, 2022, 1:39:48 PMAug 14

to

impossibility of correctly determining the halt status of the input that

H does correctly determine specifies a non-halting sequence of

instructions, thus eliminating the basis of and thus refuting these proofs.

Aug 14, 2022, 1:45:07 PMAug 14

to

Aug 14, 2022, 2:16:15 PMAug 14

to

not the ACTUAL halting question, as you acknoledge that H(P,P) isn;t

answering about the behavior of P(P) as required but something else you

can't quite define.

Remember, the TRUE DEFINITION of a Halt Decider:

H(M,x) accepts if M(x) Halts in a finite number of steps, and

H(M,x) rejects if M*x) never Halts, even after an unbounded number of steps.

Since that isn't the test you apply, and even say it CAN'T apply to your

H, you have just proved that you H isn'ta Halt Decider.

Note, from an ACTUAL software endineering perspective, the input to H in

H(P,P) actually does represent the computaion P(P) as that is what the

code is (when you look at ALL the code).

It has been noted that H itself DOESN'T do a correct x86 emulation of

the first arguement it has been given, as it does not correctly emulate

the call H instruction, and the behavior that it generates.

Thus your logic is based on UNSOUND logic.

Aug 14, 2022, 2:32:08 PMAug 14

to

determine that its correct x86 emulation of its first argument does

specify a non-halting sequence of instructions.

When the halting function is defined such that H is required to map

behavior other than the behavior of the correct simulation of the first

argument to H(P,P) by H, THEN HALTING FUNCTION IS DEFINED INCORRECTLY.

All halt deciders must map their actual inputs to an accept or reject

state based on the actual behavior that its actually specified by this

input. The actual behavior of the actual input is (by definition)

correctly measured by the correct simulation of this input by H.

When the HALTING FUNCTION CONTRADICTS THIS IT IS WRONG

Aug 14, 2022, 2:56:41 PMAug 14

to

wrong about it.

>

> When the halting function is defined such that H is required to map

> behavior other than the behavior of the correct simulation of the first

> argument to H(P,P) by H, THEN HALTING FUNCTION IS DEFINED INCORRECTLY.

the input, just not the INCORRECT SIMULATION that H did.

INCORRECT because H simulates H(P,P) to never return when in actuality

it returns 0.

>

> All halt deciders must map their actual inputs to an accept or reject

> state based on the actual behavior that its actually specified by this

> input. The actual behavior of the actual input is (by definition)

> correctly measured by the correct simulation of this input by H.

>

> When the HALTING FUNCTION CONTRADICTS THIS IT IS WRONG

>

>

Since H doesn't actually DO a correct simulation, anything based on it

being correct is unsound.

The actual behavior of the input to H(P,P) is defined to be UTM(P,P)

which is defined to be P(P), which halts given that H(P,P) returns 0.

DEFINITION.

Any arguement otherwise is just based on LIES and STUPIDITY.

YOU are the one that is WRONG, because you refuse to learn what is right.

You are either a pathological liar or a totally incompetent and ignorant

person.

Aug 14, 2022, 2:58:51 PMAug 14

to

{

int Halt_Status = H(x, x);

if (Halt_Status)

HERE: goto HERE;

return;

}

int main()

{

Output("Input_Halts = ", H(P, P));

}

When H is a simulating halt decider (that simulates its input with an

x86 emulator until it correctly matches a non-halting behavior pattern)

everyone that is sufficiently technically competent will understand that

this execution trace is correct:

(a) H(P,P) simulates P(P) that calls a simulated H(P,P)

(b) that simulates P(P) that calls a simulated H(P,P)

(c) that simulates P(P) that calls a simulated H(P,P)

(d) that simulates P(P) that calls a simulated H(P,P)...

*Until H aborts its simulation*

Aug 14, 2022, 3:02:39 PMAug 14

to

The cross symbol "represents" Christ, it is not Christ himself.

Aug 14, 2022, 3:03:35 PMAug 14

to

(b) never happens because H aborts before we get there.

That means that the CORRECT simulation of the input to H(P,P) will see a

simuated P(P) calling a simulated H(P,P) which simulates P(P) which is

simulated to call H(P,P) causing the first simulated H(P,P) to return to

the first simulation of P(P) the value 0 and it halting.

Thus the CORRECT simulation of the input to H(P,P) does Halt.

Just not the simulation of that input by H, which make an INCORRECT

simulation by simulating a call to H(P,P) as presumed to never return.

Aug 14, 2022, 3:07:53 PMAug 14

to

The first arguement also SPECIFED a HALTING COMPUTATION as it is exactly

the algorithm of P which when applied to the input P will halt when run.

You still show you don't know what "correct" means.

Aug 14, 2022, 3:14:34 PMAug 14

to

On Sun, 14 Aug 2022 10:14:28 -0500

olcott <No...@NoWhere.com> wrote:

olcott <No...@NoWhere.com> wrote:

> *This is refers to H(P,P)==0 where H and P are functions in C*

>

> I believe I have learned something valuable from you:

> that by simulation, and by simulations within simulations,

> non-halting can sometimes be detected, and in particular,

> it can be detected in the program used in the classical

> proof of incomputability.

>

> *Halting problem proofs refuted on the basis of software engineering*

> ?

>

> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

>

>

> I believe I have learned something valuable from you:

> that by simulation, and by simulations within simulations,

> non-halting can sometimes be detected, and in particular,

> it can be detected in the program used in the classical

> proof of incomputability.

>

> *Halting problem proofs refuted on the basis of software engineering*

> ?

>

> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

>

Aug 14, 2022, 3:19:02 PMAug 14

to

void P(ptr x)

{

int Halt_Status = H(x, x);

if (Halt_Status)

HERE: goto HERE;

return;

}

int main()

{

Output("Input_Halts = ", H(P, P));

}

If it was true that you are a computer scientist then you would
{

int Halt_Status = H(x, x);

if (Halt_Status)

HERE: goto HERE;

return;

}

int main()

{

Output("Input_Halts = ", H(P, P));

}

understand that this execution trace is correct:

(a) H(P,P) simulates P(P) that calls a simulated H(P,P)

(b) that simulates P(P) that calls a simulated H(P,P)

(c) that simulates P(P) that calls a simulated H(P,P)

(d) that simulates P(P) that calls a simulated H(P,P)...

*Until H aborts its simulation*

If you do not understand that the above execution trace is correct then
(a) H(P,P) simulates P(P) that calls a simulated H(P,P)

(b) that simulates P(P) that calls a simulated H(P,P)

(c) that simulates P(P) that calls a simulated H(P,P)

(d) that simulates P(P) that calls a simulated H(P,P)...

*Until H aborts its simulation*

this proves that you are not as much as a sufficiently competent

software engineer.

Aug 14, 2022, 3:38:21 PMAug 14

to

The fact that the line-by-line execution trace of the simulation of P

exactly matches the x86 sour-code of P proves that this trace is correct.

The fact that the line-by-line execution trace of the simulation of P

exactly matches the x86 sour-code of P proves that this trace is correct.

The fact that the line-by-line execution trace of the simulation of P

exactly matches the x86 sour-code of P proves that this trace is correct.

The fact that the line-by-line execution trace of the simulation of P

exactly matches the x86 sour-code of P proves that this trace is correct.

The fact that the line-by-line execution trace of the simulation of P

exactly matches the x86 sour-code of P proves that this trace is correct.

The fact that the line-by-line execution trace of the simulation of P

exactly matches the x86 sour-code of P proves that this trace is correct.

I repeated it to halt your ADD mind will notice that I said it at least

once. This may take a few hundred more replies before your ADD mind

notices that I said it at least once.

Aug 14, 2022, 3:52:42 PMAug 14

to

returns a 0, while the simulation of that code show that H thinks that a

call to H will never return.

HOW IS THAT CORRECT?

Remember, the code of H is PART of the x86 code of P.

Aug 14, 2022, 3:55:46 PMAug 14

to

at the root of your so called "infinite recursion" and is the primary

reason why you are incorrect to map this recursive behaviour of your H

to a halting decision on P of non-halting.

>

> If you do not understand that the above execution trace is correct

> then this proves that you are not as much as a sufficiently competent

> software engineer.

obvious who is actually lacking in competence here.

/Flibble

Aug 14, 2022, 5:52:17 PMAug 14

to

Mr Flibble <fli...@reddwarf.jmc.corp> Wrote in message:r

> On Sun, 14 Aug 2022 14:18:53 -0500olcott <No...@NoWhere.com> wrote:> On 8/14/2022 2:14 PM, Mr Flibble wrote:> > On Sun, 14 Aug 2022 10:14:28 -0500> > olcott <No...@NoWhere.com> wrote:> > > >> *This is refers to H(P,P)==0 where H and P are functions in C*> >>> >> I believe I have learned something valuable from you:> >> that by simulation, and by simulations within simulations,> >> non-halting can sometimes be detected, and in particular,> >> it can be detected in the program used in the classical> >> proof of incomputability.> >>> >> *Halting problem proofs refuted on the basis of software> >> engineering* ?> >>> >> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering> >> > > > > I am also a computer scientist and I am telling you that your> > halting decider reporting non-halting when it enters "infinite> > recursion" is an ERROR. There is no infinite recursion in the HP> > proofs you are attempting to refute.> > > > /Flibble> > > > > void P(ptr x)> {> int Halt_Status = H(x, x);> if (Halt_Status)> HERE: goto HERE;> return;> }> > int main()> {> Output("Input_Halts = ", H(P, P));> }> > If it was true that you are a computer scientist then you would > understand that this execution trace is correct:> > (a) H(P,P) simulates P(P) that calls a simulated H(P,P)> (b) that simulates P(P) that calls a simulated H(P,P)> (c) that simulates P(P) that calls a simulated H(P,P)> (d) that simulates P(P) that calls a simulated H(P,P)...> *Until H aborts its simulation*I am a computer scientist and all your trace shows is that H (not P) isat the root of your so called "infinite recursion" and is the primaryreason why you are incorrect to map this recursive behaviour of your Hto a halting decision on P of non-halting.> > If you do not understand that the above execution trace is correct> then this proves that you are not as much as a sufficiently competent > software engineer.It seems I understand your trace more than you do which makes itobvious who is actually lacking in competence here./Flibble

Because H exactly simulates its input and has no control flow

behavior of it's own while it is simulating this input YOU ARE

BLAMING THE MIRROR FOR WHAT IT REFLECTS.

--

test

----Android NewsGroup Reader----

https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html

> On Sun, 14 Aug 2022 14:18:53 -0500olcott <No...@NoWhere.com> wrote:> On 8/14/2022 2:14 PM, Mr Flibble wrote:> > On Sun, 14 Aug 2022 10:14:28 -0500> > olcott <No...@NoWhere.com> wrote:> > > >> *This is refers to H(P,P)==0 where H and P are functions in C*> >>> >> I believe I have learned something valuable from you:> >> that by simulation, and by simulations within simulations,> >> non-halting can sometimes be detected, and in particular,> >> it can be detected in the program used in the classical> >> proof of incomputability.> >>> >> *Halting problem proofs refuted on the basis of software> >> engineering* ?> >>> >> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering> >> > > > > I am also a computer scientist and I am telling you that your> > halting decider reporting non-halting when it enters "infinite> > recursion" is an ERROR. There is no infinite recursion in the HP> > proofs you are attempting to refute.> > > > /Flibble> > > > > void P(ptr x)> {> int Halt_Status = H(x, x);> if (Halt_Status)> HERE: goto HERE;> return;> }> > int main()> {> Output("Input_Halts = ", H(P, P));> }> > If it was true that you are a computer scientist then you would > understand that this execution trace is correct:> > (a) H(P,P) simulates P(P) that calls a simulated H(P,P)> (b) that simulates P(P) that calls a simulated H(P,P)> (c) that simulates P(P) that calls a simulated H(P,P)> (d) that simulates P(P) that calls a simulated H(P,P)...> *Until H aborts its simulation*I am a computer scientist and all your trace shows is that H (not P) isat the root of your so called "infinite recursion" and is the primaryreason why you are incorrect to map this recursive behaviour of your Hto a halting decision on P of non-halting.> > If you do not understand that the above execution trace is correct> then this proves that you are not as much as a sufficiently competent > software engineer.It seems I understand your trace more than you do which makes itobvious who is actually lacking in competence here./Flibble

Because H exactly simulates its input and has no control flow

behavior of it's own while it is simulating this input YOU ARE

BLAMING THE MIRROR FOR WHAT IT REFLECTS.

--

test

----Android NewsGroup Reader----

https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html

Aug 14, 2022, 6:16:44 PMAug 14

to

give an answer.

So either you are a liar, or just badly confused about what you are saying.

Aug 14, 2022, 6:59:06 PMAug 14

to

words.

Aug 14, 2022, 7:29:58 PMAug 14

to

before it stops?

I don't think you understand the meaning of control flow.

After each instruction it simulates, it makes a DECISION about whether

to abort or not.

THAT IS CONTROL FLOW.

Unless you have invented a Tardas, and it goes back in time to change

the path, it made a decision before the simulation was aborted, because

it had to DECIDE to abort its simulation.

You H did execute conditional instructions during its act of simulating,

and a change in that condition is what stopped the simulation.

You are either a very bad liar or a total idiot.

Aug 14, 2022, 7:33:39 PMAug 14

to

time that H is simulating P, thus any recursive behavior that P

demonstrates is behavior of P and not behavior of H.

Aug 14, 2022, 8:28:40 PMAug 14

to

This H by its actions might not affect the behavior of the input it is

simulating, but it doesn't correctly determine the effect that the copy

of H in P will have. Since H is a program, that behavior has been FIXED

and IMMUTABLE, and the behavior of your code is to abort its simulation,

and thus P doesn't get into infinite recusion. H just doesn't figure

that out, because it uses unsound logic.

YOU USE UNSOUND LOGIC.

Note, you answer doesn't answer the question, as the question is about

the affect that H has on the P that calls it, not the P that it is

simulating.

After all, that is what the questions about conditionals in H was about,

how does it affect the P(P) that calls it, and does it break the

otherwise infinite simulation loop. Since the simulated P(P) calls a

H(P,P) that will have conditionals in it, you can't just assume that

this H will just blindly get into the infinite loop that doesn't

actually happen.

You are just proving that you don't understand what you are talking

about and just trying to parrot words you have heard to try to make a point.

You are wrong.

It has been proven.

The fact that H(P,P) returns 0 means that the P(P) that H(P,P) needs to

decide on will be hatling, so H is wrong.

All you are doing is digging a deep grave for your ideas.

Aug 14, 2022, 8:48:01 PMAug 14

to

effect what-so-ever on the behavior of this input while it is simulating

this input?

The simulation by H of its input only mirrors the behavior of whatever

this input specifies.

Example 02:

H correctly determines that Infinite_Recursion() never halts

void Infinite_Recursion(int N)

{

Infinite_Recursion(N);

}

int main()

{

Output("Input_Halts = ", H((u32)Infinite_Recursion, 0x777));

Aug 14, 2022, 9:08:22 PMAug 14

to

(a) H(P,P) simulates P(P) that calls a simulated H(P,P)

(b) that simulates P(P) that calls a simulated H(P,P)

(c) that simulates P(P) that calls a simulated H(P,P)

(d) that simulates P(P) that calls a simulated H(P,P)...

*Until H aborts its simulation*

Aug 14, 2022, 9:30:18 PMAug 14

to

Your H just does (a) and the aborts its simulation brcause it THINKS

that a proper simulation of the input would never halt (but it does)

The problem is that BECAUSE H aborts its simulation and returns 0 the

CORRECT and COMPLETE simulation of the input would reach its final state.

You biggest problem is that you are starting from a wrong definition of

the problem.

H(M,x) {or in this case H(P,P)} needs to answer about the behavior that

you say it can't be asked, that of M(x), but that behavior IS the

behavior of the input if H claims to be a Halting decider.

Yes, we can refrase that question to asking about what UTM(M,x) or

UTM(P,P) does, which get around the representation issue you have.

UTM(P,P) Hslts if H(P,P) returns 0, so that isn't a correct response.

Note, the input to UTM(P,P) is EXACTLY the same input as the input to

H(P,P) so your arguement about "non-inputs" don't apply, as the behavior

IS of the input.

Aug 14, 2022, 9:41:45 PMAug 14

to

my H does and you can verify this with the complete system?

https://www.liarparadox.org/2022_07_22.zip

This is the complete system that compiles under:

Microsoft Visual Studio Community 2017

https://visualstudio.microsoft.com/vs/older-downloads/

Aug 14, 2022, 9:52:49 PMAug 14

to

You are just proving how dumb you are.

(b), (c), (d) don't happen BECAUSE H abort its simulation as soon as it

sees P(P) call H(P,P).

BECAUSE H(P,P) aborts at this point, and returns 0, it doesn't actually

do a CORRECT simulation, as it prsumes that the simulated H(P,P) will

not return, but it returns 0, thus H is INCORRECT.

We can see the CORRECT simulation when we do UTM(P,P) which agres with

this Halting Answer.

The question that H needs to answer is NOT does it need to abort it

simulation, since of a given H, there is no choice there, it does what

it is programmed.

THe question that H needs to answer is does the program that input is

based on Halt or not?

Since P(P) Halts, the CORRECT answer for H(P,P) is 1, but it returns 0,

so is wrong.

Your claims that the behavior of input to H(P,P) isn't the behavior of

P(P) is just wrong, and based on incorrect reasoning. Since this is what

P means by its call to H(P,P), if it doesn't mean that you whole proof

just becomes a LIE.

Aug 14, 2022, 9:58:46 PMAug 14

to

Then you changed the subject.

Aug 14, 2022, 10:14:05 PMAug 14

to

match you pattern.

So you are just caught in the lie.

You claim to be showing an repeating infinite loop, but it is OBVIOUS

that when P(P) calls H(P,P) that it will very quickly get an answer

backm and NOT the infinite lopp you claim it gets stuck in.

The fact that you H doesn't even look into the behavior of H is a sign

that it can easily be wrong. The fact that its prediction doesn't match

what it actaully does, proves it.

You need to LIE about the pattern that it produces, because the accurate

trace is so short it is easy to see the flaw.

You had to shorten the trace that it actually did, because making it

behave as you show above made you H needing to use static memory to

comunicate between layers, show that you weren't a pure function.

And the rest is NOT a change of subject, but point out that you are not

correct about H exactly correctly simulating its input.

Since you LIE, your words are not correct.

YOU FAIL.

Aug 14, 2022, 10:26:22 PMAug 14

to

The other H does not get past step (c) and can be adapted to proceed any

finite number of steps.

The point is that no correct simulation of the input to H(P,P) by H ever

stops running until H aborts it.

Aug 15, 2022, 7:50:51 AMAug 15

to

You don't get to "Adapt" it. That is your problem. You have to use the H

that you have provide EVERYWHERE.

NO H gets past step (a), but the CORRECT simulation of the input gets to

the end.

Your problem is that NO H does a CORRECT AND COMPLETE simulation, but

that is (one way) that Halting is defined.

The Correct and Complete simulation of P,P does Halt.

Thus the right answer is 1, not the 0 that H(P,P) returns.

You are just eating POOP, and that has addled your brain.

Aug 15, 2022, 10:56:18 AMAug 15

to

Aug 15, 2022, 6:47:41 PMAug 15

to

by H(P,P) at the point where P(P) calls H(P,P)?

Aug 15, 2022, 7:36:18 PMAug 15

to

The correct simulation by H(P,P), never stops running until H aborts it.

The exact point in the execution trace of the correct simulation of the

input to H(P,P) where the simulation is aborted is an implementation

detail that is separate from this algorithm.

Aug 15, 2022, 8:33:06 PMAug 15

to

P(P) as soon as it calls H(P,P). That is EXACTLY what the code you have

published for your H does.

>

> The exact point in the execution trace of the correct simulation of the

> input to H(P,P) where the simulation is aborted is an implementation

> detail that is separate from this algorithm.

>

otherwise it isn't an actual ALGORITM, it is just a algorithm TEMPLATE.

Until you SPECIFY that "detail", you don't have an actual H.

Is that you problem, you don't understand that in Computation Theory,

and algorithm is the COMPLETE specification of the steps needd to carry

out the computaiton?

You can't just say "Until it proves ....", you need to specify EXACTLY

HOW it proves that. That means the EXACT pattern set that H uses.

You are just showing how little you understand what you are talking about.

Aug 15, 2022, 8:44:02 PMAug 15

to

implementation?

https://www.geeksforgeeks.org/introduction-to-algorithms/

The algorithm: A simulating halt decider (SHD) continues to simulate its

input until it correctly matches a non-halting behavior pattern or the

input halts on its own. If a non-halting behavior pattern is matched

then the SHD aborts the simulation of its input and reports non-halting.

If the input halts on its own the SHD report halting.

Aug 15, 2022, 9:04:08 PMAug 15

to

non-halting behavior patterns, not just say it "match one" without

providing them,

Note, from the page you mention:

Finite-ness: The algorithm must be finite, i.e. it should terminate

after a finite time.

"Proving a pattern is non-halting" is not a finite algorithm.

"Proving" something is not an algorithmic step, as there is no guarantee

that something CAN be proved in finite time.

That is just the assuming a Halt Decider exists fallacy.

The pattern you CLAIM, is proved to not be correct, so your specific

implementation is incorrect.

Obviously, you still don't understand what an algorithm is.

Remember, the concept of an algorithm is that it is detailed enough that

a simple program could just code based on the description (or someone

could just execute it by following it).

Without an actual list of patterns, it can't just be followed.

Aug 15, 2022, 9:16:13 PMAug 15

to

> Note, from the page you mention:

> Finite-ness: The algorithm must be finite, i.e. it should terminate

> after a finite time.

>

> "Proving a pattern is non-halting" is not a finite algorithm.

>

For any program H that might determine if programs halt, a

"pathological" program P, called with some input, can pass

its own source and its input to H and then specifically do the

opposite of what H predicts P will do.

*No H can exist that handles this case*

https://en.wikipedia.org/wiki/Halting_problem

> "Proving" something is not an algorithmic step, as there is no guarantee

> that something CAN be proved in finite time.

>

> That is just the assuming a Halt Decider exists fallacy.

>

> The pattern you CLAIM, is proved to not be correct, so your specific

> implementation is incorrect.

>

ridiculously stupid) to say that my system does not work on a non-input.

> Obviously, you still don't understand what an algorithm is.

> > Remember, the concept of an algorithm is that it is detailed enough that

> a simple program could just code based on the description (or someone

> could just execute it by following it).

>

> Without an actual list of patterns, it can't just be followed.

>

(b) infinite recursion

(c) infinitely recursive simulation either as an adaption to (b)

or exactly the same as (b).

Aug 15, 2022, 9:47:24 PMAug 15

to

call it one

>

>> Without an actual list of patterns, it can't just be followed.

>>

>

> (a) Infinite loop

> (b) infinite recursion

> (c) infinitely recursive simulation either as an adaption to (b)

> or exactly the same as (b).

If you can't just write the code from the specification, it isn't

detailed enough.

You are allowed to look well know operations up in a "cookbook", so

"Sort" could be treated as an algorithmic step.

"Prove" isn't in the cookbook, so can't be used.

The only DIRECT way to "detect" infinite behavior is to wait infinite

time, which isn't an algorithm.

Thus, none of your (a), (b), (c) are algorithmic steps.

You need to SPECIFY what you are going to look for to detect each of them.

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

as you are still making elementary mistakes.

Aug 15, 2022, 9:58:25 PMAug 15

to

IMPLEMENT A SHD THAT CORRECTLY DETERMINES THE HALT STATUS OF THE ABOVE

PATHOLOGICAL INPUT:

The algorithm: A simulating halt decider (SHD) continues to simulate its

input until it correctly matches a non-halting behavior pattern or the

input halts on its own. If a non-halting behavior pattern is matched

then the SHD aborts the simulation of its input and reports non-halting.

If the input halts on its own the SHD report halting.

Aug 15, 2022, 10:20:10 PMAug 15

to

Because you wrote it to the wrong question!

H(P,P) is SUPPOSED to tell us what P(P) will do, after all, that is what

the P you provide is asking it.

H is WRONG for that.

The problem is you just don't know how to write an implemententable

specification, because you just don't understand what that mean\s.

You just THINK that there exist a "non-halting behavior pattern" that H

can match is its simulation of P(P).

You have said what you think that pattern is, but it is show to be

incorrect, as the P(P) based on the H that uses that pattern halts, so

the pattern isn't correct.

You are just living in a world where you have assumed that Fairy Dust

Powered Unicord exist, and they can magically make what you need happen.

Your Halt Decider to do its job needs to be given a Halt Decider. And

that Halr Decider to do its job will be needed to be given another,

better, Halt Decider, and so on until your algorithm is no longer finite.

YOU FAIL.

Aug 15, 2022, 10:40:52 PMAug 15

to

of the correct simulation that H performs on P THEN H GETS THE CORRECT

ANSWER. H DOES CORRECTLY PREDICT THAT ITS COMPLETE SIMULATION OF P WOULD

NEVER STOP RUNNING.

Aug 15, 2022, 10:51:25 PMAug 15

to

It is just wrong, and you prove you are dumb. You start from a LIE, so

you can't actualy prove what you claim.

The ACTUAL CORRECT and COMPLETE simulation of the input to H(P,P), which

P does not do, will Halt, so H(P,P) returning 0 is incorrect.

You are just showing that you are living in a fantasy world where Truth

doesn't actualy matter.

You are just talking about POOP, not Halting.

Aug 15, 2022, 11:02:46 PMAug 15

to

input then H(P,P)==0 is correct?

Aug 15, 2022, 11:28:20 PMAug 15

to

complete x86 emulation of its input would never stop running unless and

until it aborts its x86 emulation of this input.

Aug 16, 2022, 7:13:32 AMAug 16