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

Am Wed, 29 May 2024 21:32:49 -0500 schrieb olcott:

On 5/29/2024 9:27 PM, Richard Damon wrote:

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

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

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?

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?

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.

Or aborts prematurely.

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.

But the question ISN'T about the SIMULATED D, but about the
behavior of the actual PROGRAM/MACHINE D

Which should be the same.

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.

What’s the difference?

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

If we assume that a decider takes an actual Turing machine as its
input that is correct otherwise that is one level of indirection
away from what we are really looking at.
>
The people have perpetuated this mistake for many decades never
actually made it not a mistake.

You need to define what you mean by "Indirection", because you aren't
using it in the normal manner.

 
I have conclusively proven that the behavior of the correct
simulation of the x86 code of D by pure function H has
different behavior than the direct execution of D(D).

Then H is not a correct simulator.

--
joes