Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott Newsgroups: comp.theory,sci.logic Subject: Re: A computable function that reports on the behavior of its actual self is not allowed Date: Sun, 12 May 2024 19:20:16 -0500 Organization: A noiseless patient Spider Lines: 159 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 13 May 2024 02:20:16 +0200 (CEST) Injection-Info: dont-email.me; posting-host="822a7b45c10435b9354ed3bfb60d5b64"; logging-data="3216055"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Y7oi1A4Owyk9TSWpKEZdH" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:jVCTFHnbR1Nt8ir9nD1WwFB0SOQ= Content-Language: en-US In-Reply-To: Bytes: 7947 On 5/12/2024 7:05 PM, Richard Damon wrote: > On 5/12/24 7:19 PM, olcott wrote: >> On 5/12/2024 5:40 PM, Richard Damon wrote: >>> On 5/12/24 6:21 PM, olcott wrote: >>>> On 5/12/2024 4:40 PM, Richard Damon wrote: >>>>> On 5/12/24 5:18 PM, olcott wrote: >>>>>> On 5/12/2024 2:27 PM, olcott wrote: >>>>>>> Computable functions are the basic objects of study in computability >>>>>>> theory. 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 >>>>>>> >>>>>>> A computable function that reports on the behavior of its actual >>>>>>> self (or reports on the behavior of its caller) is not allowed. >>>>>>> >>>>>>> A decider must halt whereas simulating a pathological input >>>>>>> that would never halt unless aborted can only halt by aborting. >>>>>>> >>>>>>> This causes the direct execution of this input after it has been >>>>>>> aborted >>>>>>> to have different behavior than the simulated input that cannot >>>>>>> possibly >>>>>>> stop running unless aborted. >>>>>>> >>>>>> >>>>>> *MORE PRECISE WORDING* (this may take a few more rewrites) >>>>>> When Ĥ is applied to ⟨Ĥ⟩ >>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>> >>>>>> It is a verified fact that the directly executed Ĥ ⟨Ĥ⟩ cannot >>>>>> possibly >>>>>> stop running unless simulating partial halt decider embedded_H aborts >>>>>> its simulation of its input. >>>>> >>>>> But since embedded_H implements a specific algorithm, either it >>>>> will or it won't. "unless" is a meaningless word here, it implies a >>>>> case that can't happen. >>>>> >>>>> We can look at the two possible cases. >>>>> >>>>> First, if embedded_H doesn't ever abort its simulation, then, as >>>>> you have desceribed, THAT embedded_H creates a H^ that will never >>>>> halt, but the H that was based on will also never abort its >>>>> simulation (or you lied that embedded_H is the needed copy of H) >>>>> and thus never answer and fail to be a decider. >>>>> >>>> >>>> It can answer without halting by transitioning to its own internal >>>> non-final state of embedded_H.qn without ever reaching Ĥ.qn. Every >>>> simulated instance of embedded_H would do this same thing and then >>>> continue simulating its input. >>> So, you just don't understand how algorithms work, and how >>> compuations are DEFINED. >>> >>> >>> If you want to try to define a new system of compuation that allows >>> giving answer without the algorithm ending, but still allows all the >>> composition operations that are included in computation theory, go >>> ahead and try. >>> >>> You then need to show that it is Turing Complete, which means that >>> you can't outlaw any computation allowed in a Turing Machine, like H^. >>> >>>> >>>> In this case embedded_H an actual UTM that has the extra >>>> feature of examining all of the state transitions of its input >>>> to see what we can all see that Ĥ ⟨Ĥ⟩ remains stuck in recursive >>>> simulation. >>>> >>> >>> And a UTM doesn't reveal its answer until it come to a final state, >>> just like ALL Turing Machines or equivalent computation. >>> >>>> *Or we can get an actual partial halt decider as follows* >>>> *Or we can get an actual partial halt decider as follows* >>>> *Or we can get an actual partial halt decider as follows* >>>> >>>> No decider is ever allowed to report on its own behavior thus >>>> embedded_H >>>> as a simulating partial halt decider is NOT ALLOWED to report on the >>>> direct execution of Ĥ ⟨Ĥ⟩ because this IS REPORTING ON ITS OWN >>>> BEHAVIOR. >>> >>> WHO SAYS THIS? >> >> A decider must compute the mapping from an input. >> Its actual self cannot possibly be an input. > > Sure it can, at least when converted to the form you give the input in. > > A decide is tasked with computing an input to a function, that has been > given to it in the form (perhaps) of a description. The FUNCTION being > computed here is "Halting", and Halting take a machine and an input, and > maps it to a binary value of Halting or Non-Halting. > > A Halt Decider takes a description of that input, and nothing says that > input description can't be the description of the decider itself. > > If you want to use your arguement, NO decider can decide on any Turing > Machine, because we can't give any Turing Machine as a input, only a > description. > >> >> No decider takes an actual Turing machine as input thus >> no decider can possibly take its actual self as input. > > Algorithmic deciders frequent take their input in the form of a > description, and a > >> >> (a) The behavior of the directly executed Ĥ ⟨Ĥ⟩ is after >> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ has already aborted its simulation. > > Right, and that is the behavior that H is supposed to report on. > >> >> (b) The behavior of the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >> is before embedded_H has aborted its simulation. > > Which just shows that embedded_H doesn't do a "Correct Simulation" per > Computation Theory, so this simulation doesn't establish the actual > behavior "of the input" which is the behavior of the machine described > by it (since "inputs" don't HAVE behavior, only what they represent does). > >> >> (c) These two behaviors (a) and (b) ARE NOT THE SAME. (a) will stop >> running on its own (b) will never stop running unless aborted. > > But H isn't being asked about the simulation by H, but on the behavior > of the program descrtibed by the input. > EVERYONE HAS ALWAYS BEEN WRONG ON THIS BESIDES PROFESSOR SIPSER IT HAS NEVER EVER BEEN THE BEHAVIOR DESCRIBED BY THE INPUT IT HAS ALWAYS ALWAYS BEEN THE BEHAVIOR SPECIFIED BY THIS INPUT YOU AND OTHERS HAVE EVEN GONE TO THE EXTENT OF DIRECTLY DISAGREEING WITH THE ACTUAL SOFTWARE ITSELF. >> >> *THIS MAKES THE BEHAVIOR OF THE DIRECT EXECUTION* >> *AN INCORRECT MEASURE FOR PATHOLOGICAL INPUTS* >> > > Nope, just shows you don't understand the simple meaning of the > question, because you have lied to yourself so much you are believing > your own lies and made you incapable of understanding the truth. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer