Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.theory > #52968

Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ]

From Mr Flibble <flibble@reddwarf.jmc>
Newsgroups comp.theory, comp.ai.philosophy, sci.logic, sci.math
Subject Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ]
Message-ID <20220625201852.00001c98@reddwarf.jmc> (permalink)
References (13 earlier) <S8udnWTpo617qir_nZ2dnUU7_8zNnZ2d@giganews.com> <bf7c8dfe-4551-4589-a273-d0dff16a87a0n@googlegroups.com> <w6GdnTS8QYHH1ir_nZ2dnUU7_83NnZ2d@giganews.com> <bf62d3d3-2adb-4546-a6d7-dd5bcca2a611n@googlegroups.com> <udWdnT9pv9NZwyr_nZ2dnUU7_8zNnZ2d@giganews.com>
Organization Jupiter Mining Corp
Date 2022-06-25 20:18 +0100

Cross-posted to 4 groups.

Show all headers | View raw


On Sat, 25 Jun 2022 14:15:15 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 1:58 PM, Paul N wrote:
> > On Saturday, June 25, 2022 at 6:52:33 PM UTC+1, olcott wrote:  
> >> On 6/25/2022 12:21 PM, Paul N wrote:  
> >>> On Saturday, June 25, 2022 at 5:29:33 PM UTC+1, olcott wrote:  
> >>>> On 6/25/2022 11:19 AM, Paul N wrote:  
> >>>>> On Saturday, June 25, 2022 at 3:10:50 PM UTC+1, olcott wrote:  
> >>>>>> On 6/25/2022 6:56 AM, Paul N wrote:  
> >>>>>>> On Friday, June 24, 2022 at 9:27:27 PM UTC+1, olcott wrote:  
> >>>>>>>> On 6/24/2022 3:05 PM, Paul N wrote:  
> >>>>>>>>> On Friday, June 24, 2022 at 7:52:22 PM UTC+1, olcott wrote:
> >>>>>>>>>  
> >>>>>>>>>> On 6/22/2022 9:23 PM, Dennis Bush wrote:  
> >>>>>>>>>>> On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott
> >>>>>>>>>>> wrote:  
> >>>>>>>>>>>> On 6/22/2022 8:44 PM, Dennis Bush wrote:  
> >>>>>>>>>>>>> On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott
> >>>>>>>>>>>>> wrote:  
> >>>>>>>>>>>>>> On 6/22/2022 8:21 PM, Dennis Bush wrote:  
> >>>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4,
> >>>>>>>>>>>>>>> olcott wrote:  
> >>>>>>>>>>>>>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:  
> >>>>>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4,
> >>>>>>>>>>>>>>>>> olcott wrote:  
> >>>>>>>>>>>>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:  
> >>>>>>>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4,
> >>>>>>>>>>>>>>>>>>> olcott wrote:  
> >>>>>>>>>>>>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:  
> >>>>>>>>>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM
> >>>>>>>>>>>>>>>>>>>>> UTC-4, olcott wrote:  
> >>>>>>>>>>>>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:  
> >>>>>>>>>>>>>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
> >>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:  
> >>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>>>>>>>>>> #include <stdint.h>
> >>>>>>>>>>>>>>>>>>>>>>>>>> #define u32 uint32_t
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> #include <stdint.h>
> >>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d2](01) 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010ec](01) c3 ret
> >>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Every sufficiently competent software
> >>>>>>>>>>>>>>>>>>>>>>>>>> engineer can easily verify that the
> >>>>>>>>>>>>>>>>>>>>>>>>>> complete and correct x86 emulation of the
> >>>>>>>>>>>>>>>>>>>>>>>>>> input to H(P,P) by H would never reach the
> >>>>>>>>>>>>>>>>>>>>>>>>>> "ret" instruction of P because both H and
> >>>>>>>>>>>>>>>>>>>>>>>>>> P would remain stuck in infinitely
> >>>>>>>>>>>>>>>>>>>>>>>>>> recursive emulation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> If H does correctly determine that this is
> >>>>>>>>>>>>>>>>>>>>>>>>>> the case in a finite number of steps then
> >>>>>>>>>>>>>>>>>>>>>>>>>> H could reject its input on this basis.
> >>>>>>>>>>>>>>>>>>>>>>>>>> Here are the details of exactly how H does
> >>>>>>>>>>>>>>>>>>>>>>>>>> this in a finite number of steps.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> typedef struct Decoded
> >>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>> u32 Address;
> >>>>>>>>>>>>>>>>>>>>>>>>>> u32 ESP; // Current value of ESP
> >>>>>>>>>>>>>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
> >>>>>>>>>>>>>>>>>>>>>>>>>> u32 NumBytes;
> >>>>>>>>>>>>>>>>>>>>>>>>>> u32 Simplified_Opcode;
> >>>>>>>>>>>>>>>>>>>>>>>>>> u32 Decode_Target;
> >>>>>>>>>>>>>>>>>>>>>>>>>> } Decoded_Line_Of_Code;
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
> >>>>>>>>>>>>>>>>>>>>>>>>>> address address data code language
> >>>>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== =========
> >>>>>>>>>>>>>>>>>>>>>>>>>> =============
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov
> >>>>>>>>>>>>>>>>>>>>>>>>>> ebp,esp [000010d5][00211e8a][00211e8e]
> >>>>>>>>>>>>>>>>>>>>>>>>>> 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax
> >>>>>>>>>>>>>>>>>>>>>>>>>> // push P [000010d9][00211e86][000010d2]
> >>>>>>>>>>>>>>>>>>>>>>>>>> 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx
> >>>>>>>>>>>>>>>>>>>>>>>>>> // push P [000010dd][00211e7e][000010e2]
> >>>>>>>>>>>>>>>>>>>>>>>>>> e820feffff call 00000f02 // call H
> >>>>>>>>>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected
> >>>>>>>>>>>>>>>>>>>>>>>>>> Simulation Stopped
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> // actual fully operational code in the
> >>>>>>>>>>>>>>>>>>>>>>>>>> x86utm operating system u32 H(u32 P, u32 I)
> >>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>> HERE:
> >>>>>>>>>>>>>>>>>>>>>>>>>> u32 End_Of_Code;
> >>>>>>>>>>>>>>>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
> >>>>>>>>>>>>>>>>>>>>>>>>>> u32 code_end = get_code_end(P);
> >>>>>>>>>>>>>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded =
> >>>>>>>>>>>>>>>>>>>>>>>>>> (Decoded_Line_Of_Code*)
> >>>>>>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
> >>>>>>>>>>>>>>>>>>>>>>>>>> Registers* master_state = (Registers*)
> >>>>>>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers)); Registers*
> >>>>>>>>>>>>>>>>>>>>>>>>>> slave_state = (Registers*)
> >>>>>>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers)); u32*
> >>>>>>>>>>>>>>>>>>>>>>>>>> slave_stack = Allocate(0x10000); // 64k;
> >>>>>>>>>>>>>>>>>>>>>>>>>> u32 execution_trace =
> >>>>>>>>>>>>>>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
> >>>>>>>>>>>>>>>>>>>>>>>>>> * 1000);
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
> >>>>>>>>>>>>>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
> >>>>>>>>>>>>>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
> >>>>>>>>>>>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
> >>>>>>>>>>>>>>>>>>>>>>>>>> __asm mov End_Of_Code, eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); //
> >>>>>>>>>>>>>>>>>>>>>>>>>> 2022-06-11 Init_slave_state(P, I,
> >>>>>>>>>>>>>>>>>>>>>>>>>> End_Of_Code, slave_state, slave_stack);
> >>>>>>>>>>>>>>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace
> >>>>>>>>>>>>>>>>>>>>>>>>>> Stored at:", execution_trace); if
> >>>>>>>>>>>>>>>>>>>>>>>>>> (Decide_Halting(&execution_trace,
> >>>>>>>>>>>>>>>>>>>>>>>>>> &decoded, code_end, &master_state,
> >>>>>>>>>>>>>>>>>>>>>>>>>> &slave_state, &slave_stack, Address_of_H,
> >>>>>>>>>>>>>>>>>>>>>>>>>> P, I)) goto END_OF_CODE; return 0; // Does
> >>>>>>>>>>>>>>>>>>>>>>>>>> not halt END_OF_CODE: return 1; // Input
> >>>>>>>>>>>>>>>>>>>>>>>>>> has normally terminated }
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> H knows its own machine address and on
> >>>>>>>>>>>>>>>>>>>>>>>>>> this basis it can easily examine its
> >>>>>>>>>>>>>>>>>>>>>>>>>> stored execution_trace of P and determine:
> >>>>>>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments
> >>>>>>>>>>>>>>>>>>>>>>>>>> that H was called with. (b) No
> >>>>>>>>>>>>>>>>>>>>>>>>>> instructions in P could possibly escape
> >>>>>>>>>>>>>>>>>>>>>>>>>> this otherwise infinitely recursive
> >>>>>>>>>>>>>>>>>>>>>>>>>> emulation. (c) H aborts its emulation of P
> >>>>>>>>>>>>>>>>>>>>>>>>>> before its call to H is invoked.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Technically competent software engineers
> >>>>>>>>>>>>>>>>>>>>>>>>>> may not know this computer science:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping
> >>>>>>>>>>>>>>>>>>>>>>>>>> from its inputs to an accept or reject
> >>>>>>>>>>>>>>>>>>>>>>>>>> state on the basis of the actual behavior
> >>>>>>>>>>>>>>>>>>>>>>>>>> that is actually specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> computation that halts … the Turing
> >>>>>>>>>>>>>>>>>>>>>>>>>> machine will halt whenever it enters a
> >>>>>>>>>>>>>>>>>>>>>>>>>> final state. (Linz:1990:234)
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> The "ret" instruction of P is its final
> >>>>>>>>>>>>>>>>>>>>>>>>>> state.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to
> >>>>>>>>>>>>>>>>>>>>>>>>>> Formal Languages and Automata.
> >>>>>>>>>>>>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and
> >>>>>>>>>>>>>>>>>>>>>>>>>> Company. (317-320) 
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> void Px(u32 x)
> >>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>> H(x, x);
> >>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px,
> >>>>>>>>>>>>>>>>>>>>>>>>> (u32)Px)); }
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408
> >>>>>>>>>>>>>>>>>>>>>>>>> add esp,+08
> >>>>>>>>>>>>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push
> >>>>>>>>>>>>>>>>>>>>>>>>> eax ...[000013ec][0010234f][00000427]
> >>>>>>>>>>>>>>>>>>>>>>>>> 6827040000 push 00000427
> >>>>>>>>>>>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427]
> >>>>>>>>>>>>>>>>>>>>>>>>> e880f0ffff call 00000476 Input_Halts = 0
> >>>>>>>>>>>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408
> >>>>>>>>>>>>>>>>>>>>>>>>> add esp,+08
> >>>>>>>>>>>>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor
> >>>>>>>>>>>>>>>>>>>>>>>>> eax,eax ...[000013fb][0010235b][00100000]
> >>>>>>>>>>>>>>>>>>>>>>>>> 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
> >>>>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120)
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> It gets the answer wrong, i.e. input has
> >>>>>>>>>>>>>>>>>>>>>>>>> not been decided correctly. QED.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> You and Richard are insufficiently
> >>>>>>>>>>>>>>>>>>>>>>>> technically competent at software
> >>>>>>>>>>>>>>>>>>>>>>>> engineering not meeting these specs:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> A software engineer must be an expert in:
> >>>>>>>>>>>>>>>>>>>>>>>> the C programming language, the x86
> >>>>>>>>>>>>>>>>>>>>>>>> programming language, exactly how C
> >>>>>>>>>>>>>>>>>>>>>>>> translates into x86 and the ability to
> >>>>>>>>>>>>>>>>>>>>>>>> recognize infinite recursion at the x86
> >>>>>>>>>>>>>>>>>>>>>>>> assembly language level. No knowledge of the
> >>>>>>>>>>>>>>>>>>>>>>>> halting problem is required.  
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I cannot speak for Richard but I have 30+
> >>>>>>>>>>>>>>>>>>>>>>> years C++ experience; I also have C and x86
> >>>>>>>>>>>>>>>>>>>>>>> assembly experience (I once wrote a Zilog
> >>>>>>>>>>>>>>>>>>>>>>> Z80A CPU emulator in 80286 assembly) and I
> >>>>>>>>>>>>>>>>>>>>>>> can recognize an infinite recursion; the
> >>>>>>>>>>>>>>>>>>>>>>> problem is that you cannot recognize the fact
> >>>>>>>>>>>>>>>>>>>>>>> that the infinite recursion only manifests as
> >>>>>>>>>>>>>>>>>>>>>>> part of your invalid simulation-based
> >>>>>>>>>>>>>>>>>>>>>>> omnishambles:  
> >>>>>>>>>>>>>>>>>>>>>> If you are competent then you already know
> >>>>>>>>>>>>>>>>>>>>>> this is true and lie about it: Every
> >>>>>>>>>>>>>>>>>>>>>> sufficiently competent software engineer can
> >>>>>>>>>>>>>>>>>>>>>> easily verify that the complete and correct
> >>>>>>>>>>>>>>>>>>>>>> x86 emulation of the input to H(Px,Px) by H
> >>>>>>>>>>>>>>>>>>>>>> would never reach the "ret" instruction of P
> >>>>>>>>>>>>>>>>>>>>>> because both H and P would remain stuck in
> >>>>>>>>>>>>>>>>>>>>>> infinitely recursive emulation.  
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> H (if it was constructed correctly) is a
> >>>>>>>>>>>>>>>>>>>>> computation, and a computation *always* gives
> >>>>>>>>>>>>>>>>>>>>> the same output for a given input. So it
> >>>>>>>>>>>>>>>>>>>>> doesn't make sense to say what it "would" do.
> >>>>>>>>>>>>>>>>>>>>> It either does or does not perform a complete
> >>>>>>>>>>>>>>>>>>>>> and correct emulation. And because H contains
> >>>>>>>>>>>>>>>>>>>>> code to abort, and does abort, it does not do a
> >>>>>>>>>>>>>>>>>>>>> complete emulation.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> So the input must be given to a UTM, which by
> >>>>>>>>>>>>>>>>>>>>> definition does a correct and complete
> >>>>>>>>>>>>>>>>>>>>> simulation, to see what the actual behavior is.
> >>>>>>>>>>>>>>>>>>>>> UTM(Px,Px) halts, therefore H(Px,Px)==0 is
> >>>>>>>>>>>>>>>>>>>>> wrong.  
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Every sufficiently competent software engineer
> >>>>>>>>>>>>>>>>>>>> can easily verify that the complete and correct
> >>>>>>>>>>>>>>>>>>>> x86 emulation of the input to H(Px,Px) by H
> >>>>>>>>>>>>>>>>>>>> would never reach the "ret" instruction of Px
> >>>>>>>>>>>>>>>>>>>> because both H and Px would remain stuck in
> >>>>>>>>>>>>>>>>>>>> infinitely recursive emulation.  
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> So you just repeated what you said instead of
> >>>>>>>>>>>>>>>>>>> explaining why I'm wrong. In other words you
> >>>>>>>>>>>>>>>>>>> provided no rebuttal, which can only be taken to
> >>>>>>>>>>>>>>>>>>> mean that you have none.  
> >>>>>>>>>>>>>>>>>> Your entire basis and all of assumptions was
> >>>>>>>>>>>>>>>>>> incorrect so when I provided an infallible one to
> >>>>>>>>>>>>>>>>>> that cannot possibly be correctly refuted you
> >>>>>>>>>>>>>>>>>> simply dodged it. That is a smart move for a
> >>>>>>>>>>>>>>>>>> dishonest person that is only interested in
> >>>>>>>>>>>>>>>>>> rebuttal.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I dare you to go back to the prior post and find
> >>>>>>>>>>>>>>>>>> any error in my airtight correct reasoning.
> >>>>>>>>>>>>>>>>>> Another dodge will be construed as a tacit
> >>>>>>>>>>>>>>>>>> admission of defeat.  
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> As stated before H (or more accurately Ha) does not
> >>>>>>>>>>>>>>>>> perform a complete and correct emulation because it
> >>>>>>>>>>>>>>>>> aborts. So by definition it cannot be complete.  
> >>>>>>>>>>>>>>>> I never claimed that H(P,P) performs a complete and
> >>>>>>>>>>>>>>>> correct emulation of its input so your rebuttal is
> >>>>>>>>>>>>>>>> the strawman deception.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I claimed that H(P,P) correctly predicts that its
> >>>>>>>>>>>>>>>> complete and correct x86 emulation of its input
> >>>>>>>>>>>>>>>> would never reach the "ret" instruction of P.  
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But since H, or more accurately Ha, *can't* do a
> >>>>>>>>>>>>>>> correct and complete emulation of its input, your
> >>>>>>>>>>>>>>> point is moot.  
> >>>>>>>>>>>>>> _Infinite_Loop()
> >>>>>>>>>>>>>> [00001082](01) 55 push ebp
> >>>>>>>>>>>>>> [00001083](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>> [00001085](02) ebfe jmp 00001085
> >>>>>>>>>>>>>> [00001087](01) 5d pop ebp
> >>>>>>>>>>>>>> [00001088](01) c3 ret
> >>>>>>>>>>>>>> Size in bytes:(0007) [00001088]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Begin Local Halt Decider Simulation Execution Trace
> >>>>>>>>>>>>>> Stored at:211e8f ...[00001082][00211e7f][00211e83] 55
> >>>>>>>>>>>>>> push ebp ...[00001083][00211e7f][00211e83] 8bec mov
> >>>>>>>>>>>>>> ebp,esp ...[00001085][00211e7f][00211e83] ebfe jmp
> >>>>>>>>>>>>>> 00001085 ...[00001085][00211e7f][00211e83] ebfe jmp
> >>>>>>>>>>>>>> 00001085 Infinite Loop Detected Simulation Stopped
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On the basis of this exact same utterly moronic
> >>>>>>>>>>>>>> reasoning because H *can't* do a correct and complete
> >>>>>>>>>>>>>> emulation of its input, H cannot possibly determine
> >>>>>>>>>>>>>> that _Infinite_Loop() never halts.  
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Now who's using the strawman error? Just because H can
> >>>>>>>>>>>>> determine that _Infinite_Loop does not halt doesn't
> >>>>>>>>>>>>> mean that it gets other cases right. B  
> >>>>>>>>>>>> You just said that H(P,P) cannot correctly predict that
> >>>>>>>>>>>> the correct and complete x86 emulation of its input
> >>>>>>>>>>>> would never reach the "ret" instruction of P without a
> >>>>>>>>>>>> compete x86 emulation of its input. I just proved that
> >>>>>>>>>>>> is a very stupid thing to say.  
> >>>>>>>>>>>
> >>>>>>>>>>> You said that H can predict what *its* correct and
> >>>>>>>>>>> complete emulation would do, and I said that doesn't make
> >>>>>>>>>>> sense because H does not do correct and complete
> >>>>>>>>>>> emulation. What H *must* do is predict what *the* correct
> >>>>>>>>>>> and complete emulation, i.e. UTM(P,P), would do. And it
> >>>>>>>>>>> fails to do that.  
> >>>>>>>>>>  From a purely software engineering perspective H(P,P) is
> >>>>>>>>>> required to to correctly determine that its correct and
> >>>>>>>>>> complete x86 emulation of its input would never reach the
> >>>>>>>>>> "ret" instruction of this input and H must do this in a
> >>>>>>>>>> finite number of steps.
> >>>>>>>>>>
> >>>>>>>>>> The ordinary semantics of standard C and the conventional
> >>>>>>>>>> x86 language are the entire semantics required to
> >>>>>>>>>> conclusively prove that H(P,P) does correctly determine
> >>>>>>>>>> that its correct and complete x86 emulation of its input
> >>>>>>>>>> would never reach the "ret" instruction.
> >>>>>>>>>>
> >>>>>>>>>> That you disagree with easily verified software
> >>>>>>>>>> engineering when you already know that this software
> >>>>>>>>>> engineering is correct speaks loads about your character.
> >>>>>>>>>>
> >>>>>>>>>> The only computer science that need be added to this is
> >>>>>>>>>> that the "ret" instruction is the final state of P and
> >>>>>>>>>> that a sequence of configurations that cannot possibly
> >>>>>>>>>> reach its final state is a non-halting sequence.  
> >>>>>>>>>
> >>>>>>>>> You say that "H(P,P) is required to to correctly determine
> >>>>>>>>> that its correct and complete x86 emulation of its input
> >>>>>>>>> would never reach the "ret" instruction of this input". You
> >>>>>>>>> seem to be assuming that H does an emulation of P, that
> >>>>>>>>> this emulation includes emulating the call to H, that this
> >>>>>>>>> call to H would start emulating the call to P, etc, etc,
> >>>>>>>>> and so the call to P does not terminate. 
> >>>>>>>> Thanks for continuing to review this.
> >>>>>>>>
> >>>>>>>> No assumptions two years of software development derived
> >>>>>>>> fully operational software that conclusively proves this.  
> >>>>>>>
> >>>>>>> It might help people's understanding if we had a few more
> >>>>>>> examples. Suppose, in addition to the normal P and H, we have
> >>>>>>> two more functions as follows:
> >>>>>>>
> >>>>>>> void Q(void)
> >>>>>>> {
> >>>>>>> if (H(P, P))
> >>>>>>> H2: goto H2;
> >>>>>>> return;
> >>>>>>> }
> >>>>>>>
> >>>>>>> void R(void)
> >>>>>>> {
> >>>>>>> H(P, P);
> >>>>>>> return;
> >>>>>>> }
> >>>>>>>
> >>>>>>> Will Q return? Will R return?
> >>>>>>>  
> >>>>>> Yes they both return.
> >>>>>> void Q(void)
> >>>>>> {
> >>>>>> if (H(P, P))
> >>>>>> H2: goto H2;
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> void R(void)
> >>>>>> {
> >>>>>> H(P, P);
> >>>>>> return;
> >>>>>> }
> >>>>>> _P()
> >>>>>> [000011f0](01) 55 push ebp
> >>>>>> [000011f1](02) 8bec mov ebp,esp
> >>>>>> [000011f3](03) 8b4508 mov eax,[ebp+08]
> >>>>>> [000011f6](01) 50 push eax
> >>>>>> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>> [000011fa](01) 51 push ecx
> >>>>>> [000011fb](05) e820feffff call 00001020
> >>>>>> [00001200](03) 83c408 add esp,+08
> >>>>>> [00001203](02) 85c0 test eax,eax
> >>>>>> [00001205](02) 7402 jz 00001209
> >>>>>> [00001207](02) ebfe jmp 00001207
> >>>>>> [00001209](01) 5d pop ebp
> >>>>>> [0000120a](01) c3 ret
> >>>>>> Size in bytes:(0027) [0000120a]
> >>>>>>
> >>>>>> _Q()
> >>>>>> [00001210](01) 55 push ebp
> >>>>>> [00001211](02) 8bec mov ebp,esp
> >>>>>> [00001213](05) 68f0110000 push 000011f0
> >>>>>> [00001218](05) 68f0110000 push 000011f0
> >>>>>> [0000121d](05) e8fefdffff call 00001020
> >>>>>> [00001222](03) 83c408 add esp,+08
> >>>>>> [00001225](02) 85c0 test eax,eax
> >>>>>> [00001227](02) 7402 jz 0000122b
> >>>>>> [00001229](02) ebfe jmp 00001229
> >>>>>> [0000122b](01) 5d pop ebp
> >>>>>> [0000122c](01) c3 ret
> >>>>>> Size in bytes:(0029) [0000122c]
> >>>>>>
> >>>>>> _main()
> >>>>>> [00001250](01) 55 push ebp
> >>>>>> [00001251](02) 8bec mov ebp,esp
> >>>>>> [00001253](05) e8b8ffffff call 00001210
> >>>>>> [00001258](02) 33c0 xor eax,eax
> >>>>>> [0000125a](01) 5d pop ebp
> >>>>>> [0000125b](01) c3 ret
> >>>>>> Size in bytes:(0012) [0000125b]
> >>>>>> machine stack stack machine assembly
> >>>>>> address address data code language
> >>>>>> ======== ======== ======== ========= =============
> >>>>>> ...[00001250][00102048][00000000] 55 push ebp
> >>>>>> ...[00001251][00102048][00000000] 8bec mov ebp,esp
> >>>>>> ...[00001253][00102044][00001258] e8b8ffffff call 00001210
> >>>>>> ...[00001210][00102040][00102048] 55 push ebp
> >>>>>> ...[00001211][00102040][00102048] 8bec mov ebp,esp
> >>>>>> ...[00001213][0010203c][000011f0] 68f0110000 push 000011f0
> >>>>>> ...[00001218][00102038][000011f0] 68f0110000 push 000011f0
> >>>>>> ...[0000121d][00102034][00001222] e8fefdffff call 00001020
> >>>>>>
> >>>>>> Begin Simulation Execution Trace Stored at:2120fc
> >>>>>> Address_of_H:1020
> >>>>>> ...[000011f0][002120e8][002120ec] 55 push ebp
> >>>>>> ...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
> >>>>>> ...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
> >>>>>> ...[000011f6][002120e4][000011f0] 50 push eax
> >>>>>> ...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
> >>>>>> ...[000011fa][002120e0][000011f0] 51 push ecx
> >>>>>> ...[000011fb][002120dc][00001200] e820feffff call 00001020
> >>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
> >>>>>> ...[00001222][00102040][00102048] 83c408 add esp,+08
> >>>>>> ...[00001225][00102040][00102048] 85c0 test eax,eax
> >>>>>> ...[00001227][00102040][00102048] 7402 jz 0000122b
> >>>>>> ...[0000122b][00102044][00001258] 5d pop ebp
> >>>>>> ...[0000122c][00102048][00000000] c3 ret
> >>>>>> ...[00001258][00102048][00000000] 33c0 xor eax,eax
> >>>>>> ...[0000125a][0010204c][00100000] 5d pop ebp
> >>>>>> ...[0000125b][00102050][00000000] c3 ret
> >>>>>> Number of Instructions Executed(874)
> >>>>>>
> >>>>>> Above is:
> >>>>>> int main()
> >>>>>> {
> >>>>>> Q();
> >>>>>> //R();
> >>>>>> }
> >>>>>>
> >>>>>> ---
> >>>>>> machine stack stack machine assembly
> >>>>>> address address data code language
> >>>>>> ======== ======== ======== ========= =============
> >>>>>> ...[00001250][00102048][00000000] 55 push ebp
> >>>>>> ...[00001251][00102048][00000000] 8bec mov ebp,esp
> >>>>>> ...[00001253][00102044][00001258] e8d8ffffff call 00001230
> >>>>>> ...[00001230][00102040][00102048] 55 push ebp
> >>>>>> ...[00001231][00102040][00102048] 8bec mov ebp,esp
> >>>>>> ...[00001233][0010203c][000011f0] 68f0110000 push 000011f0
> >>>>>> ...[00001238][00102038][000011f0] 68f0110000 push 000011f0
> >>>>>> ...[0000123d][00102034][00001242] e8defdffff call 00001020
> >>>>>>
> >>>>>> Begin Simulation Execution Trace Stored at:2120fc
> >>>>>> Address_of_H:1020
> >>>>>> ...[000011f0][002120e8][002120ec] 55 push ebp
> >>>>>> ...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
> >>>>>> ...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
> >>>>>> ...[000011f6][002120e4][000011f0] 50 push eax
> >>>>>> ...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
> >>>>>> ...[000011fa][002120e0][000011f0] 51 push ecx
> >>>>>> ...[000011fb][002120dc][00001200] e820feffff call 00001020
> >>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
> >>>>>> ...[00001242][00102040][00102048] 83c408 add esp,+08
> >>>>>> ...[00001245][00102044][00001258] 5d pop ebp
> >>>>>> ...[00001246][00102048][00000000] c3 ret
> >>>>>> ...[00001258][00102048][00000000] 33c0 xor eax,eax
> >>>>>> ...[0000125a][0010204c][00100000] 5d pop ebp
> >>>>>> ...[0000125b][00102050][00000000] c3 ret
> >>>>>> Number of Instructions Executed(872)
> >>>>>>
> >>>>>> Above is:
> >>>>>> int main()
> >>>>>> {
> >>>>>> //Q();
> >>>>>> R();
> >>>>>> }  
> >>>>>
> >>>>> Right, so we're getting somewhere. Can you explain why Q()
> >>>>> returns, and P(P) doesn't, when they both do the same thing in
> >>>>> the same way?  
> >>>> int main()
> >>>> {
> >>>> P(P);
> >>>> }
> >>>>
> >>>> does return.
> >>>>
> >>>> The correct and complete x86 emulation of its input by H(P,P)
> >>>> would never reach the "ret" instruction of P because both H and
> >>>> P would remain stuck in infinitely nested emulation.  
> >>>
> >>> These last two statements of yours are a contradiction.
> >>>
> >>> If P(P) returns, then a CORRECT emulation of it will reach the
> >>> ret instruction. An emulation that runs forever, when P(P) does
> >>> not, is not a correct emulation.  
> >>
> >> The ordinary semantics of standard C and the conventional x86
> >> language are the entire semantics required to conclusively prove
> >> that H(P,P) *does correctly predict*
> >> that its correct and complete x86 emulation of its input would
> >> never reach the "ret" instruction (final state) of this input thus
> >> never halts. The correct and complete x86 emulation of its input
> >> by H would never reach the "ret" instruction of P because both H
> >> and P would remain stuck in infinitely nested emulation.
> >>
> >> I need reviewers like you so that I can *fine tune* my words.  
> > 
> > If you are saying that P(P) returns, but that a correct and
> > complete x86 emulation of P(P) does not, then I think you are going
> > to have to change either "correct" or "emulation" to some very
> > different word. 
> 
> The correct and complete emulation of the input to H(P,P) has halting 
> behavior that is provably different than the the direct execution of
> P(P).
> 
> "Common sense" tells you that they must be the same empirical proof 
> proves that they are not the same.
> 
> >> A halt decider must compute the mapping from its inputs to an
> >> accept or reject state on the basis of the actual behavior of
> >> these actual inputs.  
> > 
> > Exactly. The actual behaviour. Not the behaviour it would have if
> > things were different. In particular, you need to take into account
> > H's ability to detect infinite loops. 
> 
> I initially made H robust enough that it does correctly reject
> infinite loops and infinite recursion and have code samples to prove
> it.
> 
> >> When a simulating halt decider rejects all inputs as non-halting
> >> whenever it correctly detects [in a finite number of steps] that
> >> its correct and complete simulation of its input would never reach
> >> [a] final state of this input then all [these] inputs (including
> >> pathological inputs) are correctly decided as non-halting.  
> > 
> > If you are fine-tuning your wording, could you do something about
> > this passage? Having both "When" and "whenever" makes it difficult
> > to parse. 
> 
> When a simulating halt decider correctly detects [in a finite number
> of steps] that its correct and complete simulation of its input would
> never reach [a] final state of this input then all [these] inputs
> (including pathological inputs) are correctly rejected as non-halting.
 
Your method for detecting pathological inputs precludes detecting
non-pathological inputs:

void Px(u32 x)
{
   H(x, x);
   return;
}

int main()
{
   Output("Input_Halts = ", H((u32)Px, (u32)Px));
}

...[000013e8][00102357][00000000] 83c408          add esp,+08
...[000013eb][00102353][00000000] 50              push eax
...[000013ec][0010234f][00000427] 6827040000      push 00000427
---[000013f1][0010234f][00000427] e880f0ffff      call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408          add esp,+08
...[000013f9][00102357][00000000] 33c0            xor eax,eax
...[000013fb][0010235b][00100000] 5d              pop ebp
...[000013fc][0010235f][00000004] c3              ret
Number of Instructions Executed(16120)

It gets the answer wrong, i.e. input has not been decided correctly.
QED.

/Flibble 

Back to comp.theory | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-21 21:38 -0500
  Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-21 22:52 -0400
    Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-21 22:10 -0500
      Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-21 23:28 -0400
      Re: Technically competent Software engineers can verify this halting problem proof refutation Python <python@example.invalid> - 2022-06-22 05:52 +0200
      Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-22 00:55 -0700
        Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 07:16 -0500
          Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-22 05:45 -0700
            Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 07:53 -0500
              Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 09:55 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 19:05 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 18:39 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 20:22 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 19:30 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 20:56 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 20:03 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:19 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 20:33 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:49 -0400
            Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-22 16:50 +0100
              Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] olcott <NoOne@NoWhere.com> - 2022-06-22 12:58 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 19:11 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] olcott <NoOne@NoWhere.com> - 2022-06-22 19:00 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 20:25 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 19:34 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:05 -0400
              Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-23 01:19 -0700
                Software engineers can verify this halting problem proof refutation [ H(P,P) versus P(P) ] olcott <NoOne@NoWhere.com> - 2022-06-23 13:14 -0500
                Re: Software engineers can verify this halting problem proof refutation [ H(P,P) versus P(P) ] Daniel Pehoushek <pehoushek1@gmail.com> - 2022-06-23 11:26 -0700
                Re: Software engineers can verify this halting problem proof refutation [ H(P,P) versus P(P) ] Richard Damon <Richard@Damon-Family.org> - 2022-06-23 19:00 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-23 23:44 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-23 20:38 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 00:53 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 08:07 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 09:18 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 06:34 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 09:32 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 12:07 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <polcott2@gmail.com> - 2022-06-24 10:50 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 09:09 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 11:32 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 12:46 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 11:52 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 15:55 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 10:29 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 12:42 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 12:34 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 15:20 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 16:00 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-24 20:42 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 13:25 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 15:35 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 16:59 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-24 23:16 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 17:25 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-06-24 16:58 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 19:12 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 21:56 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-06-24 21:50 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 23:59 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 21:01 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <polcott2@gmail.com> - 2022-06-24 23:33 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 22:09 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 00:24 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-25 00:32 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 09:28 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 10:03 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 16:09 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 10:19 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 16:21 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 10:54 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 16:59 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 11:06 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 17:25 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 11:32 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 20:12 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <NoOne@NoWhere.com> - 2022-06-25 14:20 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 20:33 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-25 13:03 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation Python <python@example.invalid> - 2022-06-25 18:31 +0200
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 11:40 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-25 12:59 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-25 09:39 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-26 00:55 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 20:07 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 02:16 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 20:36 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-26 14:40 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 19:57 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-26 21:42 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 15:53 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 20:58 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 03:03 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 05:31 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 12:15 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 11:27 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 20:00 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 14:11 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 20:26 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 14:37 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 20:43 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 14:54 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 21:15 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 15:37 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 21:40 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 15:42 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-26 15:09 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-26 14:56 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 20:01 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-26 03:14 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 05:42 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-26 13:58 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 16:18 -0500
  Re: Technically competent Software engineers can verify this halting problem proof refutation Jeff Barnett <jbb@notatt.com> - 2022-06-22 11:11 -0600
    Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 13:10 -0500
      Re: Technically competent Software engineers can verify this halting problem proof refutation Jeff Barnett <jbb@notatt.com> - 2022-06-22 16:10 -0600
        Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 17:34 -0500
        Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 17:37 -0500
        Re: Technically competent Software engineers can verify this halting problem proof refutation Paul N <gw7rib@aol.com> - 2022-06-23 05:20 -0700
          Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-23 13:03 -0500
  Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-22 20:31 +0100
    Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 15:27 -0500
      Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-22 22:20 +0100
        Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 16:41 -0500
          Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-22 22:49 +0100
            Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 16:58 -0500
              Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-23 00:01 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 18:29 -0500
          Re: Technically competent Software engineers can verify this halting problem proof refutation Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 14:53 -0700
            Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 17:22 -0500
              Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 15:48 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 18:11 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 18:02 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 20:16 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 18:21 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 20:37 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 18:44 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 21:15 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 22:22 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 21:42 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 22:52 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 19:23 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 21:46 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 19:48 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-23 01:28 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 22:54 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-24 13:52 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Paul N <gw7rib@aol.com> - 2022-06-24 13:05 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-24 15:27 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Paul N <gw7rib@aol.com> - 2022-06-25 04:56 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-25 09:10 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 15:53 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Paul N <gw7rib@aol.com> - 2022-06-25 09:19 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-25 11:29 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Paul N <gw7rib@aol.com> - 2022-06-25 10:21 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <NoOne@NoWhere.com> - 2022-06-25 12:52 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Paul N <gw7rib@aol.com> - 2022-06-25 11:58 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <NoOne@NoWhere.com> - 2022-06-25 14:15 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 20:18 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Richard Damon <Richard@Damon-Family.org> - 2022-06-25 16:11 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 20:15 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-25 20:24 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Paul N <gw7rib@aol.com> - 2022-06-25 12:33 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-25 14:49 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-25 17:35 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-26 00:28 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-25 20:34 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <polcott2@gmail.com> - 2022-06-25 19:54 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <polcott2@gmail.com> - 2022-06-25 19:55 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <polcott2@gmail.com> - 2022-06-25 19:56 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <NoOne@NoWhere.com> - 2022-06-25 19:57 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Richard Damon <Richard@Damon-Family.org> - 2022-06-25 21:47 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-25 14:39 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-25 19:21 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 00:42 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-24 23:23 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <NoOne@NoWhere.com> - 2022-06-24 17:58 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Richard Damon <Richard@Damon-Family.org> - 2022-06-24 22:00 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:52 -0400
      Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 20:32 -0400
        Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 19:37 -0500
          Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 20:48 -0400
            Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 19:55 -0500
              Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 18:05 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 20:20 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:32 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Paul N <gw7rib@aol.com> - 2022-06-23 05:13 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-06-23 17:28 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 11:42 -0500
                Software engineers can verify this halting problem proof refutation [ H(P,P) versus P(P) ] olcott <NoOne@NoWhere.com> - 2022-06-23 12:44 -0500
              Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:14 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 20:29 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:36 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 20:41 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:45 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 21:18 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 22:34 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 21:55 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 23:41 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 00:13 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 00:19 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-23 07:20 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-23 20:41 +0100
                Software engineers [ not Flibble ] can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 14:56 -0500
                Re: Software engineers [ not Flibble ] can verify this halting problem proof refutation [ full closure ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-23 20:59 +0100
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-06-23 16:55 -0700
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 20:38 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-23 21:59 -0400
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 21:10 -0500
                Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-23 22:29 -0400
    Re: Technically competent Software engineers can verify this halting problem proof refutation [ nitwit rebuttals ] olcott <NoOne@NoWhere.com> - 2022-06-22 15:47 -0500
      Re: Technically competent Software engineers can verify this halting problem proof refutation [ nitwit rebuttals ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-22 22:13 +0100

csiph-web