Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: Richard Damon Newsgroups: comp.theory,sci.logic Subject: Re: At least 100 people kept denying the easily verified fact --- last communication with Richard (we wish) Date: Fri, 7 Jun 2024 18:18:58 -0400 Organization: i2pn2 (i2pn.org) Message-ID: References: <8c92495d4433776d8ddc4706fb1de05b245f5829.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 7 Jun 2024 22:18:58 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="3468869"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird Content-Language: en-US In-Reply-To: X-Spam-Checker-Version: SpamAssassin 4.0.0 Bytes: 4179 Lines: 73 On 6/7/24 6:11 PM, olcott wrote: > On 6/7/2024 3:17 PM, Richard Damon wrote: >> On 6/7/24 4:04 PM, olcott wrote: >>> On 6/7/2024 2:57 PM, Alan Mackenzie wrote: >>>> [ Followup-To: set ] >>>> >>>> In comp.theory olcott wrote: >>>> >>>> [ .... ] >>>> >>>>> If people are going to be dishonest about simple things such as the >>>>> actual behavior of actual x86 code where they consistently deny >>>>> verified facts .... >>>> >>>> You should stop swearing.  "Verified facts" has a meaning, >>> >>> Everyone knows that the following is a verified fact and >>> they dishonestly deflect. >> >> It MIGHT be a fact, but it hasn't been "Verified" as in a formal >> process that certifies a statement to be true, or that it has been >> actually formally proven. >> > > That is great you said that right before I was going to quit > looking at any of your replies. I enjoy talking to you yet not > at the expense of you undermining my life's work. > > That it is literally impossible to prove that the following > is false conclusively proves that it is true and the proof > really need not be wrapped in any tuxedo. Nope. Just shows you don't understand the meaning of True. And you are apperently stuck out in the open in your birthday clothes as it is revealed that you don't understand how logic works. > > We can get on to other key points only after we have closure > on this {foundation of simulating halt deciders} point. > > Try to show how this DD correctly simulated by any HH ever > stops running without having its simulation aborted by HH. Again, WHY? Partial simulation does not prove non-halting. > > _DD() > [00001e12] 55         push ebp > [00001e13] 8bec       mov  ebp,esp > [00001e15] 51         push ecx > [00001e16] 8b4508     mov  eax,[ebp+08] > [00001e19] 50         push eax      ; push DD > [00001e1a] 8b4d08     mov  ecx,[ebp+08] > [00001e1d] 51         push ecx      ; push DD > [00001e1e] e85ff5ffff call 00001382 ; call HH > > A {correct simulation} means that each instruction of the > above x86 machine language of DD is correctly simulated > by HH and simulated in the correct order. > > Anyone claiming that HH should report on the behavior > of the directly executed DD(DD) is requiring a violation > of the above definition of correct simulation. > > So, you are just admitting that you aren't working on the halting problem as that DOES require looking at the behavior of the directly executed DD(DD). So, you have admitted your defeat.