Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩

On 5/27/24 11:06 AM, olcott wrote:

On 5/27/2024 9:48 AM, Richard Damon wrote:

On 5/27/24 10:25 AM, olcott wrote:

On 5/27/2024 8:27 AM, Richard Damon wrote:

On 5/26/24 11:47 PM, olcott wrote:

On 5/26/2024 10:30 PM, Richard Damon wrote:

On 5/26/24 11:17 PM, olcott wrote:

On 5/26/2024 10:05 PM, Richard Damon wrote:

On 5/26/24 10:43 PM, olcott wrote:

On 5/26/2024 9:06 PM, olcott wrote:

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
  Ĥ copies its own Turing machine description: ⟨Ĥ⟩
  then invokes embedded_H that simulates ⟨Ĥ⟩ with ⟨Ĥ⟩ as input.
>
It is an easily verified fact that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
embedded_H cannot possibly reach its own simulated final state of
⟨Ĥ.qn⟩ in any finite sequence of steps.

>
*To other reviewers that are not dishonest*
The complete proof of the above statement is that when we hypothesize
that embedded_H is a UTM we can see that:

>
i.e. when we assume it is something it isn't, i.e we LIE to ourselves.
>
If you assume embedded_H is something it isn't,

>
Not at all.
*It looks like you may be utterly clueless about what-if scenarios*

You can only ask what-ifs about things that are possible.
>

>
What-if embedded_H was a UTM would ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated
by embedded_H reach its own simulated final state of ⟨Ĥ.qn⟩ ?
(a) YES
(b) NO
(c) DISHONEST HONEST ATTEMPT TO CHANGE THE SUBJECT

>
So, If your H was a UTM, and H^ built on that, then embedded_H would be a UTM and H^ (H^) would be non-halting as would H (H^) (H^).
>

>
*Great this is a step of progress*
This conclusively proves that ⟨Ĥ⟩ will not reach ⟨Ĥ.qn⟩ is less than
an infinite number of steps. A decider is not allowed to simulate
an infinite number of steps.

>
First, it doesn't "Prove" it,

>
*Sure it does, you just like to deny verified facts*

>
Nope, someone saying something doesn't prove it to be true.
>

 Because I am a relatively terrible communicator my words need constant
improvement. *These words here are the clearest ones yet*
 typedef int (*ptr)();  // ptr is pointer to int function in C
00       int H(ptr p, ptr i);
01       int D(ptr p)
02       {
03         int Halt_Status = H(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         H(D,D);
12         return 0;
13       }
 The above template refers to an infinite set of H/D pairs where D is
correctly simulated by pure function H. This was done because many
reviewers used the shell game ploy to endlessly switch which H/D pair
was being referred to.
 *Correct Simulation Defined*
    This is provided because many reviewers had a different notion of
    correct simulation that diverges from this notion.
     A simulator is an x86 emulator that correctly emulates 1 to N of the
    x86 instructions of D in the order specified by the x86 instructions
    of D. This may include M recursive emulations of H emulating itself
    emulating D.
 When we see that D correctly simulated by pure simulator H would remain
stuck in infinite recursive simulation then we also know that less than
an infinite number of steps is not enough steps for D correctly
simulated by pure function H to reach its own simulated final state at
line 06 and halt.

But the D that was non-halting was a DIFFERENT D then the one simulated by the finite stepping simulator, so the answers don't apply.
IF you want to try to define all the diffferent Ds as just one D template, you need to DEFINE how any of those terms apply to "a template" that has differing behaviors. What does it mean to simulate the x86 instructions of a "Template", when simulation is DEFINED as simulating into the H that is a variable.
Your system is just isn't based on defined logic.

 I must continue to improve the clarity of words to the point
that *INTENTIONAL MISINTERPRETATION* looks utterly ridiculous.
 *The dishonest dodge strawman deception CHANGE-THE-SUBJECT*
*fake rebuttal already looks utterly ridiculous*
 

And, because your program above is not properly related to the Halting Problem, NOTHING you say about it means anything to the halting problem.
In fact, because your "input" isn't actually a Program, but a template, you need to figure out how to define that the terms you use about it.
You can't simulate "A Template" as the template represents an infinite set of programs, that WILL have differing steps along their exectution, so there is no one correct simulation of it.
If you try to talk about it becoming a specific program for each H, then there programs are DIFFERENT for each H, and thus you can not conclude anything about one input from the behavior of another.
So, it truth, you are just showing that you have made a collossal mess that you can't actually define what it means. This is why you are so bad at communicating your ideas, because they are not based on any actual truths, but inconsistent ideas that just don't work together.