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 22:56 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <u805a0$3vudj$2@dont-email.me> (permalink) |
| References | (19 earlier) <DVGoM.4990$zQS.3689@fx41.iad> <u7vess$3q766$2@dont-email.me> <ztHoM.4993$zQS.3002@fx41.iad> <u7vvlt$3vdfm$1@dont-email.me> <vfMoM.805$8Ma1.346@fx37.iad> |
Cross-posted to 3 groups.
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. > 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. -- 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