Path: ...!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: Richard Damon Newsgroups: comp.theory,sci.logic Subject: =?UTF-8?B?UmU6IFZlcmlmaWVkIGZhY3QgdGhhdCDEpC5IIOKfqMSk4p+pIOKfqMSk?= =?UTF-8?B?4p+pIGFuZCBIIOKfqMSk4p+pIOKfqMSk4p+pIGhhdmUgZGlmZmVyZW50IGJlaGF2?= =?UTF-8?Q?ior_--RASP_Machines--?= Date: Sun, 10 Mar 2024 19:19:21 -0700 Organization: i2pn2 (i2pn.org) Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 11 Mar 2024 02:19:22 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="1531343"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird Content-Language: en-US X-Spam-Checker-Version: SpamAssassin 4.0.0 In-Reply-To: Bytes: 5148 Lines: 76 On 3/10/24 6:14 PM, olcott wrote: > On 3/10/2024 7:46 PM, immibis wrote: >> On 11/03/24 01:32, olcott wrote: >>> On 3/10/2024 2:16 PM, immibis wrote: >>>> >>>> I noticed that you gave up on Olcott machines and now you are back >>>> to your old bullshit ways of pretending that the same machine can >>>> produce two different execution traces on the same input. Why don't >>>> you show us an execution trace where that happens? Both traces must >>>> show the first instruction that is different in both traces and I >>>> recommend showing 20 more instructions after that, but you can abort >>>> one after that time, if it doesn't halt, to prevent the trace >>>> getting infinitely long. >>> >>> Turing Machines and Olcott machines cannot properly implement >>> H1(D,D) and H(D,D) that know their own machine address. >> >> "Know their own machine address" isn't an objective specification and >> it has nothing to do with the halting problem anyway. Turing machines >> don't have machine addresses and Olcott machines don't have machine >> addresses either. >> >>> My C code proves these two have different behavior: >>> (a) H1(D,D) + H1_machine_address >>> (b) H(D,D) + H_machine_address >> >> Of course. >> >>> Because they are different computations they are >>> not required to have the same behavior. >> >> Of course. One of them even answers the halting problem correctly in >> this case. But that's because this case isn't the Linz counterexample >> for H1. If you built the Linz counterexample for H1, which is D1, >> you'd find that H1 gets it wrong, so H1 doesn't solve the halting >> problem. > > I am taking H1(D,D) to be Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ and H(D,D) to be Linz H ⟨Ĥ⟩. > Since we are using machine addresses there is no need for copies. > This simplifies Linz Ĥ down to this. Then you are just LYING about following Linz. Linz H^ needs to use the EXACT computation that it is to foil, and call it in a way that it give exactly the same answer. Anything else is just a LIE. > > Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts > Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt > > H/D does contradict itself like simplified Linz Ĥ and > H1(D,D) does not contradict itself like Linz H ⟨Ĥ⟩ ⟨Ĥ⟩. H^ / D contradicts the H that it was trageted to defeat. That any other decider get it right is irreleent. > >>> They cannot be implemented as Turing Machines or Olcott >>> Machines. They can be implemented as RASP machines proven >>> by the fact that they are implemented as C functions. >> >> They can be implemented as Turing machines. Each one is different from >> the other. They are not the same. >> > > Turing machines and Olcott machines cannot know their own machine > address in a way that cannot be circumvented. X86 virtual machines > and thus (possibly augmented) RASP machines can. > Right, that is how you are CHEATING. YOu are just now being more blantant about it, which make it easier to point that you are just lying.