Here is what a computer scientist that has been published in CACM said about my work

356 views
Skip to first unread message

olcott

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

Mr Flibble

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

olcott

unread,
Aug 14, 2022, 11:43:10 AMAug 14
to
Anyone (especially those that use fake names) can call themselves a
"computer scientist". To get published in CACM is a whole other ballgame.

Mr Flibble

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

olcott

unread,
Aug 14, 2022, 12:39:14 PMAug 14
to
There are no flaws in the software engineering of my halt decider,
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

Mr Flibble

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

olcott

unread,
Aug 14, 2022, 1:00:04 PMAug 14
to
*THAT THIS IS OVER YOUR HEAD IN NO ACTUAL REBUTTAL*
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
>


d thiebaud

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

olcott

unread,
Aug 14, 2022, 1:06:35 PMAug 14
to
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.

Mr Flibble

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

Mr Flibble

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


olcott

unread,
Aug 14, 2022, 1:20:36 PMAug 14
to
All of the so-called "flaws" are merely the *strawman deception* and
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


Skep Dick

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

Mr Flibble

unread,
Aug 14, 2022, 1:27:43 PMAug 14
to
On Sun, 14 Aug 2022 12:20:30 -0500
QED

/Flibble

Richard Harnden

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

olcott

unread,
Aug 14, 2022, 1:39:48 PMAug 14
to
The HP proofs conclude that the HP cannot be solved on the basis of the
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.

olcott

unread,
Aug 14, 2022, 1:45:07 PMAug 14
to
I cannot effectively reply to your half of a sentence.

Richard Damon

unread,
Aug 14, 2022, 2:16:15 PMAug 14
to
No, your proof is invalid first because it answers to a Strawman, and
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.

olcott

unread,
Aug 14, 2022, 2:32:08 PMAug 14
to
It <is> correct software engineering in that H(P,P) does correctly
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

Richard Damon

unread,
Aug 14, 2022, 2:56:41 PMAug 14
to
Nope. First arguement represents a HALTING computation, because H is
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.

But it does map the behavior of the CORRECT (and COMPLETE) simulation of
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
>
>

No, you have the wrong definiton of correct simulation.

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.

olcott

unread,
Aug 14, 2022, 2:58:51 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));
}

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*

olcott

unread,
Aug 14, 2022, 3:02:39 PMAug 14
to
"represents" is a weak relationship is not the same as "specifies".
The cross symbol "represents" Christ, it is not Christ himself.

Richard Damon

unread,
Aug 14, 2022, 3:03:35 PMAug 14
to
Except that isn't the trace we get.

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

Richard Damon

unread,
Aug 14, 2022, 3:07:53 PMAug 14
to
RED HERRING.


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.

Mr Flibble

unread,
Aug 14, 2022, 3:14:34 PMAug 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
>

olcott

unread,
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
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
this proves that you are not as much as a sufficiently competent
software engineer.

olcott

unread,
Aug 14, 2022, 3:38:21 PMAug 14
to
I have shown what correct means dozens of times.

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.

Richard Damon

unread,
Aug 14, 2022, 3:52:42 PMAug 14
to
Except that is DOESN'T, since the x86 code of P has a call to H that
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.

Mr Flibble

unread,
Aug 14, 2022, 3:55:46 PMAug 14
to
I am a computer scientist and all your trace shows is that H (not P) is
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.

It seems I understand your trace more than you do which makes it
obvious who is actually lacking in competence here.

/Flibble

olcott

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

Richard Damon

unread,
Aug 14, 2022, 6:16:44 PMAug 14
to
H does have control low on its own, or it can't stop the simulationg to
give an answer.

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

olcott

unread,
Aug 14, 2022, 6:59:06 PMAug 14
to
Or you OCD prevents you from paying close enough attention to ALL of my
words.

Richard Damon

unread,
Aug 14, 2022, 7:29:58 PMAug 14
to
Then how does it decide to stop simulating if it has no control flow
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.


olcott

unread,
Aug 14, 2022, 7:33:39 PMAug 14
to
H does not have any effect on the behavior of its simulated P the whole
time that H is simulating P, thus any recursive behavior that P
demonstrates is behavior of P and not behavior of H.

Richard Damon

unread,
Aug 14, 2022, 8:28:40 PMAug 14
to
Nope, the problem is in H, not P.

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.

olcott

unread,
Aug 14, 2022, 8:48:01 PMAug 14
to
How can this possibly be when H merely simulates its input and has no
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));

olcott

unread,
Aug 14, 2022, 9:08:22 PMAug 14
to
So you disagree with this:

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



Richard Damon

unread,
Aug 14, 2022, 9:30:18 PMAug 14
to
That isn't what your H does, and it answers the wrong question.

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.

olcott

unread,
Aug 14, 2022, 9:41:45 PMAug 14
to
Why do you say that isn't what my H does when you know that it is what
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/

Richard Damon

unread,
Aug 14, 2022, 9:52:49 PMAug 14
to
Right, you didn't read what I said you H does, did you?

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.

olcott

unread,
Aug 14, 2022, 9:58:46 PMAug 14
to
You said that what I said H does, it does not do, this is incorrect.
Then you changed the subject.

Richard Damon

unread,
Aug 14, 2022, 10:14:05 PMAug 14
to
You H does NOT get to the step (b) that you have posted, so doesn't
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.

olcott

unread,
Aug 14, 2022, 10:26:22 PMAug 14
to
One H does not get past step (b)
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.

Richard Damon

unread,
Aug 15, 2022, 7:50:51 AMAug 15
to
Nope, look at the code you provided.

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.

olcott

unread,
Aug 15, 2022, 10:56:18 AMAug 15
to
Liar

Richard Damon

unread,
Aug 15, 2022, 6:47:41 PMAug 15
to
Are you saying the code you provided DOESN'T abort the simulation done
by H(P,P) at the point where P(P) calls H(P,P)?


olcott

unread,
Aug 15, 2022, 7:36:18 PMAug 15
to
The algorithm implemented by H:
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.

Richard Damon

unread,
Aug 15, 2022, 8:33:06 PMAug 15
to
No, the algorithm implemented by your H is to abort the simulation of
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.
>

WRONG. The actual alrgorith INCLUDES the choice of that detail,
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.

olcott

unread,
Aug 15, 2022, 8:44:02 PMAug 15
to
So you don't know the difference between an algorithm and its
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.

Richard Damon

unread,
Aug 15, 2022, 9:04:08 PMAug 15
to
Right. But, to be an algorithm, you need to SPECIFY the list of
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.

olcott

unread,
Aug 15, 2022, 9:16:13 PMAug 15
to
Then call it a high level design.

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

My detailed design only needs to apply to this pattern:
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.

I have proved that it can be proved in the above example.

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

I prove that the input does not halt, it is no rebuttal at all (and
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).
>

Call it a high level design.

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

Richard Damon

unread,
Aug 15, 2022, 9:47:24 PMAug 15
to
But it thus isn't an algorithm, so you need to specify it tighter 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).

Doesn't define what to look for, so not actually a list of patterns.

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.

olcott

unread,
Aug 15, 2022, 9:58:25 PMAug 15
to
THIS IS SUFFICIENT FOR EVERY EXCEPTIONALLY TALENTED SOFTWARE ENGINEER 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.

INSSTEAD OF PLAYING HEAD GAMES LET'S JUST AGREE ON THAT

Richard Damon

unread,
Aug 15, 2022, 10:20:10 PMAug 15
to
Then why does it get the wrong answer?

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.

olcott

unread,
Aug 15, 2022, 10:40:52 PMAug 15
to
When the measure of the behavior of the input to H(P,P) is the behavior
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.

Richard Damon

unread,
Aug 15, 2022, 10:51:25 PMAug 15
to
Except it isn't, so you can't.

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.

olcott

unread,
Aug 15, 2022, 11:02:46 PMAug 15
to
So you agree that if this is the correct measure of the behavior of the
input then H(P,P)==0 is correct?

olcott

unread,
Aug 15, 2022, 11:28:20 PMAug 15
to
The C function H(P,P) does correctly predict that its correct and
complete x86 emulation of its input would never stop running unless and
until it aborts its x86 emulation of this input.

Richard Damon

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