Groups | Search | Server Info | Login | Register
| From | olcott <polcott2@gmail.com> |
|---|---|
| Newsgroups | comp.theory, sci.logic, comp.ai.philosophy |
| Subject | Re: Decidability Decider H |
| Date | 2023-07-04 16:52 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <u824bd$7am2$1@dont-email.me> (permalink) |
| References | (23 earlier) <vfMoM.805$8Ma1.346@fx37.iad> <u805a0$3vudj$2@dont-email.me> <nVMoM.17038$N3_4.6557@fx10.iad> <u808rm$ejg$1@dont-email.me> <u816nh$3v4u$2@dont-email.me> |
Cross-posted to 3 groups.
On 7/4/2023 8:27 AM, Richard Damon wrote: > On 7/4/23 12:57 AM, olcott wrote: >> On 7/3/2023 11:06 PM, Richard Damon wrote: >>> On 7/3/23 11:56 PM, olcott wrote: >>>> On 7/3/2023 10:22 PM, Richard Damon wrote: >>>>> On 7/3/23 10:20 PM, olcott wrote: >>>>>> On 7/3/2023 4:55 PM, Richard Damon wrote: >>>>>>> On 7/3/23 5:34 PM, olcott wrote: >>>>>>>> On 7/3/2023 4:17 PM, Richard Damon wrote: >>>>>>>>> On 7/3/23 4:22 PM, olcott wrote: >>>>>>>>>> On 7/3/2023 2:58 PM, Richard Damon wrote: >>>>>>>>>>> On 7/3/23 2:48 PM, olcott wrote: >>>>>>>>>>>> On 7/3/2023 1:25 PM, Richard Damon wrote: >>>>>>>>>>>>> On 7/3/23 1:57 PM, olcott wrote: >>>>>>>>>>>>>> On 7/3/2023 11:26 AM, Richard Damon wrote: >>>>>>>>>>>>>>> On 7/3/23 12:11 PM, olcott wrote: >>>>>>>>>>>>>>>> On 7/3/2023 11:01 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>> On 7/3/23 11:56 AM, olcott wrote: >>>>>>>>>>>>>>>>>> On 7/3/2023 10:35 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 7/3/23 10:45 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>> On 7/3/2023 9:24 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 7/3/23 9:47 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>> On 7/3/2023 8:14 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> A single H can consistently correctly >>>>>>>>>>>>>>>>>>>>>>>>>>>> determine whether or not its input >>>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to itself. When >>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D,D) is invoked in >>>>>>>>>>>>>>>>>>>>>>>>>>>> decidability decider mode determines that D >>>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to >>>>>>>>>>>>>>>>>>>>>>>>>>>> itself this enables a batch file to invoke >>>>>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual >>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the directly executed D(D). H1 >>>>>>>>>>>>>>>>>>>>>>>>>>>> is identical to H except for >>>>>>>>>>>>>>>>>>>>>>>>>>>> the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> And does an input D that uses this FULL >>>>>>>>>>>>>>>>>>>>>>>>>>> algorithm give your algorithm problems? >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Since H(D,D) will (apparently) determine that >>>>>>>>>>>>>>>>>>>>>>>>>>> the input is pathological, and thus defer to >>>>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D), then when we actually run D, >>>>>>>>>>>>>>>>>>>>>>>>>>> appearently it will get that same answer from >>>>>>>>>>>>>>>>>>>>>>>>>>> H1 and do the opposite of it, and thus H1 >>>>>>>>>>>>>>>>>>>>>>>>>>> will be wrong. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Remember, the "Pathological" program is built >>>>>>>>>>>>>>>>>>>>>>>>>>> on a copy of the ACTUAL program that you ask >>>>>>>>>>>>>>>>>>>>>>>>>>> to decide on it, including ALL of its >>>>>>>>>>>>>>>>>>>>>>>>>>> "tricks", including things like this "batch >>>>>>>>>>>>>>>>>>>>>>>>>>> processing". >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - >>>>>>>>>>>>>>>>>>>>>>>>>>> Input structure, but there isn't, at least >>>>>>>>>>>>>>>>>>>>>>>>>>> not one that can affect the answer of the >>>>>>>>>>>>>>>>>>>>>>>>>>> problem. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I spent 12 hours a day for the last 10 days >>>>>>>>>>>>>>>>>>>>>>>>>> getting the copy the input >>>>>>>>>>>>>>>>>>>>>>>>>> working. When H(D,D) (in decidability decider >>>>>>>>>>>>>>>>>>>>>>>>>> mode) detects that its >>>>>>>>>>>>>>>>>>>>>>>>>> input is in the well defined set of >>>>>>>>>>>>>>>>>>>>>>>>>> pathological inputs it returns 0 >>>>>>>>>>>>>>>>>>>>>>>>>> indicating that its input is undecidable. The >>>>>>>>>>>>>>>>>>>>>>>>>> batch file that invoked H >>>>>>>>>>>>>>>>>>>>>>>>>> then knows to invoke H1(D,D) to correctly >>>>>>>>>>>>>>>>>>>>>>>>>> report that D(D) halts. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This solution does seem to work correctly on >>>>>>>>>>>>>>>>>>>>>>>>>> every conventional proof in >>>>>>>>>>>>>>>>>>>>>>>>>> every textbook. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> So, did you make your "conventional proof" >>>>>>>>>>>>>>>>>>>>>>>>> template actually use a copy of your ACTUAL >>>>>>>>>>>>>>>>>>>>>>>>> decider (which seems to be your "batch file" >>>>>>>>>>>>>>>>>>>>>>>>> not the C funciton H), or are you just >>>>>>>>>>>>>>>>>>>>>>>>> admitting that you wasted 120 hours looking at >>>>>>>>>>>>>>>>>>>>>>>>> the wrong thing because you have made yourself >>>>>>>>>>>>>>>>>>>>>>>>> intentionally ignorant of the subject so you >>>>>>>>>>>>>>>>>>>>>>>>> don't understand what you are trying to do. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> New_D copies its input and simulates its input >>>>>>>>>>>>>>>>>>>>>>>> with its input. >>>>>>>>>>>>>>>>>>>>>>>> It never sees New_H. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Why not? Since New_H is the thing that is >>>>>>>>>>>>>>>>>>>>>>> considered the "Correct Halt Decider", New_D >>>>>>>>>>>>>>>>>>>>>>> needs to be built on it. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> New_H is embedded within New_D (as its middle >>>>>>>>>>>>>>>>>>>>>> states) just the >>>>>>>>>>>>>>>>>>>>>> way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>>>>>>>> New_H(New_H) halt? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The only difference at the source code level is: >>>>>>>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> So, how is New_H a halt decider then? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> typo >>>>>>>>>>>>>>>>>>>> The only difference at the source code level is: >>>>>>>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>>>>>>>> exactly New_H >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> But New_D needs to call New_H, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Not in the Peter Linz proof: >>>>>>>>>>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In the Linz proof a copy of H is directly embedded >>>>>>>>>>>>>>>>>> within Ĥ at this state: Ĥq0 Wm Wm >>>>>>>>>>>>>>>>>> The original H remains unchanged. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The halting problem is about undecidable inputs, it is >>>>>>>>>>>>>>>>>> not about >>>>>>>>>>>>>>>>>> inserting bugs into a halt decider to make it cease to >>>>>>>>>>>>>>>>>> function. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Right, and in Linz, H is the decider that is claimed to >>>>>>>>>>>>>>>>> give the right answer. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> That isn't 'H' in your system, but the script that >>>>>>>>>>>>>>>>> decides whether to use H or H1. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Your error is in calling the wrong thing 'H' >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> You are just showing you are lying by using the wrong >>>>>>>>>>>>>>>>> name for things. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You are using double-talk in a lame attempt to show that >>>>>>>>>>>>>>>> Linz H cannot correctly determine the halt status of >>>>>>>>>>>>>>>> Linz Ĥ. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So you agree with the Theorem. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No 'Linz H' can exist that correctly decides the halt >>>>>>>>>>>>>>> status of Linz Ĥ applied to the description of Linz Ĥ. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That is EXACTLY the consequence of the Halting Theorem. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please show an ACTUAL 'Linz H' that correctly gets the >>>>>>>>>>>>>>> results of the 'Linz Ĥ' built on it. You keep on changing >>>>>>>>>>>>>>> H and trying to use the old Ĥ which just fails to meet >>>>>>>>>>>>>>> the requirement of the proof, likely because you just >>>>>>>>>>>>>>> don't understand the theory involved. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It took me two years to figure out a clean way to copy the >>>>>>>>>>>>>> input to >>>>>>>>>>>>>> Linz_H_Hat and not have the system crash. Relative to >>>>>>>>>>>>>> Linz_H_Hat >>>>>>>>>>>>>> Linz_H is H1. Now Linz_H_Hat only contradicts itself. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> So, you are admitting that you actually can't do what is >>>>>>>>>>>>> required? >>>>>>>>>>>>> >>>>>>>>>>>>> Copying the input should be trivial, >>>>>>>>>>>> >>>>>>>>>>>> The relative addressing of the x86 language causes all function >>>>>>>>>>>> calls to call the wrong address. >>>>>>>>>>> >>>>>>>>>>> Only because you aren't interpreting the input properly, but >>>>>>>>>>> in a non-Turing Complete manner. >>>>>>>>>>> >>>>>>>>>>> As I said, the input description should be a chunck of code >>>>>>>>>>> in a virtual address space with a header that tells where >>>>>>>>>>> that code is supposed to be considered to be located at. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> as the input should be a representation that packages a >>>>>>>>>>>>> full program in its own virtual environment, so a simple >>>>>>>>>>>>> bit by bit copy to empty ram will work. Your problem is >>>>>>>>>>>>> that you don't put the input into its own virtual address >>>>>>>>>>>>> space, so you have pathological interactions. >>>>>>>>>>>>> >>>>>>>>>>>>> Linz_H_Hat must be built on the exact code base that is >>>>>>>>>>>>> deciding on it, in this case H, since you just said it >>>>>>>>>>>>> isn't, your proof is invalid. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Linz_Hat <is> Linz_H that takes one param and copies it >>>>>>>>>>>> instead of >>>>>>>>>>>> two params and has an infinite loop at its accept state. >>>>>>>>>>> >>>>>>>>>>> So, Two things that are different are exactly the same? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It exactly matches the Linz spec. >>>>>>>>>> >>>>>>>>>>> You don't seem to understand what you are doing. >>>>>>>>>>> >>>>>>>>>>> Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined >>>>>>>>>>> behavior. That behavior is a function of its input, but >>>>>>>>>>> hasn't been assigned any "meaning". >>>>>>>>>>> >>>>>>>>>>> Linz_H is a Turing Machine (if it actually can exist) that >>>>>>>>>>> has a defined meaning/requirement for its final states. >>>>>>>>>>> Linz_H, to meet its requirements, MUST go to Qy if the input >>>>>>>>>>> represents a Halting Computation, and MUST go to Qn if the >>>>>>>>>>> input represents a non-halting computation. >>>>>>>>>>> >>>>>>>>>>> Since Linz_H has actual requirements, a claimed >>>>>>>>>>> implementation of it can be checked to see if it actually >>>>>>>>>>> meets the requirements, and perhaps we can determine if it is >>>>>>>>>>> possible to meet them. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't >>>>>>>>>>>>> generate any truth values, only behavior. You are just >>>>>>>>>>>>> showing that you don't understand the basics of the >>>>>>>>>>>>> requirements, and seem to think that "close" is good enough >>>>>>>>>>>>> for proofs. >>>>>>>>>>>> >>>>>>>>>>>> Linz_H_Hat(Linz_H_Hat) returns 0. >>>>>>>>>>>> >>>>>>>>>>> > Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, >>>>>>>>>>> which has NO >>>>>>>>>>> defined meaning for Linz_H_Hat as it isn't defined to be a >>>>>>>>>>> decider. >>>>>>>>>> >>>>>>>>>> Linz_H and Linz_H_Hat are C functions. >>>>>>>>>> Linz:H and Linz:Ĥ are Turing machines. >>>>>>>>> >>>>>>>>> So, inventing new terminology without introduction, thus >>>>>>>>> showing you are being intentionally deceptive. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Linz_H and Linz:H are both directly embedded within a copy of >>>>>>>>>> Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition >>>>>>>>>> to Ĥ.qn still means not halting. >>>>>>>>> >>>>>>>>> No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so >>>>>>>>> there return value has no meaning. >>>>>>>>> >>>>>>>>> Ĥ has no meaning, so it can't be "incorrect" or contradicted. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> This allows Linz_H and Linz:H correctly report on the actual >>>>>>>>>> behavior of their input. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> No, since BOTH have an input that when run will HALT, and both >>>>>>>>> report that it will not, both are just wrong. >>>>>>>>> >>>>>>>>> Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0, >>>>>>>> *I never said that you are confused* >>>>>>> >>>>>>> You always claim that your H by its various names is "Correct" to >>>>>>> return 0 as the input is non-halting because its "correct >>>>>>> simulation" will never reach a final state. >>>>>>> >>>>>>> I think your brain is turning into mush, or is your pathology >>>>>>> overloading and trying to reverse the argument. >>>>>>> >>>>>>>> Linz_H_Hat(Linz_H_Hat) returns 0 permitting >>>>>>>> Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1. >>>>>>>> >>>>>>> >>>>>>> But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means >>>>>>> Halting, >>>>>> >>>>>> Linz_H_Hat has its own embedded_H that returns 0. >>>>>> Linz_H_Hat has no access to Linz_H, only to its own embedded copy. >>>>> >>>>> But embedded_H is an identical copy to Linz_H, so if embedded_H >>>>> returns 0, so does Lin >>>>> >>>>>> Linz_H simply simulates Linz_H_Hat until it terminates. >>>>> >>>>> Then so must embedded_H, since it is an identical copy, and as you >>>>> have shown before, if H is defined that way, the H_Hat will never >>>>> halt, and thus H, since for this case you said it doesn't abort, >>>>> will also never halt and fail to be a decider. >>>>> >>>> >>>> We have gone through this many hundreds of times. >>>> It is the exact same H(D,D) versus H1(D,D) thing. >>>> >>>> Linz_H_Hat now has a pathological relationship to itself >>>> this frees Linz_H from such a pathological relationship. >>>> So Linz_H becomes H1, and Linz_H_Hat becomes H. >>> >>> Nope, just shows you are not working in a Turing Equivalent system, >>> and thus NOTHING you say matters. >>> >> >> You can make such claims with bluster finding a source that actually >> supports them is a whole different matter. > > No, you are just showing that you believe Russell's Teapot actually > exists. YOU are the one making claims, so YOU are the one that needs to > make a actual proof of correctness, and show the error in the counter > claims. > If you believe that I am incorrect you need much more than your own presumption as a basis for an actual rebuttal. You might not have much more than this mere presumption. > It is a PROVEN fact that two computation machines with the exact same > algorithm and the exact same input will always produce the same result. > > You are claiming differently, WITHOUT PROOF, so you are shown to be a LIAR. > H1(D,D) and H(D,D) have different execution traces because D calls H and D does not call H1. A not very bright software engineer could understand this. > Either H and H1 are claimed to be the same machine, or they are not. If > they are the same machine, they need to give the same answer, or they > are not, and thus H1 getting the right answer to the H^ built on H > doesn't matter. > > >> It is the case that when embedded_H is a simulating termination analyzer >> applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that the simulated input cannot possibly terminate >> normally and must have its simulation aborted. > > So? > >> >> It is not the case the Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that its input must >> have its simulation terminated. > > Thus Linz:H and embedded_H aren't the same machine, as REQUIRED, thus > showing that you hav just been LYING for decades. It is a simple execution trace that even a bright high school student can understand now that I have shown it at the C source code level. >> >>>> >>>>> Now, since you are claiming that the embedded_H and Linz_H are >>>>> IDENTICAL machines, but the also produce DIFFERENT results when >>>>> given identical inputs, you have just proven that you are a LIAR. >>>> >>>> *So you are back to rejecting verified facts out-of-hand* >>>> It is a verified fact that H(D,D) returns 0 and H1(D,D) returns >>>> 1 and the only difference is that H1 does not have a pathological >>>> relationship to H and it is otherwise identical to H. >>>> >>> >>> Since youy refuse to provide the verification fact about where the >>> paths of H(D,D) and D(D) differ, you don't HAVE a "verified fact". >>> >> >> The source code and execution trace have been available for a year. >> I have explained this many times the problem seems to be that you simply >> don't believe the facts. You say that a simulation is incorrect yet >> cannot point to the instruction that was simulated incorrectly only >> because the simulation is actually correct. > > No, YOU LIE. The "Call H" instruction has been simulated incorrectly (or > not simulated at all an false presumptions about what it does used). > >> >>> You are just proving that you are just a LIAR and an IDIOT. >>> >>> What IS verified is that D(D) Halts, so H(D,D) returning 0 is BY >>> DEFINITION WRONG and you claim tha tit is right is a verified LIE. >>> >> >> It depends on how you frame the problem. >> If you frame the problem in that a halt decider must divide up finite >> strings pairs into those that halt when directly executed and those that >> do not, then no single program can do this. A pair of programs might do >> this. > > So, you agree with the Halting Theorem, as that it is the precise > problem being asked about. > >> >> If you frame the problem in that a halt decider must divide up finite >> stings into those that must have their simulation aborted to prevent >> their infinite execution, then from H's point of view D does not halt. > > > So, you are admitting to using a Strawman, and nothing you say applies > to the ACTUAL Halting Problem. > > You have maybe shown that POOP might be decidable, it at least can't use > the simple pathological example to show it, but POOP isn't about Halting > but partial simulation, so who cares about it. > > This shows your mental instability as we don't care about what H sees, > which is just something of its imagination, we care about the reality of > what D actually does. Just like we care about what is ACTUALLY true, > verses what you think must be true without actually trying to prove it > logically. It turns out that Linz_H(Linz_H_Hat, Linz_H_Hat) == 1 because Linz_H_Hat(Linz_H_Hat) == 0 This translates into Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly transitions to Linz:H.qy because Linz:Ĥ applied to ⟨Ĥ⟩ transitions to Linz:Ĥ.qn So I have overcome the issue of H(D,D) reporting non-halting and the directly executed D(D) then halting in two different ways: (1) Linz_H(Linz_H_Hat, Linz_H_Hat) reports halting and Linz_H_Hat(Linz_H_Hat) halts. (2) With the three value return of H(D,D) H only reports halting when its directly executed input actually halts and seems to defeat Rice by separately reporting all conventional halting problem proof pathological inputs. -- Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
Back to sci.logic | Previous | Next — Previous in thread | Next in thread | Find similar
Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-02 19:45 -0500
Re: Decidability Decider H Python <python@invalid.org> - 2023-07-03 03:11 +0200
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-02 21:27 -0400
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-02 21:40 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-02 21:01 -0500
Re: Decidability Decider H Python <python@invalid.org> - 2023-07-03 04:05 +0200
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-02 22:37 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-02 22:10 -0500
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-02 22:54 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 09:14 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 10:10 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 11:35 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 10:41 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 11:58 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 11:09 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 12:26 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 13:00 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 14:25 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 13:49 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 15:58 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 15:03 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 17:07 -0400
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 09:13 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 09:42 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 11:35 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 10:44 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 11:58 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 11:05 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 12:26 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 13:03 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 14:25 -0400
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 14:25 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 13:56 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 15:58 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 15:08 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 17:07 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 16:30 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 17:34 -0400
Re: Decidability Decider H [key Rice issue] olcott <polcott2@gmail.com> - 2023-07-03 16:40 -0500
Re: Decidability Decider H [key Rice issue] Richard Damon <Richard@Damon-Family.org> - 2023-07-03 17:55 -0400
Re: Decidability Decider H [key Rice issue] olcott <polcott2@gmail.com> - 2023-07-03 20:51 -0500
Re: Decidability Decider H [key Rice issue] Richard Damon <Richard@Damon-Family.org> - 2023-07-03 23:22 -0400
Re: Decidability Decider H [key Rice issue] olcott <polcott2@gmail.com> - 2023-07-03 22:47 -0500
Re: Decidability Decider H [key Rice issue] Richard Damon <Richard@Damon-Family.org> - 2023-07-04 00:06 -0400
Re: Decidability Decider H [key Rice issue] olcott <polcott2@gmail.com> - 2023-07-03 23:35 -0500
Re: Decidability Decider H [key Rice issue] Richard Damon <news.x.richarddamon@xoxy.net> - 2023-07-04 09:27 -0400
Re: Decidability Decider H [key Rice issue] olcott <polcott2@gmail.com> - 2023-07-04 16:32 -0500
Re: Decidability Decider H [key Rice issue] Richard Damon <Richard@Damon-Family.org> - 2023-07-04 19:00 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 15:45 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 17:07 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 16:19 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 17:31 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 16:36 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 17:55 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 21:28 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 23:22 -0400
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 11:58 -0400
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-02 22:41 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-02 21:48 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 09:14 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 08:47 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 10:24 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 09:45 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 11:35 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 10:56 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 12:01 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 11:11 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 12:26 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 12:57 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 14:25 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 13:48 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 15:58 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 15:22 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 17:17 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 16:34 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 17:55 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 21:20 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-03 23:22 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 22:56 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-04 00:06 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-03 23:57 -0500
Re: Decidability Decider H Richard Damon <news.x.richarddamon@xoxy.net> - 2023-07-04 09:27 -0400
Re: Decidability Decider H olcott <polcott2@gmail.com> - 2023-07-04 16:52 -0500
Re: Decidability Decider H Richard Damon <Richard@Damon-Family.org> - 2023-07-04 19:00 -0400
csiph-web