Groups | Search | Server Info | Login | Register
| Subject | Re: Decidability Decider H |
|---|---|
| Newsgroups | comp.theory, sci.logic, comp.ai.philosophy |
| References | (14 earlier) <u7v25c$3opqe$1@dont-email.me> <goEoM.152$_2s1.40@fx44.iad> <u7v557$3p4d9$1@dont-email.me> <KLFoM.17237$W7d4.13308@fx18.iad> <u7van2$3ppvb$1@dont-email.me> |
| From | Richard Damon <Richard@Damon-Family.org> |
| Message-ID | <DVGoM.4990$zQS.3689@fx41.iad> (permalink) |
| Organization | Forte - www.forteinc.com |
| Date | 2023-07-03 17:17 -0400 |
Cross-posted to 3 groups.
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, indicating non=-halting. But when Linz_H_Hat calls Linz_H(Linz_H_Hat, Linz_H_Hat) and gets that returned 0, it Halts, so Linz_H is just wrong. You like to clai that Linz_H won't return that answer but it MUST as is needs to be a computation that only depends on its input, so it MUST always do the same thing. You have been asked before, show the first step in the direct execution of Linz_H(Linz_H_Hat, Linz_H_Hat) and the same call from within Linz_H_Hat that have different behavior, even though everything before them has been identical since the call to Linz_H. Until you provide this, you are just showing you are just a stupid pathological liar that claims impossible things must be true.
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