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

On 5/27/24 8:26 PM, olcott wrote:

On 5/27/2024 7:17 PM, Richard Damon wrote:

On 5/27/24 8:08 PM, olcott wrote:

On 5/27/2024 5:44 PM, Richard Damon wrote:

On 5/27/24 6:32 PM, olcott wrote:

On 5/27/2024 4:21 PM, Richard Damon wrote:

On 5/27/24 3:45 PM, olcott wrote:

On 5/27/2024 11:33 AM, Richard Damon wrote:

On 5/27/24 12:22 PM, olcott wrote:

On 5/27/2024 10:58 AM, Richard Damon wrote:

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

On 5/27/2024 10:25 AM, Richard Damon wrote:

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

>
>
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 either pure simulator H or 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.

>
And how do you apply that to a TEMPLATE that doesn't define what a call H means (as it could be any of the infinite set of Hs that you can instantiate the template on)?
>

>
*Somehow we got off track of the subject of this thread*

>
I note that YOU keep on switching between your C program and Turing Machines.
>
Note, per the implications that you implicitly agreed to (by not even trying to refute) the two systems are NOT equivalents of each other.
>

>
(1) I think you are wrong. I have not seen any of your
reasoning that was not anchored in false assumptions.
Your make fake rebuttal is to change the subject.
>
(2) It does not matter my proof is anchored in the Linz
proof and the H/D pairs are only used to have a 100% concrete
basis to perfectly anchor things such as the correct meaning
of D correctly simulated by H so that people cannot get away
with claiming that an incorrect simulation is correct.
>
int main() { D(D); } IS NOT THE BEHAVIOR OF D CORRECTLY SIMULATED BY H.
One cannot simply ignore the pathological relationship between H and D.
>

>
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.
>
For the purposes of the above analysis we hypothesize that
embedded_H is either a UTM or a UTM that has been adapted
to stop simulating after a finite number of steps of simulation.

>
And what you do mean by that?
>
Do you hypothesize that the original H was just a pure UTM,

>
The original proof does not consider the notion of a simulating
halt decider so I have to begin the proof at an earlier stage
than any definition of H.

>
The biggest problem is that the input to the Turing machine decider H is the description of a Turing Machine H^, which is a SPECIFIC machine,

>
When you say "specific machine" you don't mean anything like a
100% completely specified sequence of state transitions encoded
as a single unique finite string.

>
Mostly.
>
There doesn't need to be a unique finite string, but it is a 100% completely specified state transition/tape operation table.
>

>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
In other words Linz did not prove that there are no set
of state transitions specified by ⊢* that derives the
correct halt status of ⟨Ĥ⟩ ⟨Ĥ⟩.
>
He only said there there is one specific machine that
gets the wrong answer.
>

>
He STARTS with a proof that one specific (but arbitrary) machine gets the wrong answer.
>
Then he shows that the same proof can be applied to ANY such machine (becaue the proof didn't depend on any specific details of the machine, just the general properties of that machine)
>
I guess you don't understand how to do categorical proofs.
>

 I totally do. Can you please write down the
"completely specified state transition/tape operation table."
of this specific (thus uniquely identifiable) machine I would
really like to see it.
 

But it was proven that no such machine exists!
Remember, the proof starts with the hypothetical that such a machine exists. Such a machine WOULD HAVE a completely specified state transition/tape operation table.
(The fact you ask the question means you don't understand the method of proof).
Given the assumption of such a machine, we can show how to construct the H^ machine to test it with.
We can then show that, whatever the actual behavior of the machine H, it will be wrong.
Thus we proved that machine didn't meet the requirements.
And, because we didn't use any specific details of that machine, we can show that we can do the same for ANY machine that might claim to be a halt decider.
Sort of like the proof that there doesn't exist a highest prime number, we first presume that there might be, and then show how that assumption proves itself wrong.