Groups | Search | Server Info | Login | Register

Groups > comp.theory > #65332

Re: Decidability Decider H

From olcott <polcott2@gmail.com>
Newsgroups comp.theory, sci.logic, comp.ai.philosophy
Subject Re: Decidability Decider H
Date 2023-07-03 21:20 -0500
Organization A noiseless patient Spider
Message-ID <u7vvlt$3vdfm$1@dont-email.me> (permalink)
References (17 earlier) <KLFoM.17237$W7d4.13308@fx18.iad> <u7van2$3ppvb$1@dont-email.me> <DVGoM.4990$zQS.3689@fx41.iad> <u7vess$3q766$2@dont-email.me> <ztHoM.4993$zQS.3002@fx41.iad>

Cross-posted to 3 groups.

Show all headers | View raw

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.
Linz_H simply simulates Linz_H_Hat until it terminates.

> it 
> means that Linz_H_Hat will go into the infinte loop on the Qy leg.
> 
> Did you miss that parto of the design in Linz's proof. H^ has modified 
> the end of H so that Qy becomes a non-terminal state.
> 
> Linz_H_Hat doesn't actually "return" a value, it just goes to Qn and 

Linz_H_Hat is a C function Linz:Ĥ is a Turing machine.
They use the exact same algorithm.

> halt or never halts.
> 

-- 
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

Thread

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