Re: Every D(D) simulated by H presents non-halting behavior to H ###

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

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

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

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

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

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

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

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

On 5/27/24 10:39 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

>
*It is completely defined and you are just ignoring this definition*

>
So, what instruction does the call H in D go to to be simulated?
>

>
DISHONEST HEAD GAMES. WHEN WE APPLY THIS SAME REASONING TO THE
LINZ TEMPLATE YOUR REASONING CALLS THE LINZ TEMPLATE NONSENSE.

>
Nope, because Linz doesn't try to pass a Template to H, but the machine built from the template H^.
>
As I said, if you assume the input is the machine built from the template you get the ability to define the simulation, you just now get every decider got a different input, so you can't just do the logic across them.
>
YOU are the one trying to do dishonest head games
>
(And who has been saying that insults are unprofessional?)
>

>

As a template, there is no fixed H, so no instruction to look at.
>

H correctly simulates 1 to ∞ steps of D with either pure function H
or pure simulator H. In none of these cases does the correctly simulated
D ever reach its own simulated final state and halt.
>
Do some of these instances of H play a game of poker with themselves
before or after they simulate D? Yes they do because the H/D pairs
are an infinite set.
>

>
But, how do they correctly simulate something that isn't there?
>
Either they are simulating an INSTANCE of the template, in which case each H is looking at a DIFFERENT instance, and you can't relate one result to the other, or they are trying to simulate the Template, at which point you have the problem that the code to be simulated hasn't been defined, and thus you can't do what you define to do.

>
I AM REFERRING TO THE EXACT SAME SORT OF INFINITE SET
THAT THE LINZ TEMPLATE IS REFERRING TO AND YOU KNOW IT.

>
Nope, Linz choose A SPECIFIC H out of the set, and gives it a SPECIFIC H^ built from that SPECIFIC H, and then works with that set. There is

 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.
Note, the sequences of states it goes through, will be a function of the input given to that machine.
No no-trival Turing machine has a unique finite string encoding because you can always re"name" the non-initial/non-final states generating a vast array of possible encodings (generally an infinite number of them)
Does that surprise you? It shouldn't
Note, that specific Turing machine H^ needs to be built from the specific Turing Machine H that it is being built to refute as being correct.
The key is we can show that for ANY machine that might claim to be a correct halt decider, the proof establishes a formula to construct a specific input you can give that specific machine to show that it isn't correct.

 When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 Linz claims that out of the infinite possible implementations of
embedded_H specified by the second ⊢* that none of them get the
right answer.

Right, and he does it by categorical exhaustive logic.

 I would be pretty dumb if Linz took this the way the you are taking it: "there exists a specific implementation of embedded_H that gets the wrong answer."
 

Nope, I guess you don't understand how to do a categorical proof.
If you take an specific, but arbitrary, member of the set, and show that it is wrong. Then, since the choice was arbitrary, you can point out that the exact same proof could be done to any other member of the set, thus NO member of the set can be right.
The point is that when you are dealing with a specific machine, and the specific input you are giving that machine, you have at hand a large set of tools that let you talk about that machine,
If you try to work with all of them at once, it is much harder to get things right, as you need to keep all the relationships between the elements in order.
The key point is that most of the Theory provides details about the behaivior of *A* machine, not sets of machines. After all, when you run a machine, you run a specific machine and get a specific answer from that machine, so to handle a set you need to look at each of them individually anyway.