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-03 16:34 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <u7vess$3q766$2@dont-email.me> (permalink) |
| References | (15 earlier) <goEoM.152$_2s1.40@fx44.iad> <u7v557$3p4d9$1@dont-email.me> <KLFoM.17237$W7d4.13308@fx18.iad> <u7van2$3ppvb$1@dont-email.me> <DVGoM.4990$zQS.3689@fx41.iad> |
Cross-posted to 3 groups.
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* Linz_H_Hat(Linz_H_Hat) returns 0 permitting Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1. -- 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