Path: ...!news.misty.com!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: olcott Newsgroups: comp.theory,sci.logic Subject: Re: H(D,D) cannot even be asked about the behavior of D(D) Date: Fri, 14 Jun 2024 20:59:09 -0500 Organization: A noiseless patient Spider Lines: 96 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 15 Jun 2024 03:59:10 +0200 (CEST) Injection-Info: dont-email.me; posting-host="020d44455d70acf7231aebb6a85d124b"; logging-data="3313341"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19gEz9tB54xLE7eActo20wQ" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:n8Tx0UDmdobwsIHAAOaADOcPaik= In-Reply-To: Content-Language: en-US Bytes: 5241 On 6/14/2024 8:38 PM, Richard Damon wrote: > On 6/14/24 8:34 PM, olcott wrote: >> On 6/14/2024 6:27 PM, Richard Damon wrote: >>> On 6/14/24 9:15 AM, olcott wrote: >>>> On 6/14/2024 6:39 AM, Richard Damon wrote: >>>>> On 6/14/24 12:13 AM, olcott wrote: >>>>>> >>>>>> No it is more than that. >>>>>> H cannot even be asked the question: >>>>>> Does D(D) halt? >>>>> >>>>> No, you just don't understand the proper meaning of "ask" when >>>>> applied to a deterministic entity. >>>>> >>>> >>>> When H and D have a pathological relationship to each >>>> other then H(D,D) is not being asked about the behavior >>>> of D(D). H1(D,D) has no such pathological relationship >>>> thus D correctly simulated by H1 is the behavior of D(D). >>> >>> OF course it is. The nature of the input doesn't affet the form of >>> the question that H is supposed to answer. >>> >> >> The textbook asks the question. >> The data cannot possibly do that. >> > > But the data doesn't need to do it, as the program specifictions define it. > Did you know that the code itself cannot read these specifications? The specifications say {draw a square circle}, the code says huh? > Now, if H was supposed to be a "Universal Problem Decider", then we I don't have time for an infinite conversation. H is ONLY defined to be a D decider. > would need to somehow "encode" the goal of H determining that a correct > (and complete) simulation of its input would need to reach a final > state, but I see no issue with defining a way to encode that. > >> You already said that H cannot possibly map its >> input to the behavior of D(D). > > Right, it is impossible for H to itself compute that > behavior and give an answer. > NO !!! It is impossible for anyone or anything to provide a correct answer to a question THAT THEY ARE NOT BEING ASKED. > That doesn't mean we can't encode the question. > Give it your best shot, it must be encoded in C. >> >> We need to stay focused on this one single point until you >> fully get it. Unlike the other two respondents you do have >> the capacity to understand this. >> >> You keep expecting H to read your computer science >> textbooks. >> > > No, I expect its PROGRAMMER to have done that, > which clearly you haven't done. > The spec says {CAD system that draws square circles} The programmer say WTF! > Programs don't read their requirements, the perform the actions they > were programmed to do, There is no way to encode H to even see the behavior of D(D) when H and D have the pathological relationship. That is the dumbed down version of H cannot map its finite string x86 machine code to the behavior of D(D). > and if the program is correct, it will get the > right answer. If it doesn't get the right answer, then the programmer > erred in saying it meet the requirements. > Sure make a CAD system that draws square circles or you are fired. You are failing to understand the notion of logically impossible. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer