| Deutsch English Français Italiano |
|
<b119fc7a4b5d0599a084a3af604b13ac9782ec11@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: Richard Damon <richard@damon-family.org> Newsgroups: comp.theory,sci.logic Subject: Re: Ben thinks the professor Sipser is wrong Date: Thu, 4 Jul 2024 21:56:45 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <b119fc7a4b5d0599a084a3af604b13ac9782ec11@i2pn2.org> References: <tic5tr$25uem$6@dont-email.me> <8735bpq5jh.fsf@bsb.me.uk> <v66o6i$2rv8q$3@dont-email.me> <8bbce1bb519f205ef865a07719bf35f68170ad61@i2pn2.org> <v66psp$2scuh$1@dont-email.me> <990598b3a90c559f7125530edef9c5a0ef2c7102@i2pn2.org> <v677vh$2u7lu$2@dont-email.me> <dbebddf487aebc1c848fc07abb0f7800e068f34e@i2pn2.org> <v67d2s$2v7vf$1@dont-email.me> <9d7ed80b2fc8e04050d413c3f922ce409d55f31c@i2pn2.org> <v67h9h$2vnls$1@dont-email.me> <6a841a071e812698de7f236c0acfa127b9e321c3@i2pn2.org> <v67ikj$2vtu0$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 5 Jul 2024 01:56:45 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2173531"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird X-Spam-Checker-Version: SpamAssassin 4.0.0 In-Reply-To: <v67ikj$2vtu0$1@dont-email.me> Content-Language: en-US Bytes: 11689 Lines: 237 On 7/4/24 9:35 PM, olcott wrote: > On 7/4/2024 8:21 PM, Richard Damon wrote: >> On 7/4/24 9:12 PM, olcott wrote: >>> On 7/4/2024 7:33 PM, Richard Damon wrote: >>>> On 7/4/24 8:00 PM, olcott wrote: >>>>> On 7/4/2024 6:18 PM, Richard Damon wrote: >>>>>> On 7/4/24 6:33 PM, olcott wrote: >>>>>>> On 7/4/2024 5:21 PM, Richard Damon wrote: >>>>>>>> On 7/4/24 2:32 PM, olcott wrote: >>>>>>>>> On 7/4/2024 1:17 PM, Richard Damon wrote: >>>>>>>>>> On 7/4/24 2:04 PM, olcott wrote: >>>>>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022> >>>>>>>>>>> If simulating halt decider H correctly simulates its >>>>>>>>>>> input D >>>>>>>>>>> until H correctly determines that its simulated D would >>>>>>>>>>> never >>>>>>>>>>> stop running unless aborted then >>>>>>>>>>> >>>>>>>>>>> H can abort its simulation of D and correctly report that D >>>>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022> >>>>>>>>>>> >>>>>>>>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote: >>>>>>>>>>> > I don't think that is the shell game. PO really /has/ an >>>>>>>>>>> H (it's >>>>>>>>>>> > trivial to do for this one case) that correctly determines >>>>>>>>>>> that P(P) >>>>>>>>>>> > *would* never stop running *unless* aborted. >>>>>>>>>>> ... >>>>>>>>>>> > But H determines (correctly) that D would not halt if it >>>>>>>>>>> were not >>>>>>>>>>> > halted. That much is a truism. >>>>>>>>>>> >>>>>>>>>>> Ben clearly agrees that the above criteria have been met, >>>>>>>>>>> yet feels that professor Sipser was tricked into agreeing >>>>>>>>>>> that this means that: >>>>>>>>>>> H can abort its simulation of D and correctly report that D >>>>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>>>> >>>>>>>>>>> I spent two years deriving those words that Professor Sipser >>>>>>>>>>> agreed with. It seems to me that every software engineer would >>>>>>>>>>> agree that the second part is logically entailed by the first >>>>>>>>>>> part. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You mean you WASTED two years and set a trap for your self >>>>>>>>>> that you fell into. >>>>>>>>>> >>>>>>>>>> The problem is that Ben is adopting your definitions that >>>>>>>>>> professor Sipser is not using. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Ben agrees that my criteria have been met according to their >>>>>>>>> exact words. If you want to lie about that I won't talk to >>>>>>>>> you again. >>>>>>>>> >>>>>>>> >>>>>>>> Which meant different things, so not the same. >>>>>>>> >>>>>>>> The biggest problem is your H/P interlocking program pair is >>>>>>>> something outside the normal scope of Computation theory. >>>>>>>> >>>>>>>> The way you have built your Deicder/Decider combination isn't >>>>>>>> actualy within the definition of normal Computaiton Theory, as >>>>>>>> that would have Decider as a totally independent program from >>>>>>>> the program it is deciding on. >>>>>>>> >>>>>>>> Your H and D aren't that sort of thing because they are >>>>>>>> interwined into a single memory space, and even share code. >>>>>>>> >>>>>>>> This makes some things possible to do about the pair that can >>>>>>>> not be done if they were independent programs, like H being able >>>>>>>> to detect that D calls itself (but not copies of itself, which >>>>>>>> is why you don't allow those copies, as that breasks your lie). >>>>>>>> >>>>>>> >>>>>>> Ever heard of string comparison? >>>>>>> H can detect that D calls copies of itself. >>>>>>> That merely makes the details more complex. >>>>>> >>>>>> Nope, doesn't work. Particularly for Turing Machines. >>>>>> >>>>>> The problem is that the seperate compliation and linking with the >>>>>> resultant different address makes the byte pattern for the code >>>>>> not necessarily a duplicate. >>>>>> >>>>>> When you consider that the input is antagonistic, it can also >>>>>> intentionally make alterations that do not change the outward >>>>>> behavior, but do change the byte code. >>>>>> >>>>>> I seem to remember that it has been proven that, in general, the >>>>>> identification of an equivalent copy of yourself is uncomputable. >>>>>> >>>>>> We went over this before, and you could never understand it. >>>>>> >>>>>>> >>>>>>>> Another of the big effect of thins, is that the way you defined >>>>>>>> it, D actually does have access to the decider that is going to >>>>>>>> decide it (if we follow your rule and name the decider H). This >>>>>>>> can turn what used to be an independent fully defined program P >>>>>>>> into a dependent program template. >>>>>>> >>>>>>> The key issue is that by my basis structure that applies equally >>>>>>> to DD correctly simulated by HH as it applies to ⟨Ĥ⟩ correctly >>>>>>> simulated by embedded_H is that the paradoxical decision point >>>>>>> cannot be reached. This converts the "impossible" problem into a >>>>>>> difficult one. >>>>>> >>>>>> Nope. Your basic structure can not be converted back into a pair >>>>>> of Turing Machihes, showing it isn't based on actual Computations. >>>>>> >>>>>>> >>>>>>>> Undet THAT condition, Ben agreed that yoUr H could conclude that >>>>>>>> no version of H could simulate the version of D that uses it, to >>>>>>>> its final state. Since P is a template, and not a program, it >>>>>>>> doesn't have the normal Objective definition of behavior, and >>>>>>>> thus your subjective one might need to be used, even with its >>>>>>>> problems. >>>>>>>> >>>>>>> >>>>>>> The key point that you must acknowledge before continuing is >>>>>>> that the criteria is met for H/D. I can't tolerate one more >>>>>>> reply where you deny this. >>>>>> >>>>>> But your criteria isn't a legal critieria. The "Behavior" of the >>>>>> input must be an objective property of just that input, and thus >>>>>> can not be something that depends on the decider looking at it. >>>>>> >>>>> >>>>> It must depend on the decider looking at it or we are required >>>>> to ignore the actual fact that DDD does call HHH in recursive >>>>> simulation. We are certainly not allowed to ignore any actual >>>>> facts. If you can't get that then it seems we may be done talking. >>>> >>>> >>>> Why do you say that? Yes, it males the problem harder (in fact in >>>> some cases impossible) but that is the rule. >>>> >>>> You seem to have a problem with the simple fact that some maps are >>>> just imposisble to compute. >>>> >>>> But that MUST be true as there is an order of infinity more maps >>>> than possible deciders, so most maps must not be computable. >>>> >>>> It CAN'T depend on the decider, >>> >>> It must depend on the decider because that is an aspect >>> that the execution trace of DDD correctly emulated by >>> HHH specifies at machine address 0000217a. >> >> Nope, the correct answer depend on if DDD Halts or not, as determined >> by the direct execution of DDD, since that IS the behavior defined for >> DDD. >> > > _DDD() > [00002172] 55 push ebp ; housekeeping > [00002173] 8bec mov ebp,esp ; housekeeping > [00002175] 6872210000 push 00002172 ; push DDD > [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) > [0000217f] 83c404 add esp,+04 > [00002182] 5d pop ebp > [00002183] c3 ret > Size in bytes:(0018) [00002183] > ========== REMAINDER OF ARTICLE TRUNCATED ==========