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

Groups > comp.theory > #53399 > unrolled thread

Halting problem proofs refuted on the basis of software engineering V2

Started byolcott <NoOne@NoWhere.com>
First post2022-07-04 09:45 -0500
Last post2022-07-04 15:02 -0400
Articles 15 — 4 participants

Back to article view | Back to comp.theory

Contents

  Halting problem proofs refuted on the basis of software engineering V2 olcott <NoOne@NoWhere.com> - 2022-07-04 09:45 -0500
    Re: Halting problem proofs refuted on the basis of software engineering V2 Horatio Cornholer <midshipman@gmail.net> - 2022-07-04 08:31 -0700
    Re: Halting problem proofs refuted on the basis of software engineering V2 Mr Flibble <flibble@reddwarf.jmc> - 2022-07-04 16:58 +0100
      Re: Halting problem proofs refuted on the basis of software engineering V2 olcott <NoOne@NoWhere.com> - 2022-07-04 11:54 -0500
        Re: Halting problem proofs refuted on the basis of software engineering V2 Mr Flibble <flibble@reddwarf.jmc> - 2022-07-04 18:25 +0100
          Re: Halting problem proofs refuted on the basis of software engineering V2 olcott <NoOne@NoWhere.com> - 2022-07-04 12:33 -0500
            Re: Halting problem proofs refuted on the basis of software engineering V2 Mr Flibble <flibble@reddwarf.jmc> - 2022-07-04 18:39 +0100
              Re: Halting problem proofs refuted on the basis of software engineering V2 olcott <NoOne@NoWhere.com> - 2022-07-04 12:51 -0500
                Re: Halting problem proofs refuted on the basis of software engineering V2 Mr Flibble <flibble@reddwarf.jmc> - 2022-07-04 18:54 +0100
                  Re: Halting problem proofs refuted on the basis of software engineering V2 olcott <NoOne@NoWhere.com> - 2022-07-04 13:00 -0500
                    Re: Halting problem proofs refuted on the basis of software engineering V2 Mr Flibble <flibble@reddwarf.jmc> - 2022-07-04 19:38 +0100
                      Re: Halting problem proofs refuted on the basis of software engineering V2 olcott <NoOne@NoWhere.com> - 2022-07-04 14:09 -0500
                        Re: Halting problem proofs refuted on the basis of software engineering V2 Mr Flibble <flibble@reddwarf.jmc> - 2022-07-04 20:13 +0100
                        Re: Halting problem proofs refuted on the basis of software engineering V2 Richard Damon <Richard@Damon-Family.org> - 2022-07-04 15:40 -0400
    Re: Halting problem proofs refuted on the basis of software engineering V2 Richard Damon <Richard@Damon-Family.org> - 2022-07-04 15:02 -0400

#53399 — Halting problem proofs refuted on the basis of software engineering V2

Fromolcott <NoOne@NoWhere.com>
Date2022-07-04 09:45 -0500
SubjectHalting problem proofs refuted on the basis of software engineering V2
Message-ID<pKqdnSAPzf6HYF__nZ2dnUU7_83NnZ2d@giganews.com>
No one can provide any "rebuttal" of my paper on any other basis
than

(1) disagreeing with the semantics of the x86 language
*x86 Instruction Set Reference* https://c9x.me/x86/

*or disagreeing with this necessarily true principle*
(2) 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.



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(P,P) correctly determines that its input never halts

typedef void (*ptr)();

void P(ptr x)
{
   if (H(x, x))
     HERE: goto HERE;
   return;
}

int main()
{
   Output("Input_Halts = ", H(P, 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


*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


-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

[toc] | [next] | [standalone]

#53400

FromHoratio Cornholer <midshipman@gmail.net>
Date2022-07-04 08:31 -0700
Message-ID<t9v14u$13hg$1@gioia.aioe.org>
In reply to#53399
On 7/4/2022 7:45 AM, olcott wrote:
> No one can provide any "rebuttal" of my paper on any other basis
> than
> 

Post it 154,678 more times you impotent blithering wankmaggot.

[toc] | [prev] | [next] | [standalone]

#53401

FromMr Flibble <flibble@reddwarf.jmc>
Date2022-07-04 16:58 +0100
Message-ID<20220704165842.00002bb6@reddwarf.jmc>
In reply to#53399
On Mon, 4 Jul 2022 09:45:45 -0500
olcott <NoOne@NoWhere.com> wrote:

> No one can provide any "rebuttal" of my paper on any other basis
> than
> 
> (1) disagreeing with the semantics of the x86 language
> *x86 Instruction Set Reference* https://c9x.me/x86/
> 
> *or disagreeing with this necessarily true principle*
> (2) 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.
> 
> 
> 
> 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(P,P) correctly determines that its input never halts

As I have shown with my signaling halting decider there is no need for
a call to a simulation-based halting decider, H, from the input program
to be recursive; this is compatible with [Strachey 1965] and
associated proofs which are not recursive in nature.  Your H is invalid
as it aborts the simulation to prevent infinite recursion rather than
returning an answer to its caller which results in it giving the wrong
answer for a non-pathological input that calls H.

/Flibble

[toc] | [prev] | [next] | [standalone]

#53403

Fromolcott <NoOne@NoWhere.com>
Date2022-07-04 11:54 -0500
Message-ID<JZGdnTHV77zChl7_nZ2dnUU7_8xh4p2d@giganews.com>
In reply to#53401
On 7/4/2022 10:58 AM, Mr Flibble wrote:
> On Mon, 4 Jul 2022 09:45:45 -0500
> olcott <NoOne@NoWhere.com> wrote:
> 
>> No one can provide any "rebuttal" of my paper on any other basis
>> than
>>
>> (1) disagreeing with the semantics of the x86 language
>> *x86 Instruction Set Reference* https://c9x.me/x86/
>>
>> *or disagreeing with this necessarily true principle*
>> (2) 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.
>>
>>
>>
>> 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(P,P) correctly determines that its input never halts
> 
> As I have shown with my signaling halting decider there is no need for
> a call to a simulation-based halting decider, H, from the input program
> to be recursive; this is compatible with [Strachey 1965] and
> associated proofs which are not recursive in nature.  Your H is invalid
> as it aborts the simulation to prevent infinite recursion rather than
> returning an answer to its caller which results in it giving the wrong
> answer for a non-pathological input that calls H.
> 
> /Flibble
> 

YOU KEEP DISAGREEING WITH VERIFIED FACTS:
 From a purely software engineering perspective (anchored in the 
semantics of the x86 language) it is proven that H(P,P) correctly 
predicts that its correct and complete x86 emulation of its input would 
never reach the "ret" instruction (final state) of this input.

-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#53405

FromMr Flibble <flibble@reddwarf.jmc>
Date2022-07-04 18:25 +0100
Message-ID<20220704182511.0000502a@reddwarf.jmc>
In reply to#53403
On Mon, 4 Jul 2022 11:54:55 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/4/2022 10:58 AM, Mr Flibble wrote:
> > On Mon, 4 Jul 2022 09:45:45 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >   
> >> No one can provide any "rebuttal" of my paper on any other basis
> >> than
> >>
> >> (1) disagreeing with the semantics of the x86 language
> >> *x86 Instruction Set Reference* https://c9x.me/x86/
> >>
> >> *or disagreeing with this necessarily true principle*
> >> (2) 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.
> >>
> >>
> >>
> >> 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(P,P) correctly determines that its input never halts  
> > 
> > As I have shown with my signaling halting decider there is no need
> > for a call to a simulation-based halting decider, H, from the input
> > program to be recursive; this is compatible with [Strachey 1965] and
> > associated proofs which are not recursive in nature.  Your H is
> > invalid as it aborts the simulation to prevent infinite recursion
> > rather than returning an answer to its caller which results in it
> > giving the wrong answer for a non-pathological input that calls H.
> > 
> > /Flibble
> >   
> 
> YOU KEEP DISAGREEING WITH VERIFIED FACTS:
>  From a purely software engineering perspective (anchored in the 
> semantics of the x86 language) it is proven that H(P,P) correctly 
> predicts that its correct and complete x86 emulation of its input
> would never reach the "ret" instruction (final state) of this input.
 
No it doesn't. What you have doesn't work.

/Flibble

[toc] | [prev] | [next] | [standalone]

#53406

Fromolcott <NoOne@NoWhere.com>
Date2022-07-04 12:33 -0500
Message-ID<O8ydnfKceaXkuV7_nZ2dnUU7_81g4p2d@giganews.com>
In reply to#53405
On 7/4/2022 12:25 PM, Mr Flibble wrote:
> On Mon, 4 Jul 2022 11:54:55 -0500
> olcott <NoOne@NoWhere.com> wrote:
> 
>> On 7/4/2022 10:58 AM, Mr Flibble wrote:
>>> On Mon, 4 Jul 2022 09:45:45 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>    
>>>> No one can provide any "rebuttal" of my paper on any other basis
>>>> than
>>>>
>>>> (1) disagreeing with the semantics of the x86 language
>>>> *x86 Instruction Set Reference* https://c9x.me/x86/
>>>>
>>>> *or disagreeing with this necessarily true principle*
>>>> (2) 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.
>>>>
>>>>
>>>>
>>>> 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(P,P) correctly determines that its input never halts
>>>
>>> As I have shown with my signaling halting decider there is no need
>>> for a call to a simulation-based halting decider, H, from the input
>>> program to be recursive; this is compatible with [Strachey 1965] and
>>> associated proofs which are not recursive in nature.  Your H is
>>> invalid as it aborts the simulation to prevent infinite recursion
>>> rather than returning an answer to its caller which results in it
>>> giving the wrong answer for a non-pathological input that calls H.
>>>
>>> /Flibble
>>>    
>>
>> YOU KEEP DISAGREEING WITH VERIFIED FACTS:
>>   From a purely software engineering perspective (anchored in the
>> semantics of the x86 language) it is proven that H(P,P) correctly
>> predicts that its correct and complete x86 emulation of its input
>> would never reach the "ret" instruction (final state) of this input.
>   
> No it doesn't. What you have doesn't work.
> 
> /Flibble
> 

Try and prove how foolish you are by attempting to refute the above 
statement on the basis is this paper:

*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

-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#53407

FromMr Flibble <flibble@reddwarf.jmc>
Date2022-07-04 18:39 +0100
Message-ID<20220704183909.00005ee0@reddwarf.jmc>
In reply to#53406
On Mon, 4 Jul 2022 12:33:44 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/4/2022 12:25 PM, Mr Flibble wrote:
> > On Mon, 4 Jul 2022 11:54:55 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >   
> >> On 7/4/2022 10:58 AM, Mr Flibble wrote:  
> >>> On Mon, 4 Jul 2022 09:45:45 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>      
> >>>> No one can provide any "rebuttal" of my paper on any other basis
> >>>> than
> >>>>
> >>>> (1) disagreeing with the semantics of the x86 language
> >>>> *x86 Instruction Set Reference* https://c9x.me/x86/
> >>>>
> >>>> *or disagreeing with this necessarily true principle*
> >>>> (2) 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.
> >>>>
> >>>>
> >>>>
> >>>> 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(P,P) correctly determines that its input never halts  
> >>>
> >>> As I have shown with my signaling halting decider there is no need
> >>> for a call to a simulation-based halting decider, H, from the
> >>> input program to be recursive; this is compatible with [Strachey
> >>> 1965] and associated proofs which are not recursive in nature.
> >>> Your H is invalid as it aborts the simulation to prevent infinite
> >>> recursion rather than returning an answer to its caller which
> >>> results in it giving the wrong answer for a non-pathological
> >>> input that calls H.
> >>>
> >>> /Flibble
> >>>      
> >>
> >> YOU KEEP DISAGREEING WITH VERIFIED FACTS:
> >>   From a purely software engineering perspective (anchored in the
> >> semantics of the x86 language) it is proven that H(P,P) correctly
> >> predicts that its correct and complete x86 emulation of its input
> >> would never reach the "ret" instruction (final state) of this
> >> input.  
> >   
> > No it doesn't. What you have doesn't work.
> > 
> > /Flibble
> >   
> 
> Try and prove how foolish you are by attempting to refute the above 
> statement on the basis is this paper:
> 
> *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
 
I don't have to consider your "paper"; the evidence is here for all to
see:

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.

[toc] | [prev] | [next] | [standalone]

#53408

Fromolcott <NoOne@NoWhere.com>
Date2022-07-04 12:51 -0500
Message-ID<gv2dnc3XGZgAtV7_nZ2dnUU7_8zNnZ2d@giganews.com>
In reply to#53407
On 7/4/2022 12:39 PM, Mr Flibble wrote:
> On Mon, 4 Jul 2022 12:33:44 -0500
> olcott <NoOne@NoWhere.com> wrote:
> 
>> On 7/4/2022 12:25 PM, Mr Flibble wrote:
>>> On Mon, 4 Jul 2022 11:54:55 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>    
>>>> On 7/4/2022 10:58 AM, Mr Flibble wrote:
>>>>> On Mon, 4 Jul 2022 09:45:45 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>       
>>>>>> No one can provide any "rebuttal" of my paper on any other basis
>>>>>> than
>>>>>>
>>>>>> (1) disagreeing with the semantics of the x86 language
>>>>>> *x86 Instruction Set Reference* https://c9x.me/x86/
>>>>>>
>>>>>> *or disagreeing with this necessarily true principle*
>>>>>> (2) 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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(P,P) correctly determines that its input never halts
>>>>>
>>>>> As I have shown with my signaling halting decider there is no need
>>>>> for a call to a simulation-based halting decider, H, from the
>>>>> input program to be recursive; this is compatible with [Strachey
>>>>> 1965] and associated proofs which are not recursive in nature.
>>>>> Your H is invalid as it aborts the simulation to prevent infinite
>>>>> recursion rather than returning an answer to its caller which
>>>>> results in it giving the wrong answer for a non-pathological
>>>>> input that calls H.
>>>>>
>>>>> /Flibble
>>>>>       
>>>>
>>>> YOU KEEP DISAGREEING WITH VERIFIED FACTS:
>>>>    From a purely software engineering perspective (anchored in the
>>>> semantics of the x86 language) it is proven that H(P,P) correctly
>>>> predicts that its correct and complete x86 emulation of its input
>>>> would never reach the "ret" instruction (final state) of this
>>>> input.
>>>    
>>> No it doesn't. What you have doesn't work.
>>>
>>> /Flibble
>>>    
>>
>> Try and prove how foolish you are by attempting to refute the above
>> statement on the basis is this paper:
>>
>> *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
>   
> I don't have to consider your "paper"; the evidence is here for all to
> see:
> 
> 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.

Your trace always deceitfully leaves out key details.

_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
[00001199][00112013][00001192] 8b4d08     mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51         push ecx
[0000119d][0011200b][000011a2] e8d0fdffff call 00000f72
H: Infinitely Recursive Simulation Detected Simulation Stopped

[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



-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#53409

FromMr Flibble <flibble@reddwarf.jmc>
Date2022-07-04 18:54 +0100
Message-ID<20220704185450.00005552@reddwarf.jmc>
In reply to#53408
On Mon, 4 Jul 2022 12:51:24 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/4/2022 12:39 PM, Mr Flibble wrote:
> > On Mon, 4 Jul 2022 12:33:44 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >   
> >> On 7/4/2022 12:25 PM, Mr Flibble wrote:  
> >>> On Mon, 4 Jul 2022 11:54:55 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>      
> >>>> On 7/4/2022 10:58 AM, Mr Flibble wrote:  
> >>>>> On Mon, 4 Jul 2022 09:45:45 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>         
> >>>>>> No one can provide any "rebuttal" of my paper on any other
> >>>>>> basis than
> >>>>>>
> >>>>>> (1) disagreeing with the semantics of the x86 language
> >>>>>> *x86 Instruction Set Reference* https://c9x.me/x86/
> >>>>>>
> >>>>>> *or disagreeing with this necessarily true principle*
> >>>>>> (2) 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.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 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(P,P) correctly determines that its input never halts  
> >>>>>
> >>>>> As I have shown with my signaling halting decider there is no
> >>>>> need for a call to a simulation-based halting decider, H, from
> >>>>> the input program to be recursive; this is compatible with
> >>>>> [Strachey 1965] and associated proofs which are not recursive
> >>>>> in nature. Your H is invalid as it aborts the simulation to
> >>>>> prevent infinite recursion rather than returning an answer to
> >>>>> its caller which results in it giving the wrong answer for a
> >>>>> non-pathological input that calls H.
> >>>>>
> >>>>> /Flibble
> >>>>>         
> >>>>
> >>>> YOU KEEP DISAGREEING WITH VERIFIED FACTS:
> >>>>    From a purely software engineering perspective (anchored in
> >>>> the semantics of the x86 language) it is proven that H(P,P)
> >>>> correctly predicts that its correct and complete x86 emulation
> >>>> of its input would never reach the "ret" instruction (final
> >>>> state) of this input.  
> >>>    
> >>> No it doesn't. What you have doesn't work.
> >>>
> >>> /Flibble
> >>>      
> >>
> >> Try and prove how foolish you are by attempting to refute the above
> >> statement on the basis is this paper:
> >>
> >> *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
> >>  
> >   
> > I don't have to consider your "paper"; the evidence is here for all
> > to see:
> > 
> > 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.  
> 
> Your trace always deceitfully leaves out key details.

My trace only includes the pertinent details: namely that it gets the
halting decision wrong:

> > Input_Halts = 0

/Flibble

[toc] | [prev] | [next] | [standalone]

#53410

Fromolcott <NoOne@NoWhere.com>
Date2022-07-04 13:00 -0500
Message-ID<7pqdnXJsy5srt17_nZ2dnUU7_83NnZ2d@giganews.com>
In reply to#53409
On 7/4/2022 12:54 PM, Mr Flibble wrote:
> On Mon, 4 Jul 2022 12:51:24 -0500
> olcott <NoOne@NoWhere.com> wrote:
> 
>> On 7/4/2022 12:39 PM, Mr Flibble wrote:
>>> On Mon, 4 Jul 2022 12:33:44 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>    
>>>> On 7/4/2022 12:25 PM, Mr Flibble wrote:
>>>>> On Mon, 4 Jul 2022 11:54:55 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>       
>>>>>> On 7/4/2022 10:58 AM, Mr Flibble wrote:
>>>>>>> On Mon, 4 Jul 2022 09:45:45 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>          
>>>>>>>> No one can provide any "rebuttal" of my paper on any other
>>>>>>>> basis than
>>>>>>>>
>>>>>>>> (1) disagreeing with the semantics of the x86 language
>>>>>>>> *x86 Instruction Set Reference* https://c9x.me/x86/
>>>>>>>>
>>>>>>>> *or disagreeing with this necessarily true principle*
>>>>>>>> (2) 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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(P,P) correctly determines that its input never halts
>>>>>>>
>>>>>>> As I have shown with my signaling halting decider there is no
>>>>>>> need for a call to a simulation-based halting decider, H, from
>>>>>>> the input program to be recursive; this is compatible with
>>>>>>> [Strachey 1965] and associated proofs which are not recursive
>>>>>>> in nature. Your H is invalid as it aborts the simulation to
>>>>>>> prevent infinite recursion rather than returning an answer to
>>>>>>> its caller which results in it giving the wrong answer for a
>>>>>>> non-pathological input that calls H.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>          
>>>>>>
>>>>>> YOU KEEP DISAGREEING WITH VERIFIED FACTS:
>>>>>>     From a purely software engineering perspective (anchored in
>>>>>> the semantics of the x86 language) it is proven that H(P,P)
>>>>>> correctly predicts that its correct and complete x86 emulation
>>>>>> of its input would never reach the "ret" instruction (final
>>>>>> state) of this input.
>>>>>     
>>>>> No it doesn't. What you have doesn't work.
>>>>>
>>>>> /Flibble
>>>>>       
>>>>
>>>> Try and prove how foolish you are by attempting to refute the above
>>>> statement on the basis is this paper:
>>>>
>>>> *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
>>>>   
>>>    
>>> I don't have to consider your "paper"; the evidence is here for all
>>> to see:
>>>
>>> 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.
>>
>> Your trace always deceitfully leaves out key details.
> 
> My trace only includes the pertinent details: namely that it gets the
> halting decision wrong:
> 
>>> Input_Halts = 0
> 
> /Flibble
> 

You continue under the false assumption that a function called in 
infinite recursion must return to its caller. That you continue in the 
false assumption after multiple corrections is a little nuts.

-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#53411

FromMr Flibble <flibble@reddwarf.jmc>
Date2022-07-04 19:38 +0100
Message-ID<20220704193804.0000465f@reddwarf.jmc>
In reply to#53410
On Mon, 4 Jul 2022 13:00:21 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/4/2022 12:54 PM, Mr Flibble wrote:
> > On Mon, 4 Jul 2022 12:51:24 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >   
> >> On 7/4/2022 12:39 PM, Mr Flibble wrote:  
> >>> On Mon, 4 Jul 2022 12:33:44 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>      
> >>>> On 7/4/2022 12:25 PM, Mr Flibble wrote:  
> >>>>> On Mon, 4 Jul 2022 11:54:55 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>         
> >>>>>> On 7/4/2022 10:58 AM, Mr Flibble wrote:  
> >>>>>>> On Mon, 4 Jul 2022 09:45:45 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>            
> >>>>>>>> No one can provide any "rebuttal" of my paper on any other
> >>>>>>>> basis than
> >>>>>>>>
> >>>>>>>> (1) disagreeing with the semantics of the x86 language
> >>>>>>>> *x86 Instruction Set Reference* https://c9x.me/x86/
> >>>>>>>>
> >>>>>>>> *or disagreeing with this necessarily true principle*
> >>>>>>>> (2) 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.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 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(P,P) correctly determines that its input never halts  
> >>>>>>>
> >>>>>>> As I have shown with my signaling halting decider there is no
> >>>>>>> need for a call to a simulation-based halting decider, H, from
> >>>>>>> the input program to be recursive; this is compatible with
> >>>>>>> [Strachey 1965] and associated proofs which are not recursive
> >>>>>>> in nature. Your H is invalid as it aborts the simulation to
> >>>>>>> prevent infinite recursion rather than returning an answer to
> >>>>>>> its caller which results in it giving the wrong answer for a
> >>>>>>> non-pathological input that calls H.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>            
> >>>>>>
> >>>>>> YOU KEEP DISAGREEING WITH VERIFIED FACTS:
> >>>>>>     From a purely software engineering perspective (anchored in
> >>>>>> the semantics of the x86 language) it is proven that H(P,P)
> >>>>>> correctly predicts that its correct and complete x86 emulation
> >>>>>> of its input would never reach the "ret" instruction (final
> >>>>>> state) of this input.  
> >>>>>     
> >>>>> No it doesn't. What you have doesn't work.
> >>>>>
> >>>>> /Flibble
> >>>>>         
> >>>>
> >>>> Try and prove how foolish you are by attempting to refute the
> >>>> above statement on the basis is this paper:
> >>>>
> >>>> *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
> >>>>     
> >>>    
> >>> I don't have to consider your "paper"; the evidence is here for
> >>> all to see:
> >>>
> >>> 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.  
> >>
> >> Your trace always deceitfully leaves out key details.  
> > 
> > My trace only includes the pertinent details: namely that it gets
> > the halting decision wrong:
> >   
> >>> Input_Halts = 0  
> > 
> > /Flibble
> >   
> 
> You continue under the false assumption that a function called in 
> infinite recursion must return to its caller. That you continue in
> the false assumption after multiple corrections is a little nuts.
 
There is no infinite recursion in [Strachey 1965] or associated proofs
and I have shown that there need not be any recursion when using a
simulation-based halting decider; if you have to abort your simulation
to avoid infinite recursion then that just goes to show that your
solution is wrong.

/Flibble

[toc] | [prev] | [next] | [standalone]

#53415

Fromolcott <NoOne@NoWhere.com>
Date2022-07-04 14:09 -0500
Message-ID<j8mdnUHw2JFwp17_nZ2dnUU7_8zNnZ2d@giganews.com>
In reply to#53411
On 7/4/2022 1:38 PM, Mr Flibble wrote:
> On Mon, 4 Jul 2022 13:00:21 -0500
> olcott <NoOne@NoWhere.com> wrote:
> 
>> On 7/4/2022 12:54 PM, Mr Flibble wrote:
>>> On Mon, 4 Jul 2022 12:51:24 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>    
>>>> On 7/4/2022 12:39 PM, Mr Flibble wrote:
>>>>> On Mon, 4 Jul 2022 12:33:44 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>       
>>>>>> On 7/4/2022 12:25 PM, Mr Flibble wrote:
>>>>>>> On Mon, 4 Jul 2022 11:54:55 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>          
>>>>>>>> On 7/4/2022 10:58 AM, Mr Flibble wrote:
>>>>>>>>> On Mon, 4 Jul 2022 09:45:45 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>             
>>>>>>>>>> No one can provide any "rebuttal" of my paper on any other
>>>>>>>>>> basis than
>>>>>>>>>>
>>>>>>>>>> (1) disagreeing with the semantics of the x86 language
>>>>>>>>>> *x86 Instruction Set Reference* https://c9x.me/x86/
>>>>>>>>>>
>>>>>>>>>> *or disagreeing with this necessarily true principle*
>>>>>>>>>> (2) 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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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(P,P) correctly determines that its input never halts
>>>>>>>>>
>>>>>>>>> As I have shown with my signaling halting decider there is no
>>>>>>>>> need for a call to a simulation-based halting decider, H, from
>>>>>>>>> the input program to be recursive; this is compatible with
>>>>>>>>> [Strachey 1965] and associated proofs which are not recursive
>>>>>>>>> in nature. Your H is invalid as it aborts the simulation to
>>>>>>>>> prevent infinite recursion rather than returning an answer to
>>>>>>>>> its caller which results in it giving the wrong answer for a
>>>>>>>>> non-pathological input that calls H.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>             
>>>>>>>>
>>>>>>>> YOU KEEP DISAGREEING WITH VERIFIED FACTS:
>>>>>>>>      From a purely software engineering perspective (anchored in
>>>>>>>> the semantics of the x86 language) it is proven that H(P,P)
>>>>>>>> correctly predicts that its correct and complete x86 emulation
>>>>>>>> of its input would never reach the "ret" instruction (final
>>>>>>>> state) of this input.
>>>>>>>      
>>>>>>> No it doesn't. What you have doesn't work.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>          
>>>>>>
>>>>>> Try and prove how foolish you are by attempting to refute the
>>>>>> above statement on the basis is this paper:
>>>>>>
>>>>>> *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
>>>>>>      
>>>>>     
>>>>> I don't have to consider your "paper"; the evidence is here for
>>>>> all to see:
>>>>>
>>>>> 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.
>>>>
>>>> Your trace always deceitfully leaves out key details.
>>>
>>> My trace only includes the pertinent details: namely that it gets
>>> the halting decision wrong:
>>>    
>>>>> Input_Halts = 0
>>>
>>> /Flibble
>>>    
>>
>> You continue under the false assumption that a function called in
>> infinite recursion must return to its caller. That you continue in
>> the false assumption after multiple corrections is a little nuts.
>   
> There is no infinite recursion in [Strachey 1965] or associated proofs

Only because no one bothered to ever fully examine applying a simulating 
halt decider to the halting theorem counter-examples prior to:

comp.theory: [Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:

> and I have shown that there need not be any recursion when using a
> simulation-based halting decider; 

You have not shown this. One is not free to diverge from the semantics 
specified by the C/x86 source-code. If infinite recursion is specified 
in this source-code then infinite recursion must occur in the execution 
trace until it is aborted.

> if you have to abort your simulation
> to avoid infinite recursion then that just goes to show that your
> solution is wrong.

Actually it proves that my solution is correct. A simulating halt 
decider must always abort its simulation of every non-halting input.

> 
> /Flibble
> 


-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#53416

FromMr Flibble <flibble@reddwarf.jmc>
Date2022-07-04 20:13 +0100
Message-ID<20220704201303.0000350f@reddwarf.jmc>
In reply to#53415
On Mon, 4 Jul 2022 14:09:32 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/4/2022 1:38 PM, Mr Flibble wrote:
> > On Mon, 4 Jul 2022 13:00:21 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >   
> >> On 7/4/2022 12:54 PM, Mr Flibble wrote:  
> >>> On Mon, 4 Jul 2022 12:51:24 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>      
> >>>> On 7/4/2022 12:39 PM, Mr Flibble wrote:  
> >>>>> On Mon, 4 Jul 2022 12:33:44 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>         
> >>>>>> On 7/4/2022 12:25 PM, Mr Flibble wrote:  
> >>>>>>> On Mon, 4 Jul 2022 11:54:55 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>            
> >>>>>>>> On 7/4/2022 10:58 AM, Mr Flibble wrote:  
> >>>>>>>>> On Mon, 4 Jul 2022 09:45:45 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>               
> >>>>>>>>>> No one can provide any "rebuttal" of my paper on any other
> >>>>>>>>>> basis than
> >>>>>>>>>>
> >>>>>>>>>> (1) disagreeing with the semantics of the x86 language
> >>>>>>>>>> *x86 Instruction Set Reference* https://c9x.me/x86/
> >>>>>>>>>>
> >>>>>>>>>> *or disagreeing with this necessarily true principle*
> >>>>>>>>>> (2) 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.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 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(P,P) correctly determines that its input never
> >>>>>>>>>> halts  
> >>>>>>>>>
> >>>>>>>>> As I have shown with my signaling halting decider there is
> >>>>>>>>> no need for a call to a simulation-based halting decider,
> >>>>>>>>> H, from the input program to be recursive; this is
> >>>>>>>>> compatible with [Strachey 1965] and associated proofs which
> >>>>>>>>> are not recursive in nature. Your H is invalid as it aborts
> >>>>>>>>> the simulation to prevent infinite recursion rather than
> >>>>>>>>> returning an answer to its caller which results in it
> >>>>>>>>> giving the wrong answer for a non-pathological input that
> >>>>>>>>> calls H.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>               
> >>>>>>>>
> >>>>>>>> YOU KEEP DISAGREEING WITH VERIFIED FACTS:
> >>>>>>>>      From a purely software engineering perspective
> >>>>>>>> (anchored in the semantics of the x86 language) it is proven
> >>>>>>>> that H(P,P) correctly predicts that its correct and complete
> >>>>>>>> x86 emulation of its input would never reach the "ret"
> >>>>>>>> instruction (final state) of this input.  
> >>>>>>>      
> >>>>>>> No it doesn't. What you have doesn't work.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>            
> >>>>>>
> >>>>>> Try and prove how foolish you are by attempting to refute the
> >>>>>> above statement on the basis is this paper:
> >>>>>>
> >>>>>> *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
> >>>>>>        
> >>>>>     
> >>>>> I don't have to consider your "paper"; the evidence is here for
> >>>>> all to see:
> >>>>>
> >>>>> 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.  
> >>>>
> >>>> Your trace always deceitfully leaves out key details.  
> >>>
> >>> My trace only includes the pertinent details: namely that it gets
> >>> the halting decision wrong:
> >>>      
> >>>>> Input_Halts = 0  
> >>>
> >>> /Flibble
> >>>      
> >>
> >> You continue under the false assumption that a function called in
> >> infinite recursion must return to its caller. That you continue in
> >> the false assumption after multiple corrections is a little nuts.  
> >   
> > There is no infinite recursion in [Strachey 1965] or associated
> > proofs  
> 
> Only because no one bothered to ever fully examine applying a
> simulating halt decider to the halting theorem counter-examples prior
> to:
> 
> comp.theory: [Solution to one instance of the Halting Problem]
> On 3/14/2017 9:05 AM, peteolcott wrote:
> 
> > and I have shown that there need not be any recursion when using a
> > simulation-based halting decider;   
> 
> You have not shown this. One is not free to diverge from the
> semantics specified by the C/x86 source-code. If infinite recursion
> is specified in this source-code then infinite recursion must occur
> in the execution trace until it is aborted.

I have shown this: see my recent post "An idea for a simulating halt
decider" in this forum.

> 
> > if you have to abort your simulation
> > to avoid infinite recursion then that just goes to show that your
> > solution is wrong.  
> 
> Actually it proves that my solution is correct. A simulating halt 
> decider must always abort its simulation of every non-halting input.

No, it proves your solution is incorrect.

/Flibble

[toc] | [prev] | [next] | [standalone]

#53419

FromRichard Damon <Richard@Damon-Family.org>
Date2022-07-04 15:40 -0400
Message-ID<ImHwK.275137$ssF.274580@fx14.iad>
In reply to#53415
On 7/4/22 3:09 PM, olcott wrote:
> On 7/4/2022 1:38 PM, Mr Flibble wrote:
>> On Mon, 4 Jul 2022 13:00:21 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 7/4/2022 12:54 PM, Mr Flibble wrote:
>>>> On Mon, 4 Jul 2022 12:51:24 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 7/4/2022 12:39 PM, Mr Flibble wrote:
>>>>>> On Mon, 4 Jul 2022 12:33:44 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 7/4/2022 12:25 PM, Mr Flibble wrote:
>>>>>>>> On Mon, 4 Jul 2022 11:54:55 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> On 7/4/2022 10:58 AM, Mr Flibble wrote:
>>>>>>>>>> On Mon, 4 Jul 2022 09:45:45 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>> No one can provide any "rebuttal" of my paper on any other
>>>>>>>>>>> basis than
>>>>>>>>>>>
>>>>>>>>>>> (1) disagreeing with the semantics of the x86 language
>>>>>>>>>>> *x86 Instruction Set Reference* https://c9x.me/x86/
>>>>>>>>>>>
>>>>>>>>>>> *or disagreeing with this necessarily true principle*
>>>>>>>>>>> (2) 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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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(P,P) correctly determines that its input never halts
>>>>>>>>>>
>>>>>>>>>> As I have shown with my signaling halting decider there is no
>>>>>>>>>> need for a call to a simulation-based halting decider, H, from
>>>>>>>>>> the input program to be recursive; this is compatible with
>>>>>>>>>> [Strachey 1965] and associated proofs which are not recursive
>>>>>>>>>> in nature. Your H is invalid as it aborts the simulation to
>>>>>>>>>> prevent infinite recursion rather than returning an answer to
>>>>>>>>>> its caller which results in it giving the wrong answer for a
>>>>>>>>>> non-pathological input that calls H.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> YOU KEEP DISAGREEING WITH VERIFIED FACTS:
>>>>>>>>>      From a purely software engineering perspective (anchored in
>>>>>>>>> the semantics of the x86 language) it is proven that H(P,P)
>>>>>>>>> correctly predicts that its correct and complete x86 emulation
>>>>>>>>> of its input would never reach the "ret" instruction (final
>>>>>>>>> state) of this input.
>>>>>>>> No it doesn't. What you have doesn't work.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> Try and prove how foolish you are by attempting to refute the
>>>>>>> above statement on the basis is this paper:
>>>>>>>
>>>>>>> *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 
>>>>>>>
>>>>>> I don't have to consider your "paper"; the evidence is here for
>>>>>> all to see:
>>>>>>
>>>>>> 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.
>>>>>
>>>>> Your trace always deceitfully leaves out key details.
>>>>
>>>> My trace only includes the pertinent details: namely that it gets
>>>> the halting decision wrong:
>>>>>> Input_Halts = 0
>>>>
>>>> /Flibble
>>>
>>> You continue under the false assumption that a function called in
>>> infinite recursion must return to its caller. That you continue in
>>> the false assumption after multiple corrections is a little nuts.
>> There is no infinite recursion in [Strachey 1965] or associated proofs
> 
> Only because no one bothered to ever fully examine applying a simulating 
> halt decider to the halting theorem counter-examples prior to:
> 
> comp.theory: [Solution to one instance of the Halting Problem]
> On 3/14/2017 9:05 AM, peteolcott wrote:
> 
>> and I have shown that there need not be any recursion when using a
>> simulation-based halting decider; 
> 
> You have not shown this. One is not free to diverge from the semantics 
> specified by the C/x86 source-code. If infinite recursion is specified 
> in this source-code then infinite recursion must occur in the execution 
> trace until it is aborted.

Rigth, so YOUR answer is wrong, as your simulator doesn't actually 
simulate all of its input, since it doesn't simulate the code at the 
results of the call H instruction, but replaces it with something that 
is actually DIFFERENT then the actual H routine.

You have said that H(P,P) return 0, so a correct emulation of a call to 
H with parameters P and P, needs to return 0.

> 
>> if you have to abort your simulation
>> to avoid infinite recursion then that just goes to show that your
>> solution is wrong.
> 
> Actually it proves that my solution is correct. A simulating halt 
> decider must always abort its simulation of every non-halting input.

Except that if H(P,P) aborts its simulation and returns 0, then the 
input is Halting.

Note H(P,P) must refer to P(P) or your P isn't defined per the 
specification.

> 
>>
>> /Flibble
>>
> 
>

[toc] | [prev] | [next] | [standalone]

#53413

FromRichard Damon <Richard@Damon-Family.org>
Date2022-07-04 15:02 -0400
Message-ID<BPGwK.359495$70j.108436@fx16.iad>
In reply to#53399
On 7/4/22 10:45 AM, olcott wrote:
> No one can provide any "rebuttal" of my paper on any other basis
> than
> 
> (1) disagreeing with the semantics of the x86 language
> *x86 Instruction Set Reference* https://c9x.me/x86/

Which says that a call H instruction should be followed by the ACTUAL H 
code, not an approximation.

Note, since you claim H(P,P) is correct in returning 0, that means that 
it must actually DO that, so it is KNOWN that a call H will return after 
some finite time, and NOT get into an "infinite recursion loop".

It is a fundamental fact that a given sequence of x86 instructions, 
given the same input will give the same results, so your claim that the 
correct emulation of the call to H(P,P) can differ from the actual 
behavior of H(P,P) is necessarily incorrect.

> 
> *or disagreeing with this necessarily true principle*
> (2) 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.
> 

Right, and as mentioned below, the ACTUAL behavior or the input to 
H(P,P) is the behavior of P(P) or your either P or H are defined 
incorrectly.

Your claim that they must differ is incorrect, and your "proof" is based 
on assuming incorrect assuptions.

> 
> 
> 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(P,P) correctly determines that its input never halts
> 
> typedef void (*ptr)();
> 
> void P(ptr x)
> {
>    if (H(x, x))
>      HERE: goto HERE;
>    return;
> }
> 
> int main()
> {
>    Output("Input_Halts = ", H(P, P));
> }
> 
> As shown below the above P and H have the required (halting problem) 
> pathological relationship to each other:

ONLY if H(P,P) referes to the actual behavior of P(P).

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

Which still has an incorrect (b) since the ACTUAL rule this is based on 
looks at the WHOLE loop, so includes the code in H, which DOES have the 
needed conditional.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.theory

csiph-web