Groups | Search | Server Info | Login | Register
| Subject | Re: Decidability Decider H |
|---|---|
| Newsgroups | comp.theory, sci.logic, comp.ai.philosophy |
| References | (20 earlier) <u7vess$3q766$2@dont-email.me> <ztHoM.4993$zQS.3002@fx41.iad> <u7vvlt$3vdfm$1@dont-email.me> <vfMoM.805$8Ma1.346@fx37.iad> <u805a0$3vudj$2@dont-email.me> |
| From | Richard Damon <Richard@Damon-Family.org> |
| Message-ID | <nVMoM.17038$N3_4.6557@fx10.iad> (permalink) |
| Organization | Forte - www.forteinc.com |
| Date | 2023-07-04 00:06 -0400 |
Cross-posted to 3 groups.
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. > >> 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". 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.
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