Re: Two dozen people were simply wrong --- Try to prove otherwise

On 5/29/24 9:15 PM, olcott wrote:

On 5/29/2024 8:07 PM, Richard Damon wrote:

On 5/29/24 8:59 PM, olcott wrote:

On 5/29/2024 7:48 PM, Richard Damon wrote:

On 5/29/24 8:17 PM, olcott wrote:

On 5/29/2024 7:09 PM, Richard Damon wrote:

On 5/29/24 7:57 PM, olcott wrote:

On 5/29/2024 6:47 PM, Richard Damon wrote:

On 5/29/24 2:31 PM, olcott wrote:

On 5/29/2024 1:14 PM, Ben Bacarisse wrote:

Alan Mackenzie <acm@muc.de> writes:
>

How about a bit of respect?  Mike specifically asked you not to cite his
name as a back up for your points.  Why do you keep doing it?

>
He does it to try to rope more people in.  It's the same ploy as
insulting people by name.  It's hard to ignore being maligned in public
by a fool.
>

>
*Thanks for validating my simplified encoding of the Linz*
>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
I really did believe that Ben Bacarisse was lying when I said it.
>
At the time I was talking about the easily verified fact of the actual
execution trace of fully operational code and everyone was denying the
easily verified facts.
>
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       }
>
It turns out that two dozen people are easily proven wrong when
they claimed that the correct simulation of the input to H(D,D)
is the behavior of int main() { D(D); }
>

>
How is that?
>
>

When D is correctly simulated by H using an x86 emulator the only
way that the emulated D can reach its own emulated final state
at line 06 and halt is
(a) The x86 machine code of D is emulated incorrectly
(b) The x86 machine code of D is emulated in the wrong order
>

>
Which isn't a "Correct Simulation" by the definition that allow the relating of a "Simulation" to the behavior of an input.
>

>
Right the execution trace of D simulated by pure function H using
an x86 emulator must show that D cannot possibly reach its own
simulated final state and halt or the simulation of the machine
language of D is incorrect or in the wrong order.

>
So, you aren't going to resolve the question but just keep up with your contradiction that H is simulating a template (that doesn't HAVE any instrucitons of H in it) but also DOES simulate those non-existance instructions by LYING about what it does and simulating a SPECIFIC instance that it LIES behaves just like DIFFERENT specific instatces.

>
I will give you the benefit of the doubt and call that an honest
misunderstanding. I have much more empathy for you now that I found
that Linz really did say words that you could construe as you did.
>
The infinite set of every H/D pair specified by the template
where D is correctly simulated by pure simulator H or pure function
H never has any D reach its own simulated final state and halt.

>
But the question ISN'T about the SIMULATED D, but about the behavior of the actual PROGRAM/MACHINE D
>
This seems to be your blind spot.

>
∃H  ∈ Turing_Machines
∀x  ∈ Turing_Machines_Descriptions
∀y  ∈ Finite_Strings
such that H(x,y) = Halts(x,y)
>
Not really the above formalization does not can cannot
specify Turing Machines as the input to any decider H.
>

>
Then what is x representing?

>
x <is> a finite string Turing machine description that SPECIFIES behavior. The term: "representing" is inaccurate.
>

 No, it specifies the machine, and thus, though that, the behavior.