XPost: comp.theory, sci.logic, sci.math

On 12/31/2021 3:30 PM, Richard Damon wrote:

On 12/31/21 3:59 PM, olcott wrote:

On 12/31/2021 2:51 PM, Richard Damon wrote:

On 12/31/21 3:08 PM, olcott wrote:

On 12/31/2021 1:55 PM, Richard Damon wrote:

On 12/31/21 2:46 PM, olcott wrote:

On 12/31/2021 1:25 PM, Richard Damon wrote:

On 12/31/21 2:09 PM, olcott wrote:

On 12/31/2021 12:52 PM, Richard Damon wrote:

On 12/31/21 12:57 PM, olcott wrote:

On 12/31/2021 11:19 AM, olcott wrote:

On 12/31/2021 11:01 AM, Richard Damon wrote:

On 12/31/21 11:31 AM, olcott wrote:

On 12/31/2021 10:28 AM, Steve Parker wrote:

On 12/31/2021 8:27 AM, olcott wrote:

Proving that embedded_H at Ĥ.qx correctly maps its inputs >>>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn on the basis of the behavior of the UTM
simulation of these inputs.

Shut up idiot.

If you can't point to any mistakes that proves that you are >>>>>>>>>>>>> the idiot

How about that it can be simple shown by inspection that if >>>>>>>>>>>> H and embedded_H applied to <H^> <H^> goes to H.qn, then so >>>>>>>>>>>> does H^ applied to <H^> go to H^.qn and Halts, thus H was >>>>>>>>>>>> WRONG.

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

embedded_H at Ĥ.qx is only accountable for mapping its input >>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn on the basis that a pure simulation
of this input
(no embedded_H ever aborts the simulation of its input).

No embedded_H ever aborts the simulation of its input until: >>>>>>>>>> (a) Its input halts on its own.
(b) It detects that its input would never halt on its own. >>>>>>>>>>

Proven impossible for such an algorithm to decide H^ is
non-halting:

If is self-evidently true that unless simulating halt decider
embedded_H aborts the simulation of its input at some point that >>>>>>>> Ĥ applied to ⟨Ĥ⟩ never stops running.

That you have never agreed to this proves that you are dishonest. >>>>>>>>

And YOU don't understand that no ALGORITHM can detect this.

Thus, YES, if your H that doesn't abort its simulation until IT
can correctly prove the computation is non-halting, H^ will be
Non-Halting and that would be the correct answer, but H can not
compute that answer, and will be non-halting itself.

Well that is a breakthrough.

The correct halt status for embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is Ĥ.qn
even if embedded_H cannot compute this correct halt status.

Prior to this breakthrough both Ĥ.qy and Ĥ.qn were the wrong answer. >>>>>>

Right, the correct answer is Non-Halting but NEITHER H or
embedded_H can give it, because if they do, it becomes the wrong
answer.

When embedded_H is basing its halt status decision on the behavior
pure simulation of its input then because the pure simulation of its
input would never stop running when embedded_H transitions to Ĥ.qn
it is necessarily correct because it is still true that the pure
simulation of its input would never stop running.

So if H IS a pure simulator, the correct answer is Non-Halting, but a
pure simulator will never abort itself to give that. H FAILS.

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

The fact that the input to embedded_H never reaches its final state
whether or not its simulation is ever aborted conclusively proves that
this input never halts therefore when embedded_H transitions to Ĥ.qn
it is necessarily correct.

WRONG, because the ACTUAL Turing Machine that is represented in the
input WILL reach its final state,

This is why I need an actual computer scientist to review my work.

An actual computer scientist will understand that embedded_H does
compute the mapping from these inputs finite strings ⟨Ĥ⟩ ⟨Ĥ⟩ to this final state Ĥ.qn on the basis that the actual input would never halt.


--
Copyright 2021 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)