| Deutsch English Français Italiano |
|
<6a841a071e812698de7f236c0acfa127b9e321c3@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,sci.logic Subject: Re: Ben thinks the professor Sipser is wrong Date: Thu, 4 Jul 2024 21:21:48 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <6a841a071e812698de7f236c0acfa127b9e321c3@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> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 5 Jul 2024 01:21:48 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2173530"; 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: <v67h9h$2vnls$1@dont-email.me> Content-Language: en-US Bytes: 9335 Lines: 180 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. If DDD Halts, then HHH(DDD) needs to say YES, even though it can't prove it. If DDD doens't Halt, then HHH(DDD) Needs to say No, but if it returns No, them DDD doesn't halt, so HHH can not correctly do that. So, for THIS DDD, HHH needs to answer True, but it can't tell the difference between THIS DDD, and a modified version of DDD that has an infinte loop after the call to HHH, so HHH is stuck not being able to know what to do. This shows the inherent weakness of trying to do just simple emulation as your method for deciding. You fall prey to any machine that has in it an asking of your decider about themselves, even if you don't do anything contraryi with the answer. And such behavior is definitely allowed in the input under the "for any machine" part of the problem. > ========== REMAINDER OF ARTICLE TRUNCATED ==========