Path: ...!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Mikko Newsgroups: comp.theory Subject: Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Date: Fri, 28 Jun 2024 11:30:34 +0300 Organization: - Lines: 203 Message-ID: References: <87jzidm83f.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 28 Jun 2024 10:30:34 +0200 (CEST) Injection-Info: dont-email.me; posting-host="28b810ff32e626d088cb1c65df50838e"; logging-data="3437620"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ylKqu4JHvWqJK0hEiNWSJ" User-Agent: Unison/2.2 Cancel-Lock: sha1:xk+odag74won3bxvRgBCnFMbphI= Bytes: 11179 On 2024-06-27 16:56:56 +0000, olcott said: > On 6/27/2024 10:35 AM, Mikko wrote: >> On 2024-06-27 14:10:02 +0000, olcott said: >> >>> On 6/27/2024 2:36 AM, Mikko wrote: >>>> On 2024-06-26 12:58:59 +0000, olcott said: >>>> >>>>> On 6/26/2024 3:41 AM, Mikko wrote: >>>>>> On 2024-06-26 02:29:59 +0000, olcott said: >>>>>> >>>>>>> On 6/25/2024 9:23 PM, Richard Damon wrote: >>>>>>>> On 6/25/24 10:05 PM, olcott wrote: >>>>>>>>> On 6/25/2024 8:47 PM, Richard Damon wrote: >>>>>>>>>> On 6/25/24 1:45 PM, olcott wrote: >>>>>>>>>>> On 6/25/2024 9:46 AM, Alan Mackenzie wrote: >>>>>>>>>>>> Hi, Ben. >>>>>>>>>>>> >>>>>>>>>>>> Ben Bacarisse wrote: >>>>>>>>>>>>> Alan Mackenzie writes: >>>>>>>>>>>> >>>>>>>>>>>>>> In comp.theory olcott wrote: >>>>>>>>>>>>>>> On 6/25/2024 4:22 AM, joes wrote: >>>>>>>>>>>>>>>> Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 6/22/2024 1:39 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>> Op 21.jun.2024 om 15:21 schreef olcott: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> When we stipulate that the only measure of a correct emulation is the >>>>>>>>>>>>>>>>> semantics of the x86 programming language then we see that when DDD is >>>>>>>>>>>>>>>>> correctly emulated by H0 that its call to H0(DDD) cannot possibly >>>>>>>>>>>>>>>>> return. >>>>>>>>>>>>>>>> Yes. Which is wrong, because H0 should terminate. >>>>>>>>>>>> >>>>>>>>>>>>>> [ .... ] >>>>>>>>>>>> >>>>>>>>>>>>>>> The call from DDD to H0(DDD) when DDD is correctly emulated >>>>>>>>>>>>>>> by H0 cannot possibly return. >>>>>>>>>>>> >>>>>>>>>>>>>>> Until you acknowledge this is true, this is the >>>>>>>>>>>>>>> only thing that I am willing to talk to you about. >>>>>>>>>>>> >>>>>>>>>>>>>> I think you are talking at cross purposes.  Joes's point is that H0 >>>>>>>>>>>>>> should terminate because it's a decider.  You're saying that when H0 is >>>>>>>>>>>>>> "correctly" emulating, it won't terminate.  I don't recall seeing anybody >>>>>>>>>>>>>> arguing against that. >>>>>>>>>>>> >>>>>>>>>>>>>> So you're saying, in effect, H0 is not a decider.  I don't think anybody >>>>>>>>>>>>>> else would argue against that, either. >>>>>>>>>>>> >>>>>>>>>>>>> He's been making exactly the same nonsense argument for years.  It >>>>>>>>>>>>> became crystal clear a little over three years ago when he made the >>>>>>>>>>>>> mistake of posting the pseudo-code for H -- a step by step simulator >>>>>>>>>>>>> that stopped simulating (famously on line 15) when some pattern was >>>>>>>>>>>>> detected.  He declared false (not halting) to be the correct result for >>>>>>>>>>>>> the halting computation H(H_Hat(), H_Hat()) because of what H(H_Hat(), >>>>>>>>>>>>> H_Hat()) would do "if line 15 were commented out"! >>>>>>>>>>>> >>>>>>>>>>>>> PO does occasionally make it clear what the shell game is. >>>>>>>>>>>> >>>>>>>>>>>> I think it's important for (relative) newcomers to the newsgroup to >>>>>>>>>>>> become aware of this.  Each one of them is trying to help PO improve his >>>>>>>>>>>> level of learning.  They will eventually give up, as you and I have >>>>>>>>>>>> done, recognising (as Mike Terry, in particular, has done) that >>>>>>>>>>>> enriching PO's intellect is a quite impossible task. >>>>>>>>>>>> >>>>>>>>>>>> What's the betting he'll respond to this post with his usual short >>>>>>>>>>>> sequence of x86 assembly code together with a demand to recognise >>>>>>>>>>>> something or other as non-terminating? >>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Ben. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>      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. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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. >>>>>>>>>>>  > >>>>>>>>>>>  > He knows and accepts that P(P) actually does stop. The >>>>>>>>>>>  > wrong answer is justified by what would happen if H >>>>>>>>>>>  > (and hence a different P) where not what they actually are. >>>>>>>>>>>  > >>>>>>>>>>> >>>>>>>>>>> Ben thinks that I tricked professor Sipser into agreeing >>>>>>>>>>> with something that he did not fully understand. >>>>>>>>>>> >>>>>>>>>>> *The real issue is that no one here sufficiently understands* >>>>>>>>>>> *the highlighted portion of the following definition* >>>>>>>>>>> >>>>>>>>>>> Computable functions are the formalized analogue of the >>>>>>>>>>> intuitive notion of algorithms, in the sense that a >>>>>>>>>>> function is computable if there exists an algorithm >>>>>>>>>>> that can do the job of the function, i.e. >>>>>>>>>>> >>>>>>>>>>> *given an input of the function domain* >>>>>>>>>>> *it can return the corresponding output* >>>>>>>>>>> >>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> But only if the function is, in fact, computable. >>>>>>>>>> >>>>>>>>>> Since Halting isn't, you can't use that fact. >>>>>>>>> >>>>>>>>> If I ask you: What time is it? >>>>>>>>> and you do not tell me the answer to the question hidden >>>>>>>>> in my mind "What did you have for dinner?" We cannot say >>>>>>>>> that you provided the wrong answer when you tell me what >>>>>>>>> time it is. >>>>>>>> >>>>>>>> Because I answered the actual question. >>>>>>>> >>>>>>>> Just like the "Halt Decider" needs to answer the "Halt Decider >>>>>>>> Question" and not answer about POOP. >>>>>>>> >>>>>>>>> >>>>>>>>> When we ask H to tell us whether its actual input halts >>>>>>>>> H can only answer that P correctly simulated by H will not halt. >>>>>>>>> H cannot answer the question hidden in your mind. >>>>>>>>> >>>>>>>> >>>>>>>> Then you are just admitting that it can't be a Halt Decider. >>>>>>>> >>>>>>>> If it isn't what the definition requires, it just isn't one. >>>>>>> >>>>>>> Yes and everyone knows that computer scientists are much >>>>>>> more infallible than God thus cannot possibly ever make >>>>>>> a definition that is incoherent in ways that these 100% >>>>>>> infallible computer scientists never noticed. >>>>>> >>>>>> Actually, it is the opposite. Everybody, or at least all computer >>>>>> scientists and engineers, know that they, and all peaple, are fallible, >>>>>> at least when making programs and when inferring about programs. Therefore >>>>>> computer engineers demand that every program must be tested, and computer >>>>>> scinetists demand that every claim is proven. >>>>> >>>>> If this was true then everyone here would already know >>>>> that H(P,P) is not even being asked about the behavior >>>>> of the directly executed P(P). >>>> >>>> Everyone knwos that H(P,P) is not asked anything. >>>> >>> >>> In computability theory and computational complexity theory, a >>> decision problem is a computational problem that can be posed as >>> a yes–no question of the input values. >>> https://en.wikipedia.org/wiki/Decision_problem >> >> That's right. But that question cannot be presented to the decider. >> Only the input values can. >> > In other words you are saying that Turing machines do not > typically understand English. I didn't mean it that generally, only about deciders, but yes, typical Turing machines do not understand any English. More specifically, the specification of a halt decider (or any typical decider) prevents it from being asked in any language. > None-the-less no-one here understands that every halt decider > is only required to report on the behavior that its actual > input actually maps to. As far as I have seen, most of them do. And not just maps but maps in the way specified by the problem statement. > Instead everyone here expects that the halt decider must map > to the English description of what the authors of textbooks > expect it to map to. Your "everyone" is a lie. As far as I have seen, nobody has expressed ========== REMAINDER OF ARTICLE TRUNCATED ==========