Liste des Groupes | Revenir à theory |
On 2024-05-30 09:08:05 +0000, joes said:*I proved that Mike Terry is wrong and he simply ignored the proof*
Am Wed, 29 May 2024 21:32:49 -0500 schrieb olcott:Either that or the correct simulation of the x86 of D by pure functionOn 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 whenHow is that?
they claimed that the correct simulation of the input to H(D,D)
is the behavior of int main() { D(D); }
>Or aborts prematurely.Which isn't a "Correct Simulation" by the definition thatRight the execution trace of D simulated by pure function H using
allow the relating of a "Simulation" to the behavior of an
input.
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.Which should be the same.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.What’s the difference?>∃H ∈ Turing_MachinesThen what is x representing?
∀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.
>
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.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.
>Then H is not a correct simulator.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).
H does not exists. If you ensure that H is not a pure functin or
that H never performs a correct simulation of D you can say whatever
you want about the impossible simulation, for example that it
is yellow.
Les messages affichés proviennent d'usenet.