Groups | Search | Server Info | Login | Register
| Subject | Re: Decidability Decider H |
|---|---|
| Newsgroups | comp.theory, sci.logic, comp.ai.philosophy |
| References | (12 earlier) <u7us05$3o3bd$3@dont-email.me> <QECoM.21249$Bq67.11078@fx13.iad> <u7v25c$3opqe$1@dont-email.me> <goEoM.152$_2s1.40@fx44.iad> <u7v557$3p4d9$1@dont-email.me> |
| From | Richard Damon <Richard@Damon-Family.org> |
| Message-ID | <KLFoM.17237$W7d4.13308@fx18.iad> (permalink) |
| Organization | Forte - www.forteinc.com |
| Date | 2023-07-03 15:58 -0400 |
Cross-posted to 3 groups.
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? 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_Hat USES decider to determine its behavior, but its behavior doesn't have any defined "meaning" about anything. Note, since H has requirements, we can check if it meet them. Since you say that Linz_H applied to Linz_H_Hat Linz_H_Hat will "correctly" go to Qn to say that its input is non-halting, and we know that Linz_H_Hat ends with a copy of Linz_H and a tape that has Linz_H_Hat Linz_H_Hat we know that this copy will ALSO go to Qn, which is still a final state of Linz_H_Hat, so Linz_H_Hat applied to Linz_H_Hat will halt, which is the meaning of the input applied to Linz_H. This means that Linz_H applied to Linz_H_Hat Linz_H_Hat, to meet its requirement MUST go to Qy to say its input represents a Halting Computation, thus we show that your Linz_H just FAILS to meet its requirements. Linz_H_Hat, on the other hand, had no "requirements" it needed to meet, except to act like it was programmed (to act contrary to the answer it gets from H) which it did, so there is nothing wrong with Linz_H_Hat. Note, you can't get a "Contradiction" when the behavior has no meaning. You seem to want to embed into H_Hat some meaning, but it just doesn't have it. The only behavior with meaning is the behavior of H (including the copy with H_Hat, but that isn't transfered to maining of H_Hat itself).
Back to comp.theory | 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