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


Groups > comp.theory > #53363

Re: Halting problem proofs refuted on the basis of software engineering

From Mr Flibble <flibble@reddwarf.jmc>
Newsgroups comp.theory, sci.logic, sci.math, comp.software-eng
Subject Re: Halting problem proofs refuted on the basis of software engineering
Message-ID <20220703170707.00006ec9@reddwarf.jmc> (permalink)
References (16 earlier) <Eqednf7muZ26K1z_nZ2dnUU7_81g4p2d@giganews.com> <20220703164543.00004b55@reddwarf.jmc> <kcKdnc6XHIvZJ1z_nZ2dnUU7_8xh4p2d@giganews.com> <20220703165111.00006d29@reddwarf.jmc> <4rydnbiMgrTeI1z_nZ2dnUU7_83NnZ2d@giganews.com>
Organization Jupiter Mining Corp
Date 2022-07-03 17:07 +0100

Cross-posted to 4 groups.

Show all headers | View raw


On Sun, 3 Jul 2022 11:05:21 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/3/2022 10:51 AM, Mr Flibble wrote:
> > On Sun, 3 Jul 2022 10:48:18 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >   
> >> On 7/3/2022 10:45 AM, Mr Flibble wrote:  
> >>> On Sun, 3 Jul 2022 10:30:45 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>      
> >>>> On 7/3/2022 10:21 AM, Mr Flibble wrote:  
> >>>>> On Sun, 3 Jul 2022 09:57:57 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>         
> >>>>>> On 7/3/2022 9:27 AM, Mr Flibble wrote:  
> >>>>>>> On Sat, 2 Jul 2022 17:13:01 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>            
> >>>>>>>> On 7/2/2022 5:05 PM, Mr Flibble wrote:  
> >>>>>>>>> On Sat, 2 Jul 2022 16:26:45 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>               
> >>>>>>>>>> On 7/2/2022 1:44 PM, Mr Flibble wrote:  
> >>>>>>>>>>> On Sat, 2 Jul 2022 13:41:14 -0500
> >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>                  
> >>>>>>>>>>>> On 7/2/2022 1:28 PM, Mr Flibble wrote:  
> >>>>>>>>>>>>> On Sat, 2 Jul 2022 12:30:03 -0500
> >>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>                     
> >>>>>>>>>>>>>> On 7/2/2022 12:26 PM, Mr Flibble wrote:  
> >>>>>>>>>>>>>>> On Sat, 2 Jul 2022 12:15:58 -0500
> >>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>                        
> >>>>>>>>>>>>>>>> On 7/2/2022 12:10 PM, Mr Flibble wrote:  
> >>>>>>>>>>>>>>>>> On Sat, 2 Jul 2022 11:42:48 -0500
> >>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>                           
> >>>>>>>>>>>>>>>>>> On 7/2/2022 11:26 AM, Mr Flibble wrote:  
> >>>>>>>>>>>>>>>>>>> On Sat, 2 Jul 2022 10:34:34 -0500
> >>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>                              
> >>>>>>>>>>>>>>>>>>>> This much more concise version of my paper
> >>>>>>>>>>>>>>>>>>>> focuses on the actual execution of three fully
> >>>>>>>>>>>>>>>>>>>> operational examples.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> H0 correctly determines that Infinite_Loop()
> >>>>>>>>>>>>>>>>>>>> never halts H correctly determines that
> >>>>>>>>>>>>>>>>>>>> Infinite_Recursion() never halts H correctly
> >>>>>>>>>>>>>>>>>>>> determines that P() never halts
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>>>>>>>>             {
> >>>>>>>>>>>>>>>>>>>>              if (H(x, x))
> >>>>>>>>>>>>>>>>>>>>                HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>              return;
> >>>>>>>>>>>>>>>>>>>>             }
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>             {
> >>>>>>>>>>>>>>>>>>>>              Output("Input_Halts = ", H((u32)P,
> >>>>>>>>>>>>>>>>>>>> (u32)P)); }
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> As shown below the above P and H have the
> >>>>>>>>>>>>>>>>>>>> required (halting problem) pathological
> >>>>>>>>>>>>>>>>>>>> relationship to each other:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>                 For any program H that might
> >>>>>>>>>>>>>>>>>>>> determine if programs halt, a "pathological"
> >>>>>>>>>>>>>>>>>>>>                 program P, called with some
> >>>>>>>>>>>>>>>>>>>> input, can pass its own source and its input to
> >>>>>>>>>>>>>>>>>>>>                 H and then specifically do the
> >>>>>>>>>>>>>>>>>>>> opposite of what H predicts P will do. No H
> >>>>>>>>>>>>>>>>>>>>                 can exist that handles this case.
> >>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I really need software engineers to verify that H
> >>>>>>>>>>>>>>>>>>>> does correctly predict that its complete and
> >>>>>>>>>>>>>>>>>>>> correct x86 emulation of its input would never
> >>>>>>>>>>>>>>>>>>>> reach the "ret" instruction of this input.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> *Halting problem proofs refuted on the basis of
> >>>>>>>>>>>>>>>>>>>> software engineering*
> >>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
> >>>>>>>>>>>>>>>>>>>>                             
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 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)
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> As can be seen above Olcott's H decides that Px
> >>>>>>>>>>>>>>>>>>> does not halt but it is obvious that Px should
> >>>>>>>>>>>>>>>>>>> always halt if H is a valid halt decider that
> >>>>>>>>>>>>>>>>>>> always returns a decision to its caller (Px).
> >>>>>>>>>>>>>>>>>>> Olcott's H does not return a decision to its
> >>>>>>>>>>>>>>>>>>> caller (Px) and is thus invalid.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>                              
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Your false assumptions are directly contradicted by
> >>>>>>>>>>>>>>>>>> the semantics of the x86 programming language.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> *x86 Instruction Set Reference*
> >>>>>>>>>>>>>>>>>> https://c9x.me/x86/
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> void Px(u32 x)
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>             H(x, x);
> >>>>>>>>>>>>>>>>>>             return;
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>             Output("Input_Halts = ", H((u32)Px,
> >>>>>>>>>>>>>>>>>> (u32)Px)); }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> _Px()
> >>>>>>>>>>>>>>>>>> [00001192](01)  55         push ebp
> >>>>>>>>>>>>>>>>>> [00001193](02)  8bec       mov ebp,esp
> >>>>>>>>>>>>>>>>>> [00001195](03)  8b4508     mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>> [00001198](01)  50         push eax
> >>>>>>>>>>>>>>>>>> [00001199](03)  8b4d08     mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>> [0000119c](01)  51         push ecx
> >>>>>>>>>>>>>>>>>> [0000119d](05)  e8d0fdffff call 00000f72
> >>>>>>>>>>>>>>>>>> [000011a2](03)  83c408     add esp,+08
> >>>>>>>>>>>>>>>>>> [000011a5](01)  5d         pop ebp
> >>>>>>>>>>>>>>>>>> [000011a6](01)  c3         ret
> >>>>>>>>>>>>>>>>>> Size in bytes:(0021) [000011a6]
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> _main()
> >>>>>>>>>>>>>>>>>> [000011d2](01)  55         push ebp
> >>>>>>>>>>>>>>>>>> [000011d3](02)  8bec       mov ebp,esp
> >>>>>>>>>>>>>>>>>> [000011d5](05)  6892110000 push 00001192
> >>>>>>>>>>>>>>>>>> [000011da](05)  6892110000 push 00001192
> >>>>>>>>>>>>>>>>>> [000011df](05)  e88efdffff call 00000f72
> >>>>>>>>>>>>>>>>>> [000011e4](03)  83c408     add esp,+08
> >>>>>>>>>>>>>>>>>> [000011e7](01)  50         push eax
> >>>>>>>>>>>>>>>>>> [000011e8](05)  68a3040000 push 000004a3
> >>>>>>>>>>>>>>>>>> [000011ed](05)  e800f3ffff call 000004f2
> >>>>>>>>>>>>>>>>>> [000011f2](03)  83c408     add esp,+08
> >>>>>>>>>>>>>>>>>> [000011f5](02)  33c0       xor eax,eax
> >>>>>>>>>>>>>>>>>> [000011f7](01)  5d         pop ebp
> >>>>>>>>>>>>>>>>>> [000011f8](01)  c3         ret
> >>>>>>>>>>>>>>>>>> Size in bytes:(0039) [000011f8]
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>            machine   stack     stack     machine
> >>>>>>>>>>>>>>>>>> assembly address   address   data      code
> >>>>>>>>>>>>>>>>>> language ========  ========  ========  =========
> >>>>>>>>>>>>>>>>>> ============= [000011d2][00101f7f][00000000] 55
> >>>>>>>>>>>>>>>>>> push ebp [000011d3][00101f7f][00000000] 8bec
> >>>>>>>>>>>>>>>>>> mov ebp,esp [000011d5][00101f7b][00001192]
> >>>>>>>>>>>>>>>>>> 6892110000 push 00001192
> >>>>>>>>>>>>>>>>>> [000011da][00101f77][00001192] 6892110000 push
> >>>>>>>>>>>>>>>>>> 00001192 [000011df][00101f73][000011e4] e88efdffff
> >>>>>>>>>>>>>>>>>> call 00000f72
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> H: Begin Simulation   Execution Trace Stored
> >>>>>>>>>>>>>>>>>> at:11202b Address_of_H:f72
> >>>>>>>>>>>>>>>>>> [00001192][00112017][0011201b] 55         push ebp
> >>>>>>>>>>>>>>>>>> [00001193][00112017][0011201b] 8bec       mov
> >>>>>>>>>>>>>>>>>> ebp,esp [00001195][00112017][0011201b] 8b4508
> >>>>>>>>>>>>>>>>>> mov eax,[ebp+08] [00001198][00112013][00001192] 50
> >>>>>>>>>>>>>>>>>> push eax      // push Px
> >>>>>>>>>>>>>>>>>> [00001199][00112013][00001192] 8b4d08     mov
> >>>>>>>>>>>>>>>>>> ecx,[ebp+08] [0000119c][0011200f][00001192] 51
> >>>>>>>>>>>>>>>>>>    push ecx // push Px
> >>>>>>>>>>>>>>>>>> [0000119d][0011200b][000011a2] e8d0fdffff call
> >>>>>>>>>>>>>>>>>> 00000f72 // call H(Px,Px) H: Infinitely Recursive
> >>>>>>>>>>>>>>>>>> Simulation Detected Simulation Stopped
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis
> >>>>>>>>>>>>>>>>>> it can easily examine its stored execution_trace
> >>>>>>>>>>>>>>>>>> of Px (see above) to determine: (a) Px is calling
> >>>>>>>>>>>>>>>>>> H with the same arguments that H was called with.
> >>>>>>>>>>>>>>>>>> (b) No instructions in Px could possibly escape
> >>>>>>>>>>>>>>>>>> this otherwise infinitely recursive emulation. (c)
> >>>>>>>>>>>>>>>>>> H aborts its emulation of Px before its call to H
> >>>>>>>>>>>>>>>>>> is emulated.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> [000011e4][00101f7f][00000000] 83c408     add
> >>>>>>>>>>>>>>>>>> esp,+08 [000011e7][00101f7b][00000000] 50
> >>>>>>>>>>>>>>>>>> push eax [000011e8][00101f77][000004a3] 68a3040000
> >>>>>>>>>>>>>>>>>> push 000004a3 [000011ed][00101f77][000004a3]
> >>>>>>>>>>>>>>>>>> e800f3ffff call 000004f2 Input_Halts = 0
> >>>>>>>>>>>>>>>>>> [000011f2][00101f7f][00000000] 83c408     add
> >>>>>>>>>>>>>>>>>> esp,+08 [000011f5][00101f7f][00000000] 33c0
> >>>>>>>>>>>>>>>>>> xor eax,eax [000011f7][00101f83][00000018] 5d
> >>>>>>>>>>>>>>>>>>    pop ebp [000011f8][00101f87][00000000] c3
> >>>>>>>>>>>>>>>>>>   ret Number of Instructions Executed(880) == 13
> >>>>>>>>>>>>>>>>>> Pages  
> >>>>>>>>>>>>>>>>>           
> >>>>>>>>>>>>>>>>> If H wasn't a simulation-based halting decider then
> >>>>>>>>>>>>>>>>> Px() would always halt; the infinite recursion is a
> >>>>>>>>>>>>>>>>> manifestation of your invalid simulation-based
> >>>>>>>>>>>>>>>>> halting decider.  There is no recursion in
> >>>>>>>>>>>>>>>>> [Strachey 1965].
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> /Flibble  
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> In other words you are rejecting the concept of a
> >>>>>>>>>>>>>>>> simulating halt decider even though I conclusively
> >>>>>>>>>>>>>>>> proved that it does correctly determine the halt
> >>>>>>>>>>>>>>>> status of: (see my new paper)  
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> No I am rejecting your simulating halt decider as it
> >>>>>>>>>>>>>>> gets the answer wrong for Px() which is not a
> >>>>>>>>>>>>>>> pathological input. Px() halts.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>                        
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I just proved that H(Px,Px) does correctly predict that
> >>>>>>>>>>>>>> its complete and correct x86 emulation of its input
> >>>>>>>>>>>>>> would never reach the "ret" instruction of this input
> >>>>>>>>>>>>>> because of the pathological relationship between H and
> >>>>>>>>>>>>>> Px.  
> >>>>>>>>>>>>>         
> >>>>>>>>>>>>> Wrong. Px() is not a pathological input as defined by
> >>>>>>>>>>>>> the halting problem and [Strachey 1965] as it does not
> >>>>>>>>>>>>> try to do the opposite of what H decides.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>                     
> >>>>>>>>>>>>
> >>>>>>>>>>>> Your lack of comprehension does not actually count as any
> >>>>>>>>>>>> rebuttal at all.
> >>>>>>>>>>>>
> >>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>         {
> >>>>>>>>>>>>          if (H(x, x))
> >>>>>>>>>>>>            HERE: goto HERE;
> >>>>>>>>>>>>          return;
> >>>>>>>>>>>>         }
> >>>>>>>>>>>>
> >>>>>>>>>>>> int main()
> >>>>>>>>>>>>         {
> >>>>>>>>>>>>          Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>>>>>         }
> >>>>>>>>>>>>
> >>>>>>>>>>>> As shown below the above P and H have the required
> >>>>>>>>>>>> (halting problem) pathological relationship to each
> >>>>>>>>>>>> other:  
> >>>>>>>>>>> [snip]
> >>>>>>>>>>>
> >>>>>>>>>>> P does but Px does not. I am talking about Px not P.
> >>>>>>>>>>>
> >>>>>>>>>>> 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)
> >>>>>>>>>>>
> >>>>>>>>>>> As can be seen above Olcott's H decides that Px does not
> >>>>>>>>>>> halt but it is obvious that Px should always halt if H is
> >>>>>>>>>>> a valid halt decider that always returns a decision to its
> >>>>>>>>>>> caller (Px). Olcott's H does not return a decision to its
> >>>>>>>>>>> caller (Px) and is thus invalid.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>                  
> >>>>>>>>>>              
> >>>>>>>>>>       >  
> >>>>>>>>>>
> >>>>>>>>>> Your false assumptions are directly contradicted by the
> >>>>>>>>>> semantics of the x86 programming language.
> >>>>>>>>>>
> >>>>>>>>>> *x86 Instruction Set Reference*  https://c9x.me/x86/
> >>>>>>>>>>
> >>>>>>>>>> void Px(u32 x)
> >>>>>>>>>> {
> >>>>>>>>>>         H(x, x);
> >>>>>>>>>>         return;
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> int main()
> >>>>>>>>>> {
> >>>>>>>>>>         Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> _Px()
> >>>>>>>>>> [00001192](01)  55         push ebp
> >>>>>>>>>> [00001193](02)  8bec       mov ebp,esp
> >>>>>>>>>> [00001195](03)  8b4508     mov eax,[ebp+08]
> >>>>>>>>>> [00001198](01)  50         push eax
> >>>>>>>>>> [00001199](03)  8b4d08     mov ecx,[ebp+08]
> >>>>>>>>>> [0000119c](01)  51         push ecx
> >>>>>>>>>> [0000119d](05)  e8d0fdffff call 00000f72
> >>>>>>>>>> [000011a2](03)  83c408     add esp,+08
> >>>>>>>>>> [000011a5](01)  5d         pop ebp
> >>>>>>>>>> [000011a6](01)  c3         ret
> >>>>>>>>>> Size in bytes:(0021) [000011a6]
> >>>>>>>>>>
> >>>>>>>>>> _main()
> >>>>>>>>>> [000011d2](01)  55         push ebp
> >>>>>>>>>> [000011d3](02)  8bec       mov ebp,esp
> >>>>>>>>>> [000011d5](05)  6892110000 push 00001192
> >>>>>>>>>> [000011da](05)  6892110000 push 00001192
> >>>>>>>>>> [000011df](05)  e88efdffff call 00000f72
> >>>>>>>>>> [000011e4](03)  83c408     add esp,+08
> >>>>>>>>>> [000011e7](01)  50         push eax
> >>>>>>>>>> [000011e8](05)  68a3040000 push 000004a3
> >>>>>>>>>> [000011ed](05)  e800f3ffff call 000004f2
> >>>>>>>>>> [000011f2](03)  83c408     add esp,+08
> >>>>>>>>>> [000011f5](02)  33c0       xor eax,eax
> >>>>>>>>>> [000011f7](01)  5d         pop ebp
> >>>>>>>>>> [000011f8](01)  c3         ret
> >>>>>>>>>> Size in bytes:(0039) [000011f8]
> >>>>>>>>>>
> >>>>>>>>>>        machine   stack     stack     machine    assembly
> >>>>>>>>>>        address   address   data      code       language
> >>>>>>>>>>        ========  ========  ========  =========
> >>>>>>>>>> ============= [000011d2][00101f7f][00000000] 55
> >>>>>>>>>> push ebp [000011d3][00101f7f][00000000] 8bec       mov
> >>>>>>>>>> ebp,esp [000011d5][00101f7b][00001192] 6892110000 push
> >>>>>>>>>> 00001192 [000011da][00101f77][00001192] 6892110000 push
> >>>>>>>>>> 00001192 [000011df][00101f73][000011e4] e88efdffff call
> >>>>>>>>>> 00000f72
> >>>>>>>>>>
> >>>>>>>>>> H: Begin Simulation   Execution Trace Stored at:11202b
> >>>>>>>>>> Address_of_H:f72
> >>>>>>>>>> [00001192][00112017][0011201b] 55         push ebp
> >>>>>>>>>> [00001193][00112017][0011201b] 8bec       mov ebp,esp
> >>>>>>>>>> [00001195][00112017][0011201b] 8b4508     mov eax,[ebp+08]
> >>>>>>>>>> [00001198][00112013][00001192] 50         push eax      //
> >>>>>>>>>> push Px [00001199][00112013][00001192] 8b4d08     mov
> >>>>>>>>>> ecx,[ebp+08] [0000119c][0011200f][00001192] 51         push
> >>>>>>>>>> ecx      // push Px [0000119d][0011200b][000011a2]
> >>>>>>>>>> e8d0fdffff call 00000f72 // call H(Px,Px) H: Infinitely
> >>>>>>>>>> Recursive Simulation Detected Simulation Stopped
> >>>>>>>>>>
> >>>>>>>>>> H knows its own machine address and on this basis it can
> >>>>>>>>>> easily examine its stored execution_trace of Px (see above)
> >>>>>>>>>> to determine: (a) Px is calling H with the same arguments
> >>>>>>>>>> that H was called with. (b) No instructions in Px could
> >>>>>>>>>> possibly escape this otherwise infinitely recursive
> >>>>>>>>>> emulation. (c) H aborts its emulation of Px before its call
> >>>>>>>>>> to H is emulated.
> >>>>>>>>>>
> >>>>>>>>>> [000011e4][00101f7f][00000000] 83c408     add esp,+08
> >>>>>>>>>> [000011e7][00101f7b][00000000] 50         push eax
> >>>>>>>>>> [000011e8][00101f77][000004a3] 68a3040000 push 000004a3
> >>>>>>>>>> [000011ed][00101f77][000004a3] e800f3ffff call 000004f2
> >>>>>>>>>> Input_Halts = 0
> >>>>>>>>>> [000011f2][00101f7f][00000000] 83c408     add esp,+08
> >>>>>>>>>> [000011f5][00101f7f][00000000] 33c0       xor eax,eax
> >>>>>>>>>> [000011f7][00101f83][00000018] 5d         pop ebp
> >>>>>>>>>> [000011f8][00101f87][00000000] c3         ret
> >>>>>>>>>> Number of Instructions Executed(880) == 13 Pages  
> >>>>>>>>>       
> >>>>>>>>> I see you wish to pointlessly go around in circles. Oh well.
> >>>>>>>>>
> >>>>>>>>> Px() is not a pathological input as defined by the halting
> >>>>>>>>> problem and [Strachey 1965] as it does not try to do the
> >>>>>>>>> opposite of what H decides.
> >>>>>>>>>
> >>>>>>>>> Px() always halts so your H gets the answer wrong.
> >>>>>>>>>
> >>>>>>>>> /Flibble  
> >>>>>>>>
> >>>>>>>> I found that my reply did not make it to all the groups so I
> >>>>>>>> posted it again.
> >>>>>>>>
> >>>>>>>> *This general principle refutes conventional halting problem
> >>>>>>>> proofs* Every simulating halt decider that correctly
> >>>>>>>> simulates its input until it correctly predicts that this
> >>>>>>>> simulated input would never reach its final state, correctly
> >>>>>>>> rejects this input as non-halting.  
> >>>>>>>
> >>>>>>> Your H does not "correctly predict" that Px() does reach its
> >>>>>>> final state and so should accept the input as halting.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>            
> >>>>>>
> >>>>>> (x86 Instruction Set Reference* https://c9x.me/x86/
> >>>>>>
> >>>>>> The semantics of the x86 language conclusively proves that the
> >>>>>> above code is correct. People that disagree with verified facts
> >>>>>> are either incompetent or liars. Since you cannot even
> >>>>>> understand that the return statement in Px is unreachable
> >>>>>> code, (to every simulating halt decider H) you would be
> >>>>>> incompetent.  
> >>>>>     
> >>>>> Not EVERY simulating halt decider, only YOURS gets the answer
> >>>>> wrong. Px() halts.
> >>>>>
> >>>>> /Flibble
> >>>>>         
> >>>>
> >>>> Since you cannot even understand that the return statement in Px
> >>>> is unreachable code, (to *every simulating halt* decider H) you
> >>>> would be incompetent.  
> >>>    
> >>> Not at all. If I was to design a simulating halt decider then
> >>> rather than aborting the simulation at the point where P()/Px()
> >>> calls H I would instead fork the simulation, returning 0 to one
> >>> branch (the non-halting branch) and 1 to the other branch (the
> >>> halting branch) and then continue to simulate both branches in
> >>> parallel thereby getting rid of the "infinite recursion".
> >>>
> >>> /Flibble
> >>>      
> >>
> >> Yet that is *not* what the actual code specifies. Every function
> >> called in infinite recursion is not allowed to return to its
> >> caller.  
> >   
> > The infinite recursion is an artifact of how YOU are trying to solve
> > the problem; there is no infinite recursion in [Strachey 1965] and
> > associated proofs.
> > 
> > /Flibble
> >   
> 
> The halting problem expressly allows every algorithm in the universe
> as long as it correctly predicts the behavior of the input.

Your H does not correctly predict the behavior of Px() as Px() always
halts yet your H incorrectly says it doesn't.

/Flibble

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


Thread

Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 10:34 -0500
  Re: Halting problem proofs refuted on the basis of software engineering "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-02 09:20 -0700
    Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 11:32 -0500
  Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-02 17:26 +0100
    Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 11:42 -0500
      Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-02 18:10 +0100
        Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 12:15 -0500
          Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-02 18:26 +0100
            Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 12:30 -0500
              Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-02 19:28 +0100
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 13:41 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-02 19:44 +0100
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 16:26 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-02 23:05 +0100
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 17:13 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-03 15:27 +0100
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-03 09:57 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-03 16:21 +0100
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-03 10:30 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-03 16:45 +0100
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-03 10:48 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-03 16:51 +0100
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-03 11:05 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-03 17:07 +0100
                Re: Halting problem proofs refuted on the basis of software engineering "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-03 12:35 -0700
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-03 14:51 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-03 16:21 -0400
                Re: Halting problem proofs refuted on the basis of software engineering "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-03 16:10 -0700
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-03 19:44 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-04 07:45 -0400
                Re: Halting problem proofs refuted on the basis of software engineering "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-04 09:36 -0700
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-04 11:57 -0500
                Re: Halting problem proofs refuted on the basis of software engineering "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-04 11:42 -0700
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-04 14:17 -0500
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-04 14:21 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-04 18:08 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-05 11:50 -0700
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-05 14:31 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-05 16:21 -0700
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-05 18:37 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] Richard Damon <Richard@Damon-Family.org> - 2022-07-05 22:18 -0400
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] André G. Isaak <agisaak@gm.invalid> - 2022-07-05 14:24 -0600
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-05 15:42 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] Richard Damon <Richard@Damon-Family.org> - 2022-07-05 19:29 -0400
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-06 00:53 +0100
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-05 19:01 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-05 21:00 -0700
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-05 23:02 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-06 13:58 -0700
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-06 16:13 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-07 12:19 -0700
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-07 14:39 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-07 13:54 -0700
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-07 16:08 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-07 17:36 -0700
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-07 20:34 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-07 21:35 -0700
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-07 23:48 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-07 23:09 -0700
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-08 07:54 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-08 10:59 -0700
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-08 13:02 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-08 17:48 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Irrefutably Correct ] olcott <NoOne@NoWhere.com> - 2022-07-09 08:16 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Irrefutably Correct ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-09 10:22 -0700
                Re: Halting problem proofs refuted on the basis of software engineering [ Irrefutably Correct ] olcott <NoOne@NoWhere.com> - 2022-07-09 13:40 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [ Irrefutably Correct ] Richard Damon <Richard@Damon-Family.org> - 2022-07-09 15:06 -0400
                Re: Halting problem proofs refuted on the basis of software engineering [ Irrefutably Correct ] Richard Damon <Richard@Damon-Family.org> - 2022-07-09 14:18 -0400
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] Richard Damon <Richard@Damon-Family.org> - 2022-07-07 22:16 -0400
                Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-05 19:50 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-04 15:05 -0400
                Re: Halting problem proofs refuted on the basis of software engineering Mikko <mikko.levanto@iki.fi> - 2022-07-05 11:53 +0300
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-05 07:59 -0500
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-05 08:00 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-05 19:31 -0400
                Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-03 13:34 -0400
                Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-02 19:29 -0400
      Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-02 14:42 -0400
  Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-02 14:40 -0400
    Re: Halting problem proofs refuted on the basis of software engineering olcott <polcott2@gmail.com> - 2022-07-12 11:34 -0500
      Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-12 19:06 -0400
  Re: Halting problem proofs refuted on the basis of software engineering Henrietta Stinkbottom <henri@galabbogosutionallity.net> - 2022-07-02 11:52 -0700
  Re: Halting problem proofs refuted on the basis of software engineering wij <wyniijj2@gmail.com> - 2022-07-12 09:56 -0700
    Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-12 22:15 -0500
      Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-13 07:07 -0400
      Re: Halting problem proofs refuted on the basis of software engineering Paul N <gw7rib@aol.com> - 2022-07-13 08:02 -0700
        Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-13 11:07 -0500
          Re: Halting problem proofs refuted on the basis of software engineering Paul N <gw7rib@aol.com> - 2022-07-13 11:03 -0700
            Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-13 14:37 -0500
              Re: Halting problem proofs refuted on the basis of software engineering wij <wyniijj2@gmail.com> - 2022-07-13 13:47 -0700
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-13 15:51 -0500
                Re: Halting problem proofs refuted on the basis of software engineering wij <wyniijj2@gmail.com> - 2022-07-13 14:11 -0700
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-13 19:10 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-13 21:29 -0400
                Re: Halting problem proofs refuted on the basis of software engineering wij <wyniijj2@gmail.com> - 2022-07-15 02:20 -0700
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-15 09:26 -0500
                Re: Halting problem proofs refuted on the basis of software engineering wij <wyniijj2@gmail.com> - 2022-07-15 10:25 -0700
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-15 12:31 -0500
                Re: Halting problem proofs refuted on the basis of software engineering wij <wyniijj2@gmail.com> - 2022-07-15 11:48 -0700
                Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-15 19:25 -0400
              Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-13 19:29 -0400
              Re: Halting problem proofs refuted on the basis of software engineering Paul N <gw7rib@aol.com> - 2022-07-14 04:42 -0700
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-14 14:56 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-14 19:20 -0400
                Re: Halting problem proofs refuted on the basis of software engineering Paul N <gw7rib@aol.com> - 2022-07-15 05:34 -0700
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-15 09:35 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Paul N <gw7rib@aol.com> - 2022-07-15 09:17 -0700
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-15 11:26 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Paul N <gw7rib@aol.com> - 2022-07-16 04:23 -0700
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-16 08:32 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-16 10:24 -0400
                Re: Halting problem proofs refuted on the basis of software engineering Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-07-16 16:54 +0100
                Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-16 12:40 -0400
                Re: Halting problem proofs refuted on the basis of software engineering Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-07-16 20:28 +0100
                Re: Halting problem proofs refuted on the basis of software engineering (Mike fails to comprehend) olcott <NoOne@NoWhere.com> - 2022-07-16 15:12 -0500
                Re: Halting problem proofs refuted on the basis of software engineering (Mike fails to comprehend) Richard Damon <Richard@Damon-Family.org> - 2022-07-16 18:05 -0400
                Re: Halting problem proofs refuted on the basis of software engineering (Mike fails to comprehend) Richard Damon <Richard@Damon-Family.org> - 2022-07-16 18:16 -0400
                Re: Halting problem proofs refuted on the basis of software engineering [thanks Mike] olcott <NoOne@NoWhere.com> - 2022-07-17 12:00 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [thanks Mike] Richard Damon <Richard@Damon-Family.org> - 2022-07-17 13:06 -0400
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-16 12:43 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-16 13:56 -0400
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-16 19:18 -0500
                Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-16 20:38 -0400
                Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-16 20:19 -0500
                Re: Halting problem proofs refuted on the basis of software engineering [thanks Mike] olcott <polcott2@gmail.com> - 2022-07-16 21:40 -0500

csiph-web