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

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.
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.
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."
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer