Deutsch English Français Italiano |
<v4qeqe$a0nn$1@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: Richard Damon <richard@damon-family.org> Newsgroups: comp.theory Subject: Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Date: Mon, 17 Jun 2024 18:54:06 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <v4qeqe$a0nn$1@i2pn2.org> References: <v4j0h2$39gh7$3@dont-email.me> <v4k0sr$3f4m3$1@dont-email.me> <v4k44j$3fmth$1@dont-email.me> <v4m5gj$3v41v$1@dont-email.me> <v4mmnp$1qt6$2@dont-email.me> <v4ms37$5nh5$1@i2pn2.org> <v4mtif$3cbf$1@dont-email.me> <v4muph$1sav$1@news.muc.de> <v4n8ac$5d22$1@dont-email.me> <v4n9ip$61l9$8@i2pn2.org> <v4n9rb$5d22$2@dont-email.me> <v4nb63$61la$1@i2pn2.org> <v4nc6j$5spn$1@dont-email.me> <v4ncqo$61l9$9@i2pn2.org> <v4pdvl$ln46$12@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 17 Jun 2024 22:54:06 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="328439"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird X-Spam-Checker-Version: SpamAssassin 4.0.0 Content-Language: en-US In-Reply-To: <v4pdvl$ln46$12@dont-email.me> Bytes: 7720 Lines: 173 On 6/17/24 9:33 AM, olcott wrote: > On 6/16/2024 2:01 PM, Richard Damon wrote: >> On 6/16/24 2:50 PM, olcott wrote: >>> On 6/16/2024 1:33 PM, Richard Damon wrote: >>>> On 6/16/24 2:10 PM, olcott wrote: >>>>> On 6/16/2024 1:06 PM, Richard Damon wrote: >>>>>> On 6/16/24 1:44 PM, olcott wrote: >>>>>>> On 6/16/2024 10:02 AM, Alan Mackenzie wrote: >>>>>>>> olcott <polcott333@gmail.com> wrote: >>>>>>>>> On 6/16/2024 9:16 AM, joes wrote: >>>>>>>>>> Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott: >>>>>>>>>>> On 6/16/2024 2:50 AM, Mikko wrote: >>>>>>>> >>>>>>>>>>>> Whenever a decider is run it answers the question it is made >>>>>>>>>>>> to answer. >>>>>>>>>>> Not necessarily. Just because everyone falsely assumes that D >>>>>>>>>>> correctly >>>>>>>>>>> simulated by H must have the same behavior as the directly >>>>>>>>>>> executed D(D) >>>>>>>>>>> does not make this false assumption true. >>>>>>>> >>>>>>>>>> You still need to explain how you can call a simulation that >>>>>>>>>> differs from >>>>>>>>>> the behaviour of its input "correct". >>>>>>>> >>>>>>>> Indeed, you do. >>>>>>>> >>>>>>>>> I have proven it many times and this proof is simply over >>>>>>>>> everyone's heads. >>>>>>>> >>>>>>>> Nonsense! How about, instead of "proving", actually explaining? >>>>>>>> If a >>>>>>>> simulation differs from its original, it's not a simulation; >>>>>>>> it's just a >>>>>>>> random program. >>>>>>>> >>>>>>>>> When I ask what your C programming skill level is, this *is not* a >>>>>>>>> rhetorical question. >>>>>>>> >>>>>>>> The question has nothing to do with C programming. >>>>>>>> >>>>>>> >>>>>>> typedef void (*ptr)(); // pointer to void function >>>>>>> int H(ptr P, ptr I); >>>>>>> >>>>>>> int D(int (*x)()) >>>>>>> { >>>>>>> int Halt_Status = H(x, x); >>>>>>> if (Halt_Status) >>>>>>> HERE: goto HERE; >>>>>>> return Halt_Status; >>>>>>> } >>>>>>> >>>>>>> Unless I make every single detail 100% explicit false >>>>>>> assumptions always slip though the cracks. The ONLY way >>>>>>> to make EVERY SINGLE DETAIL 100% EXPLICIT is the x86 >>>>>>> programming language. >>>>>>> >>>>>>> There cannot possibly be any H that correctly emulates >>>>>>> the x86 machine code of D according to the semantics >>>>>>> of the x86 programming language such that the emulated >>>>>>> D ever reaches its own emulated final state at machine >>>>>>> address [00001f58]. >>>>>>> >>>>>> >>>>>> Which is just a strawman, as the requirement on H is NOT to answer >>>>>> about "D correctly simulated by H" but about "the program >>>>>> represented by the input directly executed", or equivalently, >>>>>> simulated by an actual UTM, which is a simulator that NEVER stops >>>>>> until it reaches a final state. >>>>>> >>>>> >>>>> This is simply over-your-head. >>>>> I am very glad of that because the alternative would >>>>> possibly condemn your soul to Hell. >>>> >>>> Whats over my head? That the definition of a Halt Decider beihg that >>>> it decides on the behavior of the program represented by the input >>>> halting when run? >>>> >>> >>> void DDD() >>> { >>> H0(DDD); >>> } >>> >>> int main() >>> { >>> H0(DDD); >>> } >>> >>> That the machine language finite string input DD0 >>> to any simulating halt decider HH0(DD0) cannot >>> possibly even ask about the behavior of DD0(). >>> >> >> Because it doesn't NEED to. >> > > I am happy that I found out you are not a liar. > You just don't understand these thing very well. > > If a decider is being asked if N > 5? > and the programmer expects the answer to a different question > then the programmer is incorrect. Right, just like if H0 does anything but report on the behavior of the machine described by its inout, then H0's prograam is just incorrect. > > If the programmer expects H0(DDD) to report on the > behavior of DDD(DDD), then the programmer is incorrect. No, sinee that is DOCUMENTED DEFINITION of it, since H0 is called a Halt Decider. > >> By being called a "Halt Decider", HH0 DEFINES what question it is >> being asked, the only question are the parameters of the question, >> which is What is the Program and input to decide on. >> > > H0(DDD) does correctly report on the behavior that its > input specifies and does not report on the behavior that > its input does not specify. So, are you admitting to LYING that H0 is a Halt Decider, or are you LYING that you correctly programmed H0? If H0 is a Halt Decider, the DEFINITION of the "bahavior of its input" is the behavior of the program the input describes, which in this case is DDD(). > >> You are just showing you are absoluting IGNORANT of what you talk >> about, and have been just LYING about it for years. >> > > No the whole actual issue is that you have always been somewhat > more clueless than I ever expected. No, you have just been a pathological liar, that just seems to forget the defintion of the problem he claims to be working on. > > That an input finite string of machine code must be mapped to > the behavior that it specifies through a sequence of finite > string transformation rules according to the semantics of the > x86 language is totally over your head. No, it CAN only go to what can be found by a sequence of finite string transforms, but to be correct, it must go to the mapping of the function it is defined to be computing, which is Halting, which maps the input to the behavior of the machine described by the input. > > Mapping finite strings to behavior is not looking up how > to get to Florida in Google maps. Right, but for a Halt Decider, it IS the uncomputable mapping to the behavior of the program represented by the input. > >> I'm sorry, but I think your "license to do logic" has been revoked, >> and you are being punished for attempted murder on logic. > > When you don't have a slight clue about what I said you try > to get away with masking your own ignorance with rhetoric. > *That surely works on dumb bunnies and other clueless wonders* > ========== REMAINDER OF ARTICLE TRUNCATED ==========