dbush and user253751 continued conversation

[olcott]

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

It is the case that the copy of H (called embedded_H) at Ĥ.qx must abort
the simulation of its input or Ĥ applied to ⟨Ĥ⟩ would never stop running.

A simulating halt decider simulates N steps of its input until its input
halts on its own or it correctly determines that a pure simulation of
its input would never stop running.

https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (315-320)

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

[Richard Damon]

On 1/13/22 3:33 PM, olcott wrote:
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> It is the case that the copy of H (called embedded_H) at Ĥ.qx must abort
> the simulation of its input or Ĥ applied to ⟨Ĥ⟩ would never stop running.
>

So, that doesn't say anything about what the H^ built from an H that
does this will do. It just proves that an H^ built from an H that
doesn't abort will be non-halting, but that H won't answer, so is wrong.

> A simulating halt decider simulates N steps of its input until its input
> halts on its own or it correctly determines that a pure simulation of
> its input would never stop running.
>

WRONG. Already proven incorrect. FAIL.

[olcott]

On 1/13/2022 5:55 PM, Richard Damon wrote:
> On 1/13/22 3:33 PM, olcott wrote:
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> It is the case that the copy of H (called embedded_H) at Ĥ.qx must
>> abort the simulation of its input or Ĥ applied to ⟨Ĥ⟩ would never stop
>> running.
>>
>
> So, that doesn't say anything about what the H^ built from an H that
> does this will do. It just proves that an H^ built from an H that
> doesn't abort will be non-halting, but that H won't answer, so is wrong.
>

>> A simulating halt decider simulates N steps of its input until its
>> input halts on its own or it correctly determines that a pure
>> simulation of its input would never stop running.
>>
>
> WRONG. Already proven incorrect. FAIL.

You have never provided any proof all that you have ever had is dogmatic
assertions.

>
>
>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>> Lexington/Toronto: D. C. Heath and Company. (315-320)
>>
>

[Richard Damon]

On 1/13/22 7:11 PM, olcott wrote:
> On 1/13/2022 5:55 PM, Richard Damon wrote:
>> On 1/13/22 3:33 PM, olcott wrote:
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> It is the case that the copy of H (called embedded_H) at Ĥ.qx must
>>> abort the simulation of its input or Ĥ applied to ⟨Ĥ⟩ would never
>>> stop running.
>>>
>>
>> So, that doesn't say anything about what the H^ built from an H that
>> does this will do. It just proves that an H^ built from an H that
>> doesn't abort will be non-halting, but that H won't answer, so is wrong.
>>
>
>>> A simulating halt decider simulates N steps of its input until its
>>> input halts on its own or it correctly determines that a pure
>>> simulation of its input would never stop running.
>>>
>>
>> WRONG. Already proven incorrect. FAIL.
>
> You have never provided any proof all that you have ever had is dogmatic
> assertions.

Subject: Re: Concise refutation of halting problem proofs V47, REFUTED,
FAIR WARNING.
Date: Sun, 9 Jan 2022 04:55:11 +0000
Message-ID: <j8sCJ.29853$8Q7....@fx10.iad>


You have NEVER provided a proper rebuttal to this, so you have thus
conceded that you have no rebuttal to it

And thus you just LIED.

FAIL.

[olcott]

I am not going over every point of your dishonest dodge.
I state a necessary truth that cannot possisbly have any correct
rebuttal and you provide some incoherent double talk that superficially
appears to be a rebuttal to people paying less than 1% of their attention.

[Richard Damon]

No, you state a LIE, as I have proven. If what I say is untrue, then you
can point out the error, like I have to what you have said.

Your FAILURE to do so just proves that you have no basis for your
statements, and YOUR comments are the 'dishonest dodge' because YOU are
the one who refuses to engage in an honest dialog.

PERIOD.

You DON'T use the right definitions, so you aren't talking about what
you claim you are making claim abouts.

All you have done is just PROVED that your logic must be unsound.

FAIL.

[olcott]

The error is that your scatter brain couldn't even stay focused on the
point. You couldn't even pay attention to the fact that I was not
talking about Ĥ.

void P(ptr x)
{
if (H(x, y))
HERE: goto HERE;
}


When H bases its halt status decision on the behavior of the simulation
of its input then P demonstrates an infinitely repeating pattern that
cannot possibly ever reach its final state.

[wij]

This is the logical and real result. The Halt Decider cannot possibly ever
reach its final state. This is exactly the ANSWER.
If you don't agree, you have to unsay these words of yours.

[Richard Damon]

Then you aren't talking about Linz or the real Halting Problem, and are
just spreading lies that you are.

FAIL.

(By the way, read what you wrote about previously, you WERE talking
about H^, you need to keep your lies straighter).

>
> void P(ptr x)
> {
>   if (H(x, y))
>     HERE: goto HERE;
> }
>

Note, this is the first reference to P in this thread, so it is just
your attempt to divert attention from your fundamental problems.

>
> When H bases its halt status decision on the behavior of the simulation
> of its input then P demonstrates an infinitely repeating pattern that
> cannot possibly ever reach its final state.
>

Excet that P CAN'T have an infinitely repeating pattern for any H that
does abort it.

So, either you have an H that doesn't abort, and thus never answers, or
you do have an H that does abort, and gets the wrong answer.

Which way are you wrong?

Remember, H is a DEFINITE decider, not some quantum mechanics uncertain
machine.

Your logic shows H getting the right answer, but for the wrong machine,
so it doesn't actually prove anything.

Note. your H/P system has a fundamental issue when you try to convert it
to the Turing Machine H/H^ system. The method you have defined for how H
works doesn't translate to Turing Machines, because your H is entangled
with its input, so the input is NOT isolated properly. This allows you
to make your recursion test.

Define your inputs properly so that H can take ANY program as an input,
not just programs with H loaded in the same location of memory as the
deciding H has it, and you will find that you can't do what you are
trying to do.

[olcott]

I spent 2 full-time years creating the actual H that actually correctly
determines the halt status of the above P. H recognizes the essentially
infinitely recursive pattern of the behavior of P.

[olcott]

When I start a whole new thread and only talk about H and P I am not
talking about Ĥ nitwit.

[Richard Damon]

On 1/13/22 9:40 PM, olcott wrote:
> On 1/13/2022 8:27 PM, Richard Damon wrote:
>> On 1/13/22 8:52 PM, olcott wrote:
>>> On 1/13/2022 7:39 PM, Richard Damon wrote:
>>>> On 1/13/22 7:35 PM, olcott wrote:
>>>>> On 1/13/2022 6:14 PM, Richard Damon wrote:
>>>>>> On 1/13/22 7:11 PM, olcott wrote:
>>>>>>> On 1/13/2022 5:55 PM, Richard Damon wrote:
>>>>>>>> On 1/13/22 3:33 PM, olcott wrote:
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>
>>>>>>>>> It is the case that the copy of H (called embedded_H) at Ĥ.qx
>>>>>>>>> must abort the simulation of its input or Ĥ applied to ⟨Ĥ⟩
>>>>>>>>> would never stop running.
>>>>>>>>>

> When I start a whole new thread and only talk about H and P I am not
> talking about Ĥ nitwit.
>

Please read how you started THIS thread.

Care to retract your LIE?

This is your typical error.

FAIL.

Just shows how much 'truth' means to you.

[Richard Damon]

You mean you WASTED 2 full-time years, as P doesn't have an infinitely
recursive pattern for an H that aborts its simulation as this H does.

All it does is either get the right answer for the wrong problem or the
wrong answer for the proper problem.

[olcott]

I would rather talk to no one than talk to you.

[Richard Damon]

Because I tell you the truth you don't want to hear?

I HAVE proven your logic is broken, and pointed out exactly why.

You can ignore me if you want, but my response will just confirm that
you are avoiding dealing with the truth and burying yourself in your lies.

You HAVE wasted many years on your fruitless search for something that
just is not true because you can't face the prospects that you are wrong.

Sorry, but you are wrong and have shown that you really don't understand
what truth actually means.

[olcott]

Because you can't even pay attention to what is actually being said.

[Richard Damon]

That seems to be YOUR problem, isn't it.

[Alex C]

A Turing machine applied to some input reaches one final state or one infinite loop, not two different ones. This is a consequence of the definition of determinism.

[olcott]

In the case of Linz Ĥ applied to ⟨Ĥ⟩, embedded_H at Ĥ.qx correctly
transitions to its final state of Ĥ.qn on the basis that a mathematical
mapping between ⟨Ĥ⟩ ⟨Ĥ⟩ and Ĥ.qn is proven. It is proven on the basis
that the input ⟨Ĥ⟩ ⟨Ĥ⟩ specifies infinitely nested simulation to the
simulating halt decider of embedded_H.

[olcott]

On 1/13/2022 2:33 PM, olcott wrote:
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> It is the case that the copy of H (called embedded_H) at Ĥ.qx must abort
> the simulation of its input or Ĥ applied to ⟨Ĥ⟩ would never stop running.
>
> A simulating halt decider simulates N steps of its input until its input
> halts on its own or it correctly determines that a pure simulation of
> its input would never stop running.
>
> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (315-320)
>

dbush said:
@polcott There is a point of agreement, namely that you've successfully
shown that a simulating H cannot simulate the P built from it to
completion. Your confusion is that you think this is the same as
not-halting. By definition, it is not.

It must be a point of mutual agreement or it does not count as a point
of agreement.

I have successfully shown that sequences of configurations that never
reach the final state of this sequence can be recognized as meeting the
Linz definition of non-halting computations.

[Alex C]

Ĥ.q0 ⟨Ĥ⟩ ⊢* ??
is a question. A question that has only one answer. We can find the answer by passing the arguments ⟨Ĥ.q0⟩ and ⟨Ĥ⟩ to a UTM. Otherwise it is like saying:

2+2 = 4
2+2 = 5

[olcott]

> Ĥ.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ??

> is a question. A question that has only one answer. We can find the answer by passing the arguments ⟨Ĥ.q0⟩ and ⟨Ĥ⟩ to a UTM. Otherwise it is like saying:
>
> 2+2 = 4
> 2+2 = 5

That is not the question and you know it.
I can't really understand your motivation to lie.

This is the actual question: embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢*
and the answer is: Ĥ.qn.

[olcott]

There can only be a conditional branch at the point in the execution
trace where there is conditional code. The point in the execution trace
that you pointed to was an unconditional branch.

[olcott]

On 1/13/2022 2:33 PM, olcott wrote:

> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> It is the case that the copy of H (called embedded_H) at Ĥ.qx must abort
> the simulation of its input or Ĥ applied to ⟨Ĥ⟩ would never stop running.
>
> A simulating halt decider simulates N steps of its input until its input
> halts on its own or it correctly determines that a pure simulation of
> its input would never stop running.
>
> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (315-320)
>

@polcott There is a point of agreement, namely that you've successfully
shown that a simulating H cannot simulate the P built from it to
completion. Your confusion is that you think this is the same as

not-halting. By definition, it is not. – dbush

Proof that my reviewers are not interested in an honest dialogue:
(1) There are never any points of mutual agreement.
(2) Whenever I prove my point reviewers always change the subject rather
than acknowledge that I proved my point.

A simulating halt decider continues to simulate N steps of its input
input until (a) The simulation ends on its own after reaching the final
state specified by the input. (b) An infinite execution pattern has been
recognized.

It is ridiculously stupid to claim that the simulating halt decider
fails on the basis that it cannot simulate an input that specifies
infinite execution to completion.

H cannot simulate P to completion because P has no completion. All the
HP counter-example instance specify infinitely nested simulation to
every simulating halt decider.

[olcott]

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

Because no finite number of N steps of the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by
embedded_H ever reach a final state of Ĥ, embedded_H correctly
determines that its input meets the Linz definition of a computation
that does not halt. At this point embedded_H aborts the simulation of
its input and correctly transitions to Ĥ.qn.

[Alex C]

if that is the question then why did you post the nonsense about Ĥ.q0 ⟨Ĥ⟩

[olcott]

If you are user253751 then you already know the full background.
Otherwise you need to study the 6 pages of Linz text on this link:
https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf

This is a simplification of the Linz syntax at the bottom of page 319

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The copy of Linz H that is embedded at Ĥ.qx is called embedded_H.

[olcott]

If you are user253751 then you already know the full background.
Otherwise you need to study the 6 pages of Linz text on this link:
https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf

This is a simplification of the Linz syntax at the bottom of page 319

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The copy of Linz H that is embedded at Ĥ.qx is called embedded_H.

[Richard Damon]

On 1/14/22 12:17 PM, olcott wrote:
> On 1/13/2022 2:33 PM, olcott wrote:
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> It is the case that the copy of H (called embedded_H) at Ĥ.qx must
>> abort the simulation of its input or Ĥ applied to ⟨Ĥ⟩ would never stop
>> running.
>>
>> A simulating halt decider simulates N steps of its input until its
>> input halts on its own or it correctly determines that a pure
>> simulation of its input would never stop running.
>>
>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>> Lexington/Toronto: D. C. Heath and Company. (315-320)
>>
>
> dbush said:
> @polcott There is a point of agreement, namely that you've successfully
> shown that a simulating H cannot simulate the P built from it to
> completion. Your confusion is that you think this is the same as
> not-halting. By definition, it is not.
>
> It must be a point of mutual agreement or it does not count as a point
> of agreement.
>
> I have successfully shown that sequences of configurations that never
> reach the final state of this sequence can be recognized as meeting the
> Linz definition of non-halting computations.
>
>

No, you have shown that the PARTIAL simulation by H never reaches the
final state of H^. That is NOT the definition of Halting.

You haven't proven that the UNCONDITIONAL simulation of H^ by a UTM
won't reach the terminal state, and in fact, it is proven that if H ->
H.Qn then H^ -> H^.Qn and Halts.

Thus, any H^ x for which H x x -> H.Qn is a Halting computation, which
includes the case of x being the description of H^, which is the problem
in question.

FAIL.

[Keith Thompson]

olcott <No...@NoWhere.com> writes:
[...]

> If you are user253751 then you already know the full background.
> Otherwise you need to study the 6 pages of Linz text on this link:
> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf

I see that you've posted a link to this PDF repeatedly. I hadn't
bothered to follow the link until now.

The PDF is a copy of chapter 12 of Peter Linz's book "An Introduction to
Formal Languages and Automata". The latest edition was published in
2016.

Is liarparadox.org your web site? If so, do you have permission from
the author or publisher to publish an entire chapter of Peter Linz's
book? In a few minutes of web searching, I've found no indication that
either Peter Linz or Jones & Bartlett Learning has made this book freely
available. (I seriously doubt that posting an entire chapter would
qualify as fair use.)

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[Richard Damon]

On 1/14/22 4:40 PM, olcott wrote:
> On 1/13/2022 2:33 PM, olcott wrote:
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> It is the case that the copy of H (called embedded_H) at Ĥ.qx must
>> abort the simulation of its input or Ĥ applied to ⟨Ĥ⟩ would never stop
>> running.
>>
>> A simulating halt decider simulates N steps of its input until its
>> input halts on its own or it correctly determines that a pure
>> simulation of its input would never stop running.
>>
>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>> Lexington/Toronto: D. C. Heath and Company. (315-320)
>>
>
> @polcott There is a point of agreement, namely that you've successfully
> shown that a simulating H cannot simulate the P built from it to
> completion. Your confusion is that you think this is the same as
> not-halting. By definition, it is not. – dbush
>
> Proof that my reviewers are not interested in an honest dialogue:
> (1) There are never any points of mutual agreement.
> (2) Whenever I prove my point reviewers always change the subject rather
> than acknowledge that I proved my point.

We agree that you have proven *A* point, just not the one you claim.

What you have proven is that NO H can PROVE that the H^ derived from it
is Halting, because there exists no H by your formula that can reach
that point.

This does NOT prove that any given instance of a H/H^ creates a
non-halting H^ machine.

>
> A simulating halt decider continues to simulate N steps of its input
> input until (a) The simulation ends on its own after reaching the final
> state specified by the input. (b) An infinite execution pattern has been
> recognized.

No, it hasn't as have been previously proven.

The decider you just described is proved to never halt and give a
decision and thus is wrong.

FAIL.

>
> It is ridiculously stupid to claim that the simulating halt decider
> fails on the basis that it cannot simulate an input that specifies
> infinite execution to completion.

WHY? The problem is that you haven't actually defined what your H is,
but just assume that you can do the impossible job.

Once you give H any pattern that it sees in its simulation of H^, then
the H^ you build from THAT H can be shown to Halt, and thus the pattern
was incorrect.

It isn't that strange an idea that you can build a Turing Machine that
uses a copy of the decider (that needs to exist first) to make that
decider wrong.

H ends up stuck between having to make a decision, and a machine that
knows what decision it will make and act the opposite.

Try playing Rock-Paper-Scissor with someone where you have to put out
your move first, then they get to act. This is the place that H is in,
since H has to exist first. H^ just declares its template, it will
choose what ever answer will make H wrong.

>
> H cannot simulate P to completion because P has no completion. All the
> HP counter-example instance specify infinitely nested simulation to
> every simulating halt decider.
>

WRONG. The problem is there is no H in the first place to simulate P,
and thus there is no P to simulate.

Once you actually create a specific H, then we can see that the H^/P
created from it will be able to foil that H.

You arguement fails to actually create an H with an actual defined
algorithm to run.

[Richard Damon]

But since a given H will only simulate H^ for N steps, then the fact
that H didn't see the final state of H^ in that N steps doesn't say that
it can't reach it in some larger value K.

The DEFINITION of Halting is that it will eventually get there is SOME
finite number (not a specific finite number), and if it does in a K
greater than N doesn't mean that it didn't. And if you change your H to
run longer to try to catch that K, you changed H and thus H^ and the new
H^ will have a larger K.

The fact that H^ depends on H means that it can easily be the case that
for a given H/H^ pair, the K steps that H^ stops in is ALWAYS greater
than the N that H simulated for, so all you have shown is that there is
no N such that N > K(N) not that for any particular N there does not
exist a finite K.

You have failed to prove anything at all like what you need to prove.

[Richard Damon]

H may compute a mapping of H^ applied to <H^> mapping to H.Qn, but that
is NOT the Halting Function, since we KNOW that if H x x -> H.Qn that we
also have that H^ x -> H^.Qn and HALTS, so H^ applied to <H^> goes to
H^.Qn (since you have claimed that H <H^> <H^> goes to H.Qn) and thus Halts.

Thus H does NOT compute the Halting Function, but something else.

All you have proved is that for Hn^ based on Hn that doesn't abort its
simulation that Hn^ <Hn^> doesn't halt, but it is only Ha that gives
that answer, and we don't care if Ha <Hn^> <Hn^> gets the right answer,
you need Ha to get the right answer for Ha <Ha^> <Ha^> which it doesn't
as we just showed that Ha^ <Ha^> halts, becuase Ha went to Ha.Qn

FAIL

[Richard Damon]

Except it isn't

The DEFINITION of a correct H was

H <X> y -> H.Qn iff X y did not halt. (and to H.Qy if it does)

But we have that H^ y will go to H^.Qn and Halt if H y y -> H.Qn

Since this is just the case where y = <H^> we have that

H <H^> <H^> should go to H.Qn only if H^ <H^> will not halt, but we just
showed that if H <H^> <H^> goes to H.Qn then H^ <H^> will also go to
H^.Qn and Halt, so H didn't meet its requirements.

FAIL.

[Richard Damon]

??? The ⊢* better have a condition branch in it as it goes to two
different later states based on some condition.

It THAT you problem?

[olcott]

On 1/14/2022 8:08 PM, Keith Thompson wrote:
> olcott <No...@NoWhere.com> writes:
> [...]
>> If you are user253751 then you already know the full background.
>> Otherwise you need to study the 6 pages of Linz text on this link:
>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>
> I see that you've posted a link to this PDF repeatedly. I hadn't
> bothered to follow the link until now.
>
> The PDF is a copy of chapter 12 of Peter Linz's book "An Introduction to
> Formal Languages and Automata". The latest edition was published in
> 2016.
>
> Is liarparadox.org your web site? If so, do you have permission from
> the author or publisher to publish an entire chapter of Peter Linz's
> book? In a few minutes of web searching, I've found no indication that
> either Peter Linz or Jones & Bartlett Learning has made this book freely
> available. (I seriously doubt that posting an entire chapter would
> qualify as fair use.)
>

Chapter 12 is 28 pages long.
Since I am refuting his proof this justifies fair use.
The first 2.5 pages specifies the terminology that applies to
the proof.

[olcott]

The actual correct definition is embedded_H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn
based on the actual behavior specified by its input: ⟨Ĥ⟩ ⟨Ĥ⟩.

Do you understand that this is correct, or do you not know computer
science well enough to understand that this is correct?

> But we have that H^ y will go to H^.Qn and Halt if H y y -> H.Qn
>
> Since this is just the case where y = <H^> we have that
>
> H <H^> <H^> should go to H.Qn only if H^ <H^> will not halt, but we just
> showed that if H <H^> <H^> goes to H.Qn then H^ <H^> will also go to
> H^.Qn and Halt, so H didn't meet its requirements.
>
> FAIL.

[Richard Damon]

Right, AS DETERMINED BY UTM(<H^>,<H^>) which is the same as H^ applied
to <H^> (BY DEFINITION) which goes to H^.Qn and Halts if the copy of H
in it goes to H.Qn, which it does if H mapped <H^> <H^> to H.Qn which
you claim, so the behavior specified by the input is HALTING.

THUS if H maps <H^> <H^> to H.Qn, then by its definition it SHOULD have
mapped it to H.Qy, so it was WRONG.

[olcott]

I won't count that as wrong because the part that you got wrong was
outside the scope of the original question.

You 100% agree with this:

The actual correct definition is embedded_H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or
Ĥ.qn based on the actual behavior specified by its input: ⟨Ĥ⟩ ⟨Ĥ⟩.

The next step after we agree on that point is:
How we measure the actual behavior of the input to embedded_H: ⟨Ĥ⟩ ⟨Ĥ⟩ ?

> THUS if H maps <H^> <H^> to H.Qn, then by its definition it SHOULD have
> mapped it to H.Qy, so it was WRONG.
>
>>
>>> But we have that H^ y will go to H^.Qn and Halt if H y y -> H.Qn
>>>
>>> Since this is just the case where y = <H^> we have that
>>>
>>> H <H^> <H^> should go to H.Qn only if H^ <H^> will not halt, but we
>>> just showed that if H <H^> <H^> goes to H.Qn then H^ <H^> will also
>>> go to H^.Qn and Halt, so H didn't meet its requirements.
>>>
>>> FAIL.
>>
>>
>

[Richard Damon]

From the definition of the problem: it is defined as the behavior of H^
applied to <H^> or its equivalent of UTM(<H^>,<H^>) and nothing else.


Remember H <X> y -> H.Qy IFF X y Halts, and -> H.Qn IFF X y never Halts.

THAT IS THE DEFINITION.

By the definition of a UTM, this is the equivalent to:

H x y -> H.Qy IFF UTM(x,y) Halts and -> H.Qn IFF UTM(x,y) never Halts.

Note, by the construction of H^, if H x x -> H.Qn then H^ x -> H^.Qn and
Halts.

Thus IFF H <H^> <H^> gives your claimed correct answer of H.Qn then by
the construction of H^ we have that H^ <H^> will also go to H^.Qn and Halt.

Thus H <H^> <H^> -> H.Qn is incorrect, as we just showed that its input
will Halt if H behaves as you just claimed.

So either H gave the answer Qn and was wrong, or the answer was Qn but H
didn't give it. Either way H is wrong.

FAIL.

[olcott]

Ah so you don't understand enough computer science to know that every
decider implements a computable function that maps its input(s) to an
accept reject state.

Unless you understand this we cannot proceed. It makes sense that I
apply this same threshold of understanding to all of my reviewers.

[Richard Damon]

No, I understand that perfectly, H needs to compute a mapping from its
inputs, but the definition of the mapping, in this case is the Halting
Function, which it turns out is NOT directly computatable from the inputs.

THAT IS THE WHOLE ISSUE.

If you are saying that it is impossible for H to compute the mapping
based on this definition, then you are just agreeing with Linz and
Turing and everyone else that the Halting Function is NOT computable.

So, what is the issue?

Either you are agreeing that the Halting Function is not computable, or
you are going to show everyone up by showing how you can actually
compute this function as it is defined, which means you don't get to
change the definition based on the fact that it isn't computable.

I think the issue really is that you don't really understand the
question you are trying to disprove the answer to.

[olcott]

Because you tend to weasel word all over the place and have your
rebuttal ignore what I am currently saying and instead refer to
something that I said 50 posts ago let's be perfectly clear:

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The copy of H at Ĥ.qx referred to as embedded_H must compute the
mapping of its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn

> THAT IS THE WHOLE ISSUE.
>
> If you are saying that it is impossible for H to compute the mapping
> based on this definition, then you are just agreeing with Linz and
> Turing and everyone else that the Halting Function is NOT computable.
>
> So, what is the issue?
>
> Either you are agreeing that the Halting Function is not computable, or
> you are going to show everyone up by showing how you can actually
> compute this function as it is defined, which means you don't get to
> change the definition based on the fact that it isn't computable.
>
> I think the issue really is that you don't really understand the
> question you are trying to disprove the answer to.

[Richard Damon]

So, no answer?

The FULL statement from Linz, INCLUDING the requirements which you drop
is that, we can derive the following requirements on Ĥ based on the
actual requirements on H.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ IFF Ĥ (Ĥ) Halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn IFF Ĥ (Ĥ) Never Halts

This is from the definition of a Halting Decider that

H wM w ⊢* H.Qy IFF M w Halts
H wM w ⊢* H.Qn IFF M w Does Not Halt.

Note, the requirements on H are EXACTLY the requirements I use that show
your answer is incorrect, and the requirements on the lines you like to
partially quote (partial because you leave off the derived requirements)
show that if H was correct then Ĥ (Ĥ) needs to Halt if it runs forever
or run forever if it Halts.

The clear impossibility of this pointing out that such an Ĥ can't exist
which imply that the H that meets its requirements can not exist.

YOU are the one who fills there discussion with 'weasel words',
fabrications, bad definitions and outright lies to try to put forward a
smoke screen to support your unsound argument.

YOU never answer a rebuttal, because you don't have any grounds to
actually base such an answer.

YOU are the one that needs to tightly control the direction of the
conversation, and not allow looking at it from other angles, because you
don't have enough smoke to hide all the problems, and other views show
the fraud for what it is.

It is NOT the case that you really need to build up your arguement in a
precise order for it to be understandable, it is that you have a narrow
path that you have figured out miss-information to cover the errors in
your logic, and you don't know how to handle any other paths, and you
need to keep the discussion away from the points that flat out show you
are wrong, like the definition of what Halting actually means and the
requirements of a Halting Decider.

You can NOT get around the fundamental fact that Ĥ will halt if H
answers H.Qn and thus makes H wrong.

FAIL.

[olcott]

I am asking whether or not you agree with the above,
Linz says it in a less precise way that can be misinterpreted.

Unless and until you understand enough computer science to
know that the way that I said it is correct we cannot proceed.

DO YOU PERFECTLY AGREE THAT THIS IS 100% CORRECT?

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The copy of H at Ĥ.qx referred to as embedded_H must compute the
mapping of its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn

[Richard Damon]

That is a NONSENSE statement without the conditions on it.

>
> The copy of H at Ĥ.qx  referred to as embedded_H must compute the
> mapping of its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn

Right.

AND the input <H^> <H^> is a description of the whole computation being
preformed.

Note, this puts H in a bind, if its algorithm decides that this input
should take it to the Qn state, then the actual behavior of the
computatiion this input represents will be HALTING (since it ends up at
H^.qn which halts), and similarly if it decides to go to Qy, then the
computation will be non-halting.

[olcott]

There is no H, there is only a copy of H at Ĥ.qx that is referred to as
embedded_H.

> if its algorithm decides that this input
> should take it to the Qn state, then the actual behavior of the
> computatiion this input represents will be HALTING

There is no "represents", there is only the actual behavior specified by
the actual input to embedded_H: ⟨Ĥ⟩ ⟨Ĥ⟩.

embedded_H computes the mapping from its input: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.

The actual behavior of this actual input is measured by the pure
simulation of N steps by embedded_H of its input ⟨Ĥ⟩ applied to ⟨Ĥ⟩.

[Richard Damon]

And you are wrong there. The HAD to be an H first to build H^ from.


H is the decider that you want to make the CLAIM to be a correct Halting
Decider.

If you are willing to stipulate that there is no such machine, fine,
that mean you concede the question.

You seem to have forgotten what you are trying to do.

You DO underestand that you can have more than 1 Turing Machine in
existence at a time, they all run independently, but more than one do exist.

>
>>  if its algorithm decides that this input should take it to the Qn
>> state, then the actual behavior of the computatiion this input
>> represents will be HALTING
>
> There is no "represents", there is only the actual behavior specified by
> the actual input to embedded_H: ⟨Ĥ⟩ ⟨Ĥ⟩.

And what 'behavior' does a string of symbol have?

How did we get that string of symbols?

>
> embedded_H computes the mapping from its input: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>
> The actual behavior of this actual input is measured by the pure
> simulation of N steps by embedded_H of its input ⟨Ĥ⟩ applied to ⟨Ĥ⟩.
>

No, if anything the actual behavior of this input is measured by the
ACTUAL pure simulation of that input but a REAL UTM until it either
halts or NEVER halts.

You are forgetting the problem you are trying to solve and have gone off
into mental Unicorn land.

FAIL.

[olcott]

I wanted to make it clear that the subject of the discussion is not H
applied to ⟨Ĥ⟩ ⟨Ĥ⟩. The subject of the discussion is embedded_H applied
to ⟨Ĥ⟩ ⟨Ĥ⟩.

It seems that you apply great skill and creativity to make sure that you
always refer to things that are not being discussed.

> If you are willing to stipulate that there is no such machine, fine,
> that mean you concede the question.
>
> You seem to have forgotten what you are trying to do.
>
> You DO underestand that you can have more than 1 Turing Machine in
> existence at a time, they all run independently, but more than one do
> exist.
>
>>
>>>  if its algorithm decides that this input should take it to the Qn
>>> state, then the actual behavior of the computatiion this input
>>> represents will be HALTING
>>
>> There is no "represents", there is only the actual behavior specified by
>> the actual input to embedded_H: ⟨Ĥ⟩ ⟨Ĥ⟩.
>
>
> And what 'behavior' does a string of symbol have?
>
> How did we get that string of symbols?
>

The behavior specified by a string of symbols is the actual behavior of
the simulation of this string of symbols.

>>
>> embedded_H computes the mapping from its input: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>
>> The actual behavior of this actual input is measured by the pure
>> simulation of N steps by embedded_H of its input ⟨Ĥ⟩ applied to ⟨Ĥ⟩.
>>
>
> No, if anything the actual behavior of this input is measured by the
> ACTUAL pure simulation of that input but a REAL UTM until it either
> halts or NEVER halts.
>

No one is stupid enough to believe that a halt decider must wait an
infinite amount of time for an infinite loop to stop running.

Some people are smart enough to understand that infinite loops, infinite
recursion and infinitely nested simulation demonstrate infinite behavior
patterns that can be recognized in a finite number of steps.

> You are forgetting the problem you are trying to solve and have gone off
> into mental Unicorn land.
>
> FAIL.
>

[Richard Damon]

And the behavior for the Halting Problem would be that simulation by a
REAL UTM, not some 'partial' simulator.

Remember are claiming to work on an established problem, so you need to
use the established definitions.

>
>>>
>>> embedded_H computes the mapping from its input: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>
>>> The actual behavior of this actual input is measured by the pure
>>> simulation of N steps by embedded_H of its input ⟨Ĥ⟩ applied to ⟨Ĥ⟩.
>>>
>>
>> No, if anything the actual behavior of this input is measured by the
>> ACTUAL pure simulation of that input but a REAL UTM until it either
>> halts or NEVER halts.
>>
>
> No one is stupid enough to believe that a halt decider must wait an
> infinite amount of time for an infinite loop to stop running.

No one says the halt decider needs to compute its answer that way, this
is the difference between the IMPLEMENTATION done by the Halt Decider,
and the REQUIREMENTS specified for it.

H CAN'T wait forever to get its answer, it needs to answer in finite time.

The DEFINITION of the Halting Function is based on something that at
least naively, can take an infinite time. The key is that to claim that
this is actually 'computable' means that you are claiming that this
apparently infinite time operation can be done in finite time.

Remember, the Halting Problem STARTED with a 'Function' also known as a
mapping of machines and inputs to a Halting or Non-Halting property.

So Halting is a mapping of (M,w) -> {Halting, Non-Halting} based on the
condition that (M,w) -> Halting iff M applied to w will Halt in a finite
number of steps, and (M, w) -> Non-Halting if M applied to w will NEVER
halt.

The claim is that there exists no Turing Machine H, that can take as an
input a representation of this 'input' to the Halting Function, and
computate the answer.

That machine, if it existed, would have the following specification:

H wM w -> H.Qy if M w will Halt, and -> H.Qn if M w will never halt.

Given this specification, Turing (and Linz) have shown that it is
possible to create a machine H^ that uses this H, and that H can never
give the right answer to.

If you want to try to disprove this, you need to actually show that you
can do it. Yes, H CAN'T just wait forever to get the answer, and that is
the problem. You make lots of 'claims' about what you can do, but all
these claims contain Unicorns, a claim that you can do something that is
impossible, and you NEVER actually show how you claim to do it.

You arguements just FAIL.

>
> Some people are smart enough to understand that infinite loops, infinite
> recursion and infinitely nested simulation demonstrate infinite behavior
> patterns that can be recognized in a finite number of steps.

Proven incorrect.

Mesage ID <FOnzJ.162569$np6.1...@fx46.iad>
Date: 2021-12-30 19:31:49 GMT
Subject: Re: Concise refutation of halting problem proofs V42 [compute
the mapping]


It is well established that there is no finite exhaustive enumeration of
non-halting behavior.

[olcott]

In the case where there is no existing terminology for ideas that I must
convey Sapir–Whorf would prevent expressing these ideas.

There is no existing term that even roughly approximates the concept of
a {simulating halt decider} so I must construct the meaning of this term
from scratch.

>>
>>>>
>>>> embedded_H computes the mapping from its input: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or
>>>> Ĥ.qn.
>>>>
>>>> The actual behavior of this actual input is measured by the pure
>>>> simulation of N steps by embedded_H of its input ⟨Ĥ⟩ applied to ⟨Ĥ⟩.
>>>>
>>>
>>> No, if anything the actual behavior of this input is measured by the
>>> ACTUAL pure simulation of that input but a REAL UTM until it either
>>> halts or NEVER halts.
>>>
>>
>> No one is stupid enough to believe that a halt decider must wait an
>> infinite amount of time for an infinite loop to stop running.
>
> No one says the halt decider needs to compute its answer that way, this
> is the difference between the IMPLEMENTATION done by the Halt Decider,
> and the REQUIREMENTS specified for it.
>
> H CAN'T wait forever to get its answer, it needs to answer in finite time.
>
> The DEFINITION of the Halting Function is based on something that at
> least naively, can take an infinite time. The key is that to claim that
> this is actually 'computable' means that you are claiming that this
> apparently infinite time operation can be done in finite time.
>
> Remember, the Halting Problem STARTED with a 'Function' also known as a
> mapping of machines and inputs to a Halting or Non-Halting property.
>

No this is flatly incorrect. It has never been a mapping of machines and
inputs. It has always been a mapping of machine descriptions and inputs.

> So Halting is a mapping of (M,w) -> {Halting, Non-Halting} based on the
> condition that (M,w) -> Halting iff M applied to w will Halt in a finite
> number of steps, and (M, w) -> Non-Halting if M applied to w will NEVER
> halt.
>

embedded_H must compute the mapping from its input ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.

Because there is no N number of steps that embedded_H can simply wait
for ⟨Ĥ⟩ applied to ⟨Ĥ⟩ to stop running (even if this requires 100,000
recursive invocations of other copies of ⟨Ĥ⟩ applied to ⟨Ĥ⟩) embedded_H
is necessarily correct to abort the simulation of its input.

We have been over this point so many times that it seems that this point
is simply beyond your intellectual capacity.

THIS IS TRUE WHETHER OR NOT YOU HAVE THE CAPACITY TO UNDERSTAND IT:
When-so-ever in any-and-all cases where some recursive instance of a
simulating halt decider H must abort its simulation of its input to
prevent the otherwise infinite simulation of this input then it is
always correct for H to abort the simulation of its input and report
that this input specifies a non-halting computation.

>>
>>> You are forgetting the problem you are trying to solve and have gone
>>> off into mental Unicorn land.
>>>
>>> FAIL.
>>>
>>
>>
>

[Richard Damon]

The HALTING FUNCTION has ALWAYS been a mapping of TURING/MACH(INES +
INPUT to Halting/Non-Halting.

That is why the specification for H (the part after the iff) look at M
applied to w and not about wM.

We don't get descriptions until we talk about attempting to make it a
computable function, which means we need to find a mapping of the
descriptions that matches the original mapping.

Given, M and w, create the wM and w to give to H to try to get the same
mapping of (wM,w) as we have from (M,w).

The key is we know that for any M we can create a wM that is a
description of it suitable for processing by a Turing Machine.

>
>> So Halting is a mapping of (M,w) -> {Halting, Non-Halting} based on
>> the condition that (M,w) -> Halting iff M applied to w will Halt in a
>> finite number of steps, and (M, w) -> Non-Halting if M applied to w
>> will NEVER halt.
>>
>
> embedded_H must compute the mapping from its input ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.

Yes, it needs to compute a mappig from its input to its output, but the
mapping must be CORRECT for it to be acceptable.

If the mapping that H computes doesn't match the Halting Function then
it hasn't shown that Halting was computable.

GARBAGE.

Given H, there is only 1 N that exists, as that H will simulate only a
given amount and then incorrect abort its simulation (or just fail to
abort and not answer).

If you change your H to change that value, you have changed H^, so you
previous work was invalidated.

> We have been over this point so many times that it seems that this point
> is simply beyond your intellectual capacity.
>
> THIS IS TRUE WHETHER OR NOT YOU HAVE THE CAPACITY TO UNDERSTAND IT:
> When-so-ever in any-and-all cases where some recursive instance of a
> simulating halt decider H must abort its simulation of its input to
> prevent the otherwise infinite simulation of this input then it is
> always correct for H to abort the simulation of its input and report
> that this input specifies a non-halting computation.

THAT IS NOT THE DEFINITION.

THAT IS JUST A STATEMENT OF YOUR POOP

IT IS A BLATANT LIE TO SAY IT APPLIED TO THE DEFINITION OF HALTING.

If you want to burn in HELL over this, go ahead, you have read the TRUTH
of the definition of Halting, and you chose to not accept it but claim
something false.

The ONLY definition of halting that is correct, is the actual behavior
of the machine that is being asked about, not what some decider does or
doesn't do in its processing.

Remember, to even ask the question about H^ <H^> we need H^ to exist,
and that requires that H must first exist and be fully defined.

Once H is defined, then there is no 'whether or not' term in play, H
will either abort its simulation, and return the INCORRECT Non-Halting
ansswer, incorrect because since it does this, H^ will use that exact
same answer to cause itself to Halt, thus making H wrong, or H will
NEVER abort its simulation, and then fail to return an answer to the
question, and thus be wrong.

Yes, in that second case Non-Halting WOULD have been the right answer,
but only BECAUSE H never gave it.

FAIL.

[olcott]

You are far too ignorant for me to waste any more time on.
I won't even bother to document your error. I will just
stop talking to you.

[Richard Damon]

You mean, you can't find a way to counter what I say, because you just
don't understand what you are talking about.

YOU are the one making the absurd claim to do the impossible.

If you could do it, it would be trivial to prove, just publish your code
that does what you claim.

The simple fact that you don't proves that you haven't been able to do
the thing you claim you have already done.

It doesn't take a lot of explanation to show that the code does work, if
it does.

The problem is that it takes a LOT of BULLSHIT to try to explain why
what you have is 'close' to working and should be treated as good
enough, even though it isn't, because the task is still clearly impossible.

FAIL.