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 15:22 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <u7van2$3ppvb$1@dont-email.me> (permalink) |
| References | (13 earlier) <QECoM.21249$Bq67.11078@fx13.iad> <u7v25c$3opqe$1@dont-email.me> <goEoM.152$_2s1.40@fx44.iad> <u7v557$3p4d9$1@dont-email.me> <KLFoM.17237$W7d4.13308@fx18.iad> |
Cross-posted to 3 groups.
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. 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. This allows Linz_H and Linz:H correctly report on the actual behavior of their input. -- 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 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