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

[olcott]

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

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]

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]

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]

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]

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]

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

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]

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]

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]

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]

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]

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]

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

QED

/Flibble

[Richard Harnden]

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]

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]

I cannot effectively reply to your half of a sentence.

[Richard Damon]

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]

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]

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]

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]

"represents" is a weak relationship is not the same as "specifies".
The cross symbol "represents" Christ, it is not Christ himself.

[Richard Damon]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Or you OCD prevents you from paying close enough attention to ALL of my
words.

[Richard Damon]

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]

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]

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]

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]

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]

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]

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]

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]

You said that what I said H does, it does not do, this is incorrect.
Then you changed the subject.

[Richard Damon]

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]

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]

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]

Liar

[Richard Damon]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

So you agree that if this is the correct measure of the behavior of the
input then H(P,P)==0 is correct?

[olcott]

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]

The statement is meaningless as it is based on an impossible premise, so
can't be 'correct'.

[Richard Damon]

No, it doesn't.

The Correct and Complete x86 emulation of the program P(P) Halts, so it
is impossible for H to be correct about it not halting.

An H that answers doesn't do a correct and complete emulation so you
can't do any logic based on the fact that it does.

FAIL.

Your logic is just UNSOUND, as is your mind.

[olcott]

Again you lie. The correct and complete x86 emulation of the input to
H(P,P) by H never stops running.

[olcott]

Again you lie. The correct and complete x86 emulation of the input to
H(P,P) by H WOULD never stop running.

[Skep Dick]

On Tuesday, 16 August 2022 at 13:13:32 UTC+2, richar...@gmail.com wrote:
> The statement is meaningless as it is based on an impossible premise, so
> can't be 'correct'.

Shame. Somebody REALLY doesn't understand Rice's theorem. "impossibility" is meaningless.

A premise is a premise is a premise is a premise. In the abstract there is nothing which is explicitly forbidden; or allowed.

But then you have performed some computation on the premise.... And you have decided that the impossibility of the premise is true.

Impossible(premise) <=> True

Please show us the axioms under which your theorem holds.
Thanks!

[olcott]

The correct and complete x86 emulation of the input to H(P,P) by H WOULD
never stop running.

[Skep Dick]

On Tuesday, 16 August 2022 at 15:55:30 UTC+2, olcott wrote:
> The correct and complete x86 emulation of the input to H(P,P) by H WOULD
> never stop running.

Sounds like you are stuck in a loop.

Maybe your Decider/Maker should terminate you.

[olcott]

I have been trying to get an honest person to acknowledge the correct
software engineering of my system so that we can move on to the next
point for a year now. (bot many honest people here, mostly trolls).

H(P,P) does correctly predict that its correct and complete x86

emulation of its input would never stop running, thus does correctly
reject this input as non-halting.

*The next point after this point is why can't a TM do the same thing*?

[Skep Dick]

On Tuesday, 16 August 2022 at 16:27:14 UTC+2, olcott wrote:
> On 8/16/2022 9:07 AM, Skep Dick wrote:
> > On Tuesday, 16 August 2022 at 15:55:30 UTC+2, olcott wrote:
> >> The correct and complete x86 emulation of the input to H(P,P) by H WOULD
> >> never stop running.
> > Sounds like you are stuck in a loop.
> >
> > Maybe your Decider/Maker should terminate you.
> >
> I have been trying to get an honest person to acknowledge the correct
> software engineering of my system so that we can move on to the next
> point for a year now. (bot many honest people here, mostly trolls).
> H(P,P) does correctly predict that its correct and complete x86
> emulation of its input would never stop running, thus does correctly
> reject this input as non-halting.
>
> *The next point after this point is why can't a TM do the same thing*?

A Turing Machine can and does do the EXACT SAME THING!

It's literally in Turing's paper (had you bothered to read it).

There is a hierarchy of Turing computability.
A machine which is higher in the hierarchy (more powerful) can solve the halting problem for a machine lower in the hierarchy (less powerful).

All you've demonstrated is precisely THAT your halt decider is a more powerful program than the program it's deciding on.

Boring.

[olcott]

On 8/16/2022 9:30 AM, Skep Dick wrote:
> On Tuesday, 16 August 2022 at 16:27:14 UTC+2, olcott wrote:
>> On 8/16/2022 9:07 AM, Skep Dick wrote:
>>> On Tuesday, 16 August 2022 at 15:55:30 UTC+2, olcott wrote:
>>>> The correct and complete x86 emulation of the input to H(P,P) by H WOULD
>>>> never stop running.
>>> Sounds like you are stuck in a loop.
>>>
>>> Maybe your Decider/Maker should terminate you.
>>>
>> I have been trying to get an honest person to acknowledge the correct
>> software engineering of my system so that we can move on to the next
>> point for a year now. (bot many honest people here, mostly trolls).
>> H(P,P) does correctly predict that its correct and complete x86
>> emulation of its input would never stop running, thus does correctly
>> reject this input as non-halting.
>>
>> *The next point after this point is why can't a TM do the same thing*?
> A Turing Machine can and does do the EXACT SAME THING!
>
> It's literally in Turing's paper (had you bothered to read it).
>

A computer scientist that has been published in CACM says that because H
does not return a value when it is called in infinite recursion it is
not a pure function thus not Turing computable.

It seems to me that when CS requires a function to return a value when
it is called in infinite recursion and software engineering forbids this
that either CS or SE must be incorrect.

> There is a hierarchy of Turing computability.
> A machine which is higher in the hierarchy (more powerful) can solve the halting problem for a machine lower in the hierarchy (less powerful).
>
> All you've demonstrated is precisely THAT your halt decider is a more powerful program than the program it's deciding on.
>
> Boring.

[Skep Dick]

On Tuesday, 16 August 2022 at 16:37:41 UTC+2, olcott wrote:
> A computer scientist that has been published in CACM says...
That's an appeal to authority!

>that because H does not return a value when it is called in infinite recursion it is
> not a pure function thus not Turing computable.

And that's a tautology! We know!

Non-termination is an EFFECT

> It seems to me that when CS requires a function to return a value when it is called in infinite recursion and software engineering forbids this

Software engineering doesn't forbid anything. Software engineering exploits this fact.

An infinite loop (any program!) which prints output/logs is a function with side effects.

> that either CS or SE must be incorrect.

You fucking imbecille. You are in hospital, and on a death bed and you are still seeking social validation about being "correct" or "incorrect"!

Let me tell you about Michael O'Day's tombstone...

Here lies the body of Michael O'Day.
He died defending his right of way.
He was right, dead right, as he sailed along,
But just as dead as if he'd been wrong.

[olcott]

On 8/16/2022 9:53 AM, Skep Dick wrote:
> On Tuesday, 16 August 2022 at 16:37:41 UTC+2, olcott wrote:
>> A computer scientist that has been published in CACM says...
> That's an appeal to authority!
>

Which is legitimate under inductive inference.
When you have cancer you go to an oncologist, not a house painter.

>> that because H does not return a value when it is called in infinite recursion it is
>> not a pure function thus not Turing computable.
> And that's a tautology! We know!
>

Under computer science a function called in infinite recursion is
required to return a value to its caller as long as it returns a value
to its called when not called under infinite recursion.

> Non-termination is an EFFECT
>
>> It seems to me that when CS requires a function to return a value when it is called in infinite recursion and software engineering forbids this
> Software engineering doesn't forbid anything. Software engineering exploits this fact.
>

CS calls this fact untrue.

> An infinite loop (any program!) which prints output/logs is a function with side effects.
>
>> that either CS or SE must be incorrect.
> You fucking imbecille. You are in hospital, and on a death bed and you are still seeking social validation about being "correct" or "incorrect"!
>
> Let me tell you about Michael O'Day's tombstone...
>
> Here lies the body of Michael O'Day.
> He died defending his right of way.
> He was right, dead right, as he sailed along,
> But just as dead as if he'd been wrong.

[Skep Dick]

On Tuesday, 16 August 2022 at 17:05:05 UTC+2, olcott wrote:
> On 8/16/2022 9:53 AM, Skep Dick wrote:
> > On Tuesday, 16 August 2022 at 16:37:41 UTC+2, olcott wrote:
> >> A computer scientist that has been published in CACM says...
> > That's an appeal to authority!
> >
> Which is legitimate under inductive inference.
> When you have cancer you go to an oncologist, not a house painter.

No it isn't!

Do you want your onologist to be good at publishing papers.
Or do you want your oncologist to be good at curing cancer?

Do you want your ocologist to be good at WRITING or good at DOING?

> > Software engineering doesn't forbid anything. Software engineering exploits this fact.
> CS calls this fact untrue.

It depends on who you ask! CS is not a person.

Some Computer Scientists accept it as an axiom.
Some Computer Scientists rejectit as an axiom.

https://cstheory.stackexchange.com/questions/45539/can-non-termination-be-considered-an-algebraic-effect

[olcott]

On 8/16/2022 10:16 AM, Skep Dick wrote:
> On Tuesday, 16 August 2022 at 17:05:05 UTC+2, olcott wrote:
>> On 8/16/2022 9:53 AM, Skep Dick wrote:
>>> On Tuesday, 16 August 2022 at 16:37:41 UTC+2, olcott wrote:
>>>> A computer scientist that has been published in CACM says...
>>> That's an appeal to authority!
>>>
>> Which is legitimate under inductive inference.
>> When you have cancer you go to an oncologist, not a house painter.
> No it isn't!
>
> Do you want your onologist to be good at publishing papers.

You have to actually pay attention to ALL the words that I said
When you have cancer
When you have cancer
When you have cancer
When you have cancer

you go to an oncologist.

That you only glance at a few of the words that I said seems to indicate
that you are only a troll.

> Or do you want your oncologist to be good at curing cancer?
>
> Do you want your ocologist to be good at WRITING or good at DOING?
>
>>> Software engineering doesn't forbid anything. Software engineering exploits this fact.
>> CS calls this fact untrue.
> It depends on who you ask! CS is not a person.
>
> Some Computer Scientists accept it as an axiom.
> Some Computer Scientists rejectit as an axiom.
>
> https://cstheory.stackexchange.com/questions/45539/can-non-termination-be-considered-an-algebraic-effect
>
>
>
>
>
>
>
>
>

[Skep Dick]

On Tuesday, 16 August 2022 at 18:21:52 UTC+2, olcott wrote:
> On 8/16/2022 10:16 AM, Skep Dick wrote:
> > On Tuesday, 16 August 2022 at 17:05:05 UTC+2, olcott wrote:
> >> On 8/16/2022 9:53 AM, Skep Dick wrote:
> >>> On Tuesday, 16 August 2022 at 16:37:41 UTC+2, olcott wrote:
> >>>> A computer scientist that has been published in CACM says...
> >>> That's an appeal to authority!
> >>>
> >> Which is legitimate under inductive inference.
> >> When you have cancer you go to an oncologist, not a house painter.
> > No it isn't!
> >
> > Do you want your onologist to be good at publishing papers.
> You have to actually pay attention to ALL the words that I said

Yes! You fucking retard. Read ALL of MY words.

> When you have cancer
> When you have cancer
> When you have cancer
> When you have cancer
>
> you go to an oncologist.

WHEN you have cancer do you go to

An oncologist who THEORISES about oncology (writes papers).
OR
An oncologist who PRACTICES oncology (cures cancer).

Do you go to a theoretician; or a practitioner?

> That you only glance at a few of the words that I said seems to indicate
> that you are only a troll.

Then you are a troll! You fucking troll.

> > Do you want your ocologist to be good at WRITING or good at DOING?

See^^^^ I distinguished between the OUTPUT of oncologists.

One oncologist OUTPUTS academic papers.
One oncologist OUTPUTS side-effects (they treat cancer).

WHICH oncologist do you choose?

[olcott]

On 8/16/2022 11:30 AM, Skep Dick wrote:
> On Tuesday, 16 August 2022 at 18:21:52 UTC+2, olcott wrote:
>> On 8/16/2022 10:16 AM, Skep Dick wrote:
>>> On Tuesday, 16 August 2022 at 17:05:05 UTC+2, olcott wrote:
>>>> On 8/16/2022 9:53 AM, Skep Dick wrote:
>>>>> On Tuesday, 16 August 2022 at 16:37:41 UTC+2, olcott wrote:
>>>>>> A computer scientist that has been published in CACM says...
>>>>> That's an appeal to authority!
>>>>>
>>>> Which is legitimate under inductive inference.
>>>> When you have cancer you go to an oncologist, not a house painter.
>>> No it isn't!
>>>
>>> Do you want your onologist to be good at publishing papers.
>> You have to actually pay attention to ALL the words that I said
> Yes! You fucking retard. Read ALL of MY words.
>
>> When you have cancer
>> When you have cancer
>> When you have cancer
>> When you have cancer
>>
>> you go to an oncologist.
> WHEN you have cancer do you go to
>
> An oncologist who THEORISES about oncology (writes papers).
> OR
> An oncologist who PRACTICES oncology (cures cancer).

The point is that when you have cancer you do not go to a hairdresser,
you go to an oncologist thus validating the legitimacy of the appeal to
authority for inductive rather than deductive reasoning.

1. Appeal to Unqualified Authority (argumentum ad verecundiam):
This fallacy is committed whenever someone proposes that some
conclusion is true because someone who is NOT an authority on
the subject SAID it was true.

https://rintintin.colorado.edu/~vancecd/phil1440/weakinduction.pdf

[Mr Flibble]

Appeal to authority is ALWAYS a logical fallacy.

/Flibble

[olcott]

Within deductive logical inference.

Within inductive logical inference only the appeal to an unqualified
authority is a fallacy (as I just proved).


>
> /Flibble

[Mr Flibble]

On Tue, 16 Aug 2022 12:03:21 -0500

Nope; logical fallacies apply to argument and a logical fallacy is
always a logical fallacy.

/Flibble

[Skep Dick]

On Tuesday, 16 August 2022 at 18:41:03 UTC+2, olcott wrote:
> The point is that when you have cancer you do not go to a hairdresser,
> you go to an oncologist thus validating the legitimacy of the appeal to
> authority for inductive rather than deductive reasoning.

Bullshit! "An oncologist" is not a person. "An oncologist" is a proffession.

There all kinds of oncologists!
There are bad oncologists.
There are good oncologists.
There are experienced oncologists.
There are unexperienced oncologists.
There are poorly qualified oncologists.
There are oncologists which don't keep up with latest developments.
There are oncologists which are on top of their game.
There are oncologists who got into the proffession because they knew people.

> 1. Appeal to Unqualified Authority (argumentum ad verecundiam):
> This fallacy is committed whenever someone proposes that some
> conclusion is true because someone who is NOT an authority on
> the subject SAID it was true.

Yeah! Look at this word ... "UNQUALIFIED".

How do you distinguish between a qualified oncologist from an unqualified oncologist?

Your search procedure is underspecified!

[Skep Dick]

On Tuesday, 16 August 2022 at 19:03:29 UTC+2, olcott wrote:
> Within deductive logical inference.
>
> Within inductive logical inference only the appeal to an unqualified
> authority is a fallacy (as I just proved).

You have failed to prove that the authority you are appealing to is qualified.

Having qualifications is NOT the same thing as being qualified.

[Skep Dick]

On Tuesday, 16 August 2022 at 19:18:35 UTC+2, Mr Flibble wrote:
> Nope; logical fallacies apply to argument and a logical fallacy is
> always a logical fallacy.

You are committing the fallacy fallacy!

Just because the argument is fallacious; or and the reasoning is incorrect it doesn't mean the conclusion is wrong.

[olcott]

On 8/16/2022 12:21 PM, Skep Dick wrote:
> On Tuesday, 16 August 2022 at 19:03:29 UTC+2, olcott wrote:
>> Within deductive logical inference.
>>
>> Within inductive logical inference only the appeal to an unqualified
>> authority is a fallacy (as I just proved).
> You have failed to prove that the authority you are appealing to is qualified.
>

My purpose was to merely prove that "appeal to authority" is not a
fallacy within inductive inference. When you used the strawman deception
to change the subject that does not change my actual proof at all.

[Mr Flibble]

If the conclusion is predicated on faulty reasoning then the
conclusion cannot be trusted and can be dismissed within the context of
the argument irregardless of whether it is actually true or not.

/Flibble

[Skep Dick]

On Tuesday, 16 August 2022 at 19:26:46 UTC+2, olcott wrote:
> My purpose was to merely prove that "appeal to authority" is not a
> fallacy within inductive inference. When you used the strawman deception
> to change the subject that does not change my actual proof at all.

Those are big words you are using there.

None of it changes the fact that you are wrong.

[Skep Dick]

On Tuesday, 16 August 2022 at 19:28:08 UTC+2, Mr Flibble wrote:
> If the conclusion is predicated on faulty reasoning then the
> conclusion cannot be trusted and can be dismissed within the context of
> the argument irregardless of whether it is actually true or not.

None of which has anything to do with whether the conclusion is true; or not.

If the conclusion is true - the premises or the argument (the justification) doesn't matter.

[Mr Flibble]

If you know a priori that the conclusion is true then arguing about it
is pointless.

/Flibble

[olcott]

OK so you are only a troll

[Mr Flibble]

The conclusion in the following argument can be dismissed as fallacious
even though it is true. Why? Because it is only predicated on the
claims made in the argument it is a part of.

Mr Edgar Authority Expert The Third says all animals have four legs.
A cat has four legs.
Ergo a cat is an animal.

/Flibble

[Skep Dick]

On Tuesday, 16 August 2022 at 19:58:49 UTC+2, olcott wrote:
> On 8/16/2022 12:34 PM, Skep Dick wrote:
> > On Tuesday, 16 August 2022 at 19:26:46 UTC+2, olcott wrote:
> >> My purpose was to merely prove that "appeal to authority" is not a
> >> fallacy within inductive inference. When you used the strawman deception
> >> to change the subject that does not change my actual proof at all.
> > Those are big words you are using there.
> >
> > None of it changes the fact that you are wrong.
> >
> >
> >
> OK so you are only a troll

No, moron.

It is undecidable wheher I am a troll. The fact that you've decided contradicts undecidability.

Ergo - you are wrong.

[Skep Dick]

On Tuesday, 16 August 2022 at 20:02:27 UTC+2, Mr Flibble wrote:
> On Tue, 16 Aug 2022 10:36:31 -0700 (PDT)
> Skep Dick <skepd...@gmail.com> wrote:
>
> > On Tuesday, 16 August 2022 at 19:28:08 UTC+2, Mr Flibble wrote:
> > > If the conclusion is predicated on faulty reasoning then the
> > > conclusion cannot be trusted and can be dismissed within the
> > > context of the argument irregardless of whether it is actually true
> > > or not.
> > None of which has anything to do with whether the conclusion is true;
> > or not.
> >
> > If the conclusion is true - the premises or the argument (the
> > justification) doesn't matter.
> The conclusion in the following argument can be dismissed as fallacious
> even though it is true.

No! The conclusion cannot be dismissed as fallacious BECAUSE the conclusion is true.

The argument is fallacious and can be dismissed, but that doesn't matter.
The conclusion cannot be dismissed because the conclusion is true!

Your conclusion (that the conclusion can be dismissed) is a fallacy.

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

> Why? Because it is only predicated on the
> claims made in the argument it is a part of.
>
> Mr Edgar Authority Expert The Third says all animals have four legs.
> A cat has four legs.
> Ergo a cat is an animal.

This is practically the same example as the one in the wiki page.

https://en.wikipedia.org/wiki/Argument_from_fallacy#Examples

[olcott]

None-the-less since you have proven to not be interested in an honest
dialogue you will be ignored.

[Skep Dick]

On Tuesday, 16 August 2022 at 21:13:50 UTC+2, olcott wrote:
> On 8/16/2022 1:03 PM, Skep Dick wrote:
> > On Tuesday, 16 August 2022 at 19:58:49 UTC+2, olcott wrote:
> >> On 8/16/2022 12:34 PM, Skep Dick wrote:
> >>> On Tuesday, 16 August 2022 at 19:26:46 UTC+2, olcott wrote:
> >>>> My purpose was to merely prove that "appeal to authority" is not a
> >>>> fallacy within inductive inference. When you used the strawman deception
> >>>> to change the subject that does not change my actual proof at all.
> >>> Those are big words you are using there.
> >>>
> >>> None of it changes the fact that you are wrong.
> >>>
> >>>
> >>>
> >> OK so you are only a troll
> > No, moron.
> >
> > It is undecidable wheher I am a troll. The fact that you've decided contradicts undecidability.
> >
> > Ergo - you are wrong.
> None-the-less since you have proven to not be interested in an honest
> dialogue you will be ignored.

Q.E.D

honest/dishonest are undecidable.

But you have decided.

So you are wrong.

[Richard Damon]

On 8/16/22 10:27 AM, olcott wrote:
> On 8/16/2022 9:07 AM, Skep Dick wrote:
>> On Tuesday, 16 August 2022 at 15:55:30 UTC+2, olcott wrote:
>>> The correct and complete x86 emulation of the input to H(P,P) by H WOULD
>>> never stop running.
>> Sounds like you are stuck in a loop.
>>
>> Maybe your Decider/Maker should terminate you.
>>
>
> I have been trying to get an honest person to acknowledge the correct
> software engineering of my system so that we can move on to the next
> point for a year now. (bot many honest people here, mostly trolls).

The problem is that what you say ISN'T CORRECT software engineering.

You use the wrong definition of things and incorrect assumptions about
thing, so it just isn't true.

>
> H(P,P) does correctly predict that its correct and complete x86
> emulation of its input would never stop running, thus does correctly
> reject this input as non-halting.
>

Nope. And in fact, you even acknoldge it doesn't but just don't see it.

[Richard Damon]

On 8/16/22 10:37 AM, olcott wrote:
> On 8/16/2022 9:30 AM, Skep Dick wrote:
>> On Tuesday, 16 August 2022 at 16:27:14 UTC+2, olcott wrote:
>>> On 8/16/2022 9:07 AM, Skep Dick wrote:
>>>> On Tuesday, 16 August 2022 at 15:55:30 UTC+2, olcott wrote:
>>>>> The correct and complete x86 emulation of the input to H(P,P) by H
>>>>> WOULD
>>>>> never stop running.
>>>> Sounds like you are stuck in a loop.
>>>>
>>>> Maybe your Decider/Maker should terminate you.
>>>>
>>> I have been trying to get an honest person to acknowledge the correct
>>> software engineering of my system so that we can move on to the next
>>> point for a year now. (bot many honest people here, mostly trolls).
>>> H(P,P) does correctly predict that its correct and complete x86
>>> emulation of its input would never stop running, thus does correctly
>>> reject this input as non-halting.
>>>
>>> *The next point after this point is why can't a TM do the same thing*?
>> A Turing Machine can and does do the EXACT SAME THING!
>>
>> It's literally in Turing's paper (had you bothered to read it).
>>
>
> A computer scientist that has been published in CACM says that because H
> does not return a value when it is called in infinite recursion it is
> not a pure function thus not Turing computable.

If he said that, he just disproved your statement,

If H isn't a Pure Function, even though you have been claiming it is,
then your proof just falls apart.

Just proves how badly you understand what people say.

>
> It seems to me that when CS requires a function to return a value when
> it is called in infinite recursion and software engineering forbids this
> that either CS or SE must be incorrect.

The problem is that the H(P,P) that returns 0 ISN'T called in infinite
recursion, because ALL copies of it will abort there simulation at the
same point in their processing.

Thus, there isn't a problem.

[Richard Damon]

On 8/16/22 9:44 AM, olcott wrote:
> On 8/16/2022 6:16 AM, Richard Damon wrote:
>> On 8/15/22 11:28 PM, olcott wrote:
>>> On 8/15/2022 9:51 PM, Richard Damon wrote:
>>>> On 8/15/22 10:40 PM, olcott wrote:
>>>>> On 8/15/2022 9:20 PM, Richard Damon wrote:
>>>>>> On 8/15/22 9:58 PM, olcott wrote:
>>>>>>> On 8/15/2022 8:47 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 8/15/22 9:16 PM, olcott wrote:
>>>>>>>>> On 8/15/2022 8:04 PM, Richard Damon wrote:
>>>>>>>>>> On 8/15/22 8:43 PM, olcott wrote:
>>>>>>>>>>> On 8/15/2022 7:33 PM, Richard Damon wrote:
>>>>>>>>>>>> On 8/15/22 7:36 PM, olcott wrote:
>>>>>>>>>>>>> On 8/15/2022 5:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 8/15/22 10:56 AM, olcott wrote:
>>>>>>>>>>>>>>> On 8/15/2022 6:50 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 8/14/22 10:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 8/14/2022 9:14 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 8/14/22 9:58 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 8/14/2022 8:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 8/14/22 9:41 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 8/14/2022 8:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 8/14/22 9:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 8/14/2022 7:28 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 8/14/22 7:33 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 8/14/2022 6:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 8/14/22 6:58 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 8/14/2022 5:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 8/14/22 5:52 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H does have control low on its own, or it
>>>>>>>>>>>>>>>>>>>>>>>>>>>> can't stop the simulationg to give an answer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Because H exactly simulates its input and has
>>>>>>>>>>>>>>>>>>>>>>>>>>> no control flow
>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of it's own
>>>>>>>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> YOU ARE BLAMING THE MIRROR FOR WHAT IT REFLECTS.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> So either you are a liar, or just badly
>>>>>>>>>>>>>>>>>>>>>>>>>>>> confused about what you are saying.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Or you OCD prevents you from paying close
>>>>>>>>>>>>>>>>>>>>>>>>>>> enough attention to ALL of my words.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Then how does it decide to stop simulating if
>>>>>>>>>>>>>>>>>>>>>>>>>> it has no control flow before it stops?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 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));
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 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*
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> That isn't what your H does,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 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/
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Right, you didn't read what I said you H does, did you?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You said that what I said H does, it does not do,
>>>>>>>>>>>>>>>>>>> this is incorrect.
>>>>>>>>>>>>>>>>>>> Then you changed the subject.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You H does NOT get to the step (b) that you have
>>>>>>>>>>>>>>>>>> posted, so doesn't match you pattern.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, look at the code you provided.
>>>>>>>>>>>>>>> Liar
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The algorithm implemented by H:
>>>>>>>>>>>>> The correct simulation by H(P,P), never stops running until
>>>>>>>>>>>>> H aborts it.
>>>>>>>>>>>>
>>>>>>>>>>>> No, the algorithm implemented by your H is to abort the
>>>>>>>>>>>> simulation of P(P) as soon as it calls H(P,P).
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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,
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> Then why does it get the wrong answer?
>>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Except it isn't, so you can't.
>>>>
>>>
>>> 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.
>>>
>>>
>>>
>>
>> No, it doesn't.
>>
>> The Correct and Complete x86 emulation of the program P(P) Halts,
>
> Again you lie. The correct and complete x86 emulation of the input to
> H(P,P) by H never stops running.
>
>

The problem is that your H (at least those that answer) don't do a
complete and correct x86 emultion of their input, so your statement is
vacuous and unsound.

Even YOU have publish the correct and complete trace of a emulation of
the input to H(P,P) when H(P,P) returns 0, and show that it does halt.

Your problem is still that you use the wrong defintions.

It doesn't matter WHAT does the correct and complete trace, as long as
it is THE correct and complete trace (and there is only one for a given
P and thus a given H). And, for any H(P,P) that returns 0, it is shown
that this trace will finish, and thus that is NEVER the correct answer.

All you have proven is that if you H(P,P) fails to be a decider, then
P(P) can be non-halting, that isn't a counter example.

PERIOD.

[olcott]

So you are saying that the correct and complete x86 emulation by H(P,P)
of its input WOULD STOP RUNNING?

[olcott]

On 8/16/2022 8:14 PM, Richard Damon wrote:
> On 8/16/22 10:37 AM, olcott wrote:
>> On 8/16/2022 9:30 AM, Skep Dick wrote:
>>> On Tuesday, 16 August 2022 at 16:27:14 UTC+2, olcott wrote:
>>>> On 8/16/2022 9:07 AM, Skep Dick wrote:
>>>>> On Tuesday, 16 August 2022 at 15:55:30 UTC+2, olcott wrote:
>>>>>> The correct and complete x86 emulation of the input to H(P,P) by H
>>>>>> WOULD
>>>>>> never stop running.
>>>>> Sounds like you are stuck in a loop.
>>>>>
>>>>> Maybe your Decider/Maker should terminate you.
>>>>>
>>>> I have been trying to get an honest person to acknowledge the correct
>>>> software engineering of my system so that we can move on to the next
>>>> point for a year now. (bot many honest people here, mostly trolls).
>>>> H(P,P) does correctly predict that its correct and complete x86
>>>> emulation of its input would never stop running, thus does correctly
>>>> reject this input as non-halting.
>>>>
>>>> *The next point after this point is why can't a TM do the same thing*?
>>> A Turing Machine can and does do the EXACT SAME THING!
>>>
>>> It's literally in Turing's paper (had you bothered to read it).
>>>
>>
>> A computer scientist that has been published in CACM says that because
>> H does not return a value when it is called in infinite recursion it
>> is not a pure function thus not Turing computable.
>
> If he said that, he just disproved your statement,

*Not at all. No one has disproved this statement*

H(P,P) does correctly predict that its correct and complete x86
emulation of its input would never stop running, thus does correctly
reject this input as non-halting.

Every attempt to "disprove" that statement twists its words and
disproves the twisted words.

[olcott]

correctly predict
correctly predict
correctly predict
correctly predict
correctly predict
correctly predict
correctly predict
correctly predict

[Richard Damon]

On 8/16/22 9:20 PM, olcott wrote:
> On 8/16/2022 8:10 PM, Richard Damon wrote:
>> On 8/16/22 10:27 AM, olcott wrote:
>>> On 8/16/2022 9:07 AM, Skep Dick wrote:
>>>> On Tuesday, 16 August 2022 at 15:55:30 UTC+2, olcott wrote:
>>>>> The correct and complete x86 emulation of the input to H(P,P) by H
>>>>> WOULD
>>>>> never stop running.
>>>> Sounds like you are stuck in a loop.
>>>>
>>>> Maybe your Decider/Maker should terminate you.
>>>>
>>>
>>> I have been trying to get an honest person to acknowledge the correct
>>> software engineering of my system so that we can move on to the next
>>> point for a year now. (bot many honest people here, mostly trolls).
>>
>> The problem is that what you say ISN'T CORRECT software engineering.
>>
>> You use the wrong definition of things and incorrect assumptions about
>> thing, so it just isn't true.
>>
>>>
>>> H(P,P) does correctly predict that its correct and complete x86
>>> emulation of its input would never stop running, thus does correctly
>>> reject this input as non-halting.
>>>
>>
>> Nope. And in fact, you even acknoldge it doesn't but just don't see it.
>>
>
> So you are saying that the correct and complete x86 emulation by H(P,P)
> of its input WOULD STOP RUNNING?
>

No, I am saying that you H doesn't do a correct and complete emulation
of its input, and thus to say it did is just a LIE.

Yes, there is ANOTHER machine that you deceitfully also call H, the Hn
that never aborts, and yes, for that Hn, it does correctly and
completely emulate its input of PN(Pn) and that is non-halting, but Hn
fails to answer, so doesn't give the correct answer either.

You decietfully confuse the two H's which are DIFFERENT deciders, to try
to make you point.

BOTH FAIL, but in different ways.

YOU ARE JUST A DECEITFUL LIAR.

[Richard Damon]

LIE.

I know I have, and so have others.

You are just too stupid to understand it because YOU use incorrect
definitions to try to twist your words.

Please show EXACTLY which words I have "twisted", and what the correct
meaning is.

I DARE YOU.

Otherwise, you are just proved to be a LIAR.

A DAMNED LIAR.

[Richard Damon]

How can you correctly predict about a behavior that never happens.

You forget that the H you are talking about isn't just some abstract
idea of a Decider, but an actual particular instance of one.

That H DOES abort its simulation, so asking about the complete
simulation is asking about something that just didn't happen.

What color was The famous Napoleon Bonaparte's shoes when he landed on Mars?

There is no answer, as it didn't happen. Just like there is no answer
about the complete simulation done by THIS H, since it didn't do one.

It is a DIFFERENT H that does the complete simulation, one that nevers
answers.