Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

May Euell Gibbons eat your only copy of the manual!


devel / comp.theory / Halting problem proofs refuted on the basis of software engineering

SubjectAuthor
* Halting problem proofs refuted on the basis of software engineeringolcott
+* Halting problem proofs refuted on the basis of softwareMr Flibble
|`* Halting problem proofs refuted on the basis of softwareolcott
| +* Halting problem proofs refuted on the basis of softwareMr Flibble
| |`* Halting problem proofs refuted on the basis of softwareolcott
| | `* Halting problem proofs refuted on the basis of softwareMr Flibble
| |  `* Halting problem proofs refuted on the basis of softwareolcott
| |   `* Halting problem proofs refuted on the basis of softwareMr Flibble
| |    `* Halting problem proofs refuted on the basis of softwareolcott
| |     `* Halting problem proofs refuted on the basis of softwareMr Flibble
| |      `* Halting problem proofs refuted on the basis of softwareolcott
| |       +* Halting problem proofs refuted on the basis of softwareMr Flibble
| |       |`* Halting problem proofs refuted on the basis of softwareolcott
| |       | `* Halting problem proofs refuted on the basis of softwareMr Flibble
| |       |  `* Halting problem proofs refuted on the basis of softwareolcott
| |       |   +* Halting problem proofs refuted on the basis of softwareMr Flibble
| |       |   |`* Halting problem proofs refuted on the basis of softwareolcott
| |       |   | `* Halting problem proofs refuted on the basis of softwareMr Flibble
| |       |   |  `* Halting problem proofs refuted on the basis of softwareolcott
| |       |   |   `* Halting problem proofs refuted on the basis of softwareMr Flibble
| |       |   |    `* Halting problem proofs refuted on the basis of softwareolcott
| |       |   |     +- Halting problem proofs refuted on the basis of softwareMr Flibble
| |       |   |     `* Halting problem proofs refuted on the basis of software engineeringdklei...@gmail.com
| |       |   |      +* Halting problem proofs refuted on the basis of softwareolcott
| |       |   |      |`- Halting problem proofs refuted on the basis of softwareRichard Damon
| |       |   |      `* Halting problem proofs refuted on the basis of software engineeringdklei...@gmail.com
| |       |   |       +* Halting problem proofs refuted on the basis of softwareolcott
| |       |   |       |+- Halting problem proofs refuted on the basis of softwareRichard Damon
| |       |   |       |`* Halting problem proofs refuted on the basis of software engineeringMikko
| |       |   |       | `* Halting problem proofs refuted on the basis of softwareolcott
| |       |   |       |  +- Halting problem proofs refuted on the basis of software engineeringolcott
| |       |   |       |  `- Halting problem proofs refuted on the basis of softwareRichard Damon
| |       |   |       `* Halting problem proofs refuted on the basis of software engineeringdklei...@gmail.com
| |       |   |        +* Halting problem proofs refuted on the basis of softwareolcott
| |       |   |        |`- Halting problem proofs refuted on the basis of softwareRichard Damon
| |       |   |        `* Halting problem proofs refuted on the basis of software engineeringdklei...@gmail.com
| |       |   |         +* Halting problem proofs refuted on the basis of softwareolcott
| |       |   |         |`- Halting problem proofs refuted on the basis of softwareolcott
| |       |   |         +- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |         `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |          +- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |          +* _Halting_problem_proofs_refuted_on_the_basis_of_softAndré G. Isaak
| |       |   |          |`* _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |          | `- _Halting_problem_proofs_refuted_on_the_basis_of_softRichard Damon
| |       |   |          +* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |          |`* _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |          | `- _Halting_problem_proofs_refuted_on_the_basis_of_softRichard Damon
| |       |   |          `* Halting problem proofs refuted on the basis of softwareBen Bacarisse
| |       |   |           +- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |           +- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |           `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |            +- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |            `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |             +* _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |             |`* _Halting_problem_proofs_refuted_on_the_basis_of_software_engineering_[_Curry–Howolcott
| |       |   |             | +* _Halting_problem_proofs_refuted_on_the_basis_of_software_engineering_[_Curry–Howolcott
| |       |   |             | |`- _Halting_problem_proofs_refuted_on_the_basis_of_software_engineering_[_Curry–Howolcott
| |       |   |             | `- _Halting_problem_proofs_refuted_on_the_basis_of_softRichard Damon
| |       |   |             `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |              `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |               `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |                `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |                 +- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |                 `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |                  +- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |                  +* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |                  |`- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |                  `* _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |                   +* Halting problem proofs refuted on the basis of software engineering [ Irrefutablolcott
| |       |   |                   |`- Halting problem proofs refuted on the basis of softwareRichard Damon
| |       |   |                   `* Halting problem proofs refuted on the basis of softwaredklei...@gmail.com
| |       |   |                    `* Halting problem proofs refuted on the basis of software engineering [ Irrefutablolcott
| |       |   |                     `- Halting problem proofs refuted on the basis of softwareRichard Damon
| |       |   `- Halting problem proofs refuted on the basis of softwareRichard Damon
| |       `- Halting problem proofs refuted on the basis of softwareRichard Damon
| `- Halting problem proofs refuted on the basis of softwareRichard Damon
+- Halting problem proofs refuted on the basis of software engineeringolcott
+* Halting problem proofs refuted on the basis of softwareRichard Damon
|`* Halting problem proofs refuted on the basis of softwareolcott
| `- Halting problem proofs refuted on the basis of softwareRichard Damon
+- Halting problem proofs refuted on the basis of softwareHenrietta Stinkbottom
`* Halting problem proofs refuted on the basis of software engineeringwij
 `* Halting problem proofs refuted on the basis of softwareolcott
  +- Halting problem proofs refuted on the basis of softwareRichard Damon
  `* Halting problem proofs refuted on the basis of software engineeringPaul N
   `* Halting problem proofs refuted on the basis of softwareolcott
    `* Halting problem proofs refuted on the basis of software engineeringPaul N
     `* Halting problem proofs refuted on the basis of softwareolcott
      +* Halting problem proofs refuted on the basis of software engineeringwij
      |`* Halting problem proofs refuted on the basis of softwareolcott
      | `* Halting problem proofs refuted on the basis of software engineeringwij
      |  `* Halting problem proofs refuted on the basis of softwareolcott
      |   +- Halting problem proofs refuted on the basis of softwareRichard Damon
      |   `* Halting problem proofs refuted on the basis of software engineeringwij
      |    `* Halting problem proofs refuted on the basis of software engineeringolcott
      |     +* Halting problem proofs refuted on the basis of software engineeringwij
      |     |`* Halting problem proofs refuted on the basis of softwareolcott
      |     | `- Halting problem proofs refuted on the basis of software engineeringwij
      |     `- Halting problem proofs refuted on the basis of softwareRichard Damon
      +- Halting problem proofs refuted on the basis of softwareRichard Damon
      `* Halting problem proofs refuted on the basis of software engineeringPaul N

Pages:12345
Halting problem proofs refuted on the basis of software engineering

<EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35281&group=comp.theory#35281

 copy link   Newsgroups: comp.theory comp.lang.c comp.lang.c++ comp.software-eng
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 02 Jul 2022 10:34:35 -0500
Date: Sat, 2 Jul 2022 10:34:34 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Newsgroups: comp.theory,comp.lang.c,comp.lang.c++,comp.software-eng
Content-Language: en-US
From: NoO...@NoWhere.com (olcott)
Subject: Halting problem proofs refuted on the basis of software engineering
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 45
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-SUid2CSyPNA58Mhr0+uWP12vodiCXLZZN8YjS84yYXdZUsV0bSEdaR5Z8XSSoq9lCQyHvV5MJgpvxRJ!FVTGQWB8kMxDmaaCQ4n0PUAL1D0YqR8vnK6fZxwUjPNAAbDCqH9xaP2B9KyWKF94Fh+U4vELcFqZ
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2577
X-Received-Bytes: 2699
 by: olcott - Sat, 2 Jul 2022 15:34 UTC

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

--
Copyright 2022 Pete Olcott

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

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

<20220702172644.00004e9c@reddwarf.jmc>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35282&group=comp.theory#35282

 copy link   Newsgroups: comp.theory comp.lang.c comp.lang.c++ comp.software-eng
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx07.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory,comp.lang.c,comp.lang.c++,comp.software-eng
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Message-ID: <20220702172644.00004e9c@reddwarf.jmc>
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 70
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sat, 02 Jul 2022 16:26:38 UTC
Date: Sat, 2 Jul 2022 17:26:44 +0100
X-Received-Bytes: 3168
 by: Mr Flibble - Sat, 2 Jul 2022 16:26 UTC

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

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

<K4SdnSkj6Y6Z7l3_nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35283&group=comp.theory#35283

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 02 Jul 2022 11:32:04 -0500
Date: Sat, 2 Jul 2022 11:32:03 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software engineering
Content-Language: en-US
Newsgroups: comp.theory
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com> <1b0800fd-375d-4abf-a722-54a09efc49dan@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <1b0800fd-375d-4abf-a722-54a09efc49dan@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <K4SdnSkj6Y6Z7l3_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 16
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-YVvAk+opz6s+nWpFlo54pddg68FL1Od7/7VqVqnpMEC6Pjodj2ohUD/BtK4BAZYsPMvo0Nj2vb5Soik!+VW5bzDLU7qFU1YhlVmO2nphDyroriLYlyNyOXzo7YPhNtJGIa5mjOY8B0RO5m78rFhnxhjjXEwx
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 1915
X-Received-Bytes: 2052
 by: olcott - Sat, 2 Jul 2022 16:32 UTC

On 7/2/2022 11:20 AM, dklei...@gmail.com wrote:
> On Saturday, July 2, 2022 at 8:34:42 AM UTC-7, olcott wrote:
>>
>> *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
>>
> The researchgate article is a great improvement over your comp.theory posts. Maybe I will get up enough gumption to try to grasp it.

Thanks

--
Copyright 2022 Pete Olcott

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

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

<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35284&group=comp.theory#35284

 copy link   Newsgroups: comp.theory comp.software-eng sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 02 Jul 2022 11:42:49 -0500
Date: Sat, 2 Jul 2022 11:42:48 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,comp.software-eng,sci.logic,sci.math
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <20220702172644.00004e9c@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 162
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-D6kSfB+Y6NlawVGep1f5XtQK1JjGn6XrTXWlxqwtd+z6TZjj9XJpYKSd/lObR3nP6ovSl4z9kLelQBR!t4ubxQg6Kx7OEf46dyq67lI76bcrYN4VogNz88ekeG+A9ma1nZHbCf/IgTF9d/V9dMMGQDfTK0wn
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7164
X-Received-Bytes: 7255
 by: olcott - Sat, 2 Jul 2022 16:42 UTC

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

--
Copyright 2022 Pete Olcott

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

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

<20220702181010.000011c0@reddwarf.jmc>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35285&group=comp.theory#35285

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx07.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Message-ID: <20220702181010.000011c0@reddwarf.jmc>
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 172
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sat, 02 Jul 2022 17:10:04 UTC
Date: Sat, 2 Jul 2022 18:10:10 +0100
X-Received-Bytes: 7206
 by: Mr Flibble - Sat, 2 Jul 2022 17:10 UTC

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

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

<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35286&group=comp.theory#35286

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 02 Jul 2022 12:15:59 -0500
Date: Sat, 2 Jul 2022 12:15:58 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220702181010.000011c0@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 194
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Rj8+dhCYOJOOXLFGwYR1I7Puc2uGT+odYWzcCBM4nyDz9iOJEuWm5/q184JamZBgQQrpJWFZckzJU2/!zrRJAa80cbyiLEDsn13goEfjCxNY8CBfnpyZI3kklmyk/dk9MDV3lumnEKdGZzekraP4YMXI+8+S
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 8828
 by: olcott - Sat, 2 Jul 2022 17:15 UTC

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)

H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts
H correctly determines that P() never halts

*This is necessarily true thus impossibly false*
Every simulating halt decider that correctly simulates its input until
it correctly determines that this simulated input would never reach its
final state, correctly rejects this input as non-halting.

*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

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

<20220702182653.00003f52@reddwarf.jmc>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35287&group=comp.theory#35287

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx01.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Message-ID: <20220702182653.00003f52@reddwarf.jmc>
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 182
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sat, 02 Jul 2022 17:26:47 UTC
Date: Sat, 2 Jul 2022 18:26:53 +0100
X-Received-Bytes: 8246
 by: Mr Flibble - Sat, 2 Jul 2022 17:26 UTC

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

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

<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35288&group=comp.theory#35288

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 02 Jul 2022 12:30:04 -0500
Date: Sat, 2 Jul 2022 12:30:03 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220702182653.00003f52@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 195
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-o3K3FwYGOefFQ9k9sjKcaa0JevYaeR/HcW/kOtyUSWqgPiKyM9UKJvfLo9Bzrccxd6ikk4uPWYmNTbK!2r+EBnDOeimoTZwkqTJ9PIG5IbwwrpVrghGcl5Kd6aq4Udkqx7oaeVUaQowZjIO8zMDq/nAj6ZKU
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 9185
 by: olcott - Sat, 2 Jul 2022 17:30 UTC

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
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering

<20220702192847.00000807@reddwarf.jmc>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35290&group=comp.theory#35290

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx04.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Message-ID: <20220702192847.00000807@reddwarf.jmc>
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 200
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sat, 02 Jul 2022 18:28:42 UTC
Date: Sat, 2 Jul 2022 19:28:47 +0100
X-Received-Bytes: 9305
 by: Mr Flibble - Sat, 2 Jul 2022 18:28 UTC

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.

Click here to read the complete article

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

<6i0wK.31269$Qd2.9293@fx37.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35292&group=comp.theory#35292

 copy link   Newsgroups: comp.theory comp.lang.c comp.lang.c++
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx37.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,comp.lang.c,comp.lang.c++
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 55
Message-ID: <6i0wK.31269$Qd2.9293@fx37.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 2 Jul 2022 14:40:02 -0400
X-Received-Bytes: 2876
 by: Richard Damon - Sat, 2 Jul 2022 18:40 UTC

On 7/2/22 11:34 AM, olcott 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

Except that if H(P,P) actually returns 0, then P(P) will halt, so H is
wrong.

You can't just define the wrong answer to be right. And, your dishonest
dodge that H(P,P) doesn't actually refer to P(P) says that P isn't the
program you claim, as the P is DEFINED to ask H about ITSELF with its
input, so if H(P,P) doesn't mean that, then you have defined something
wrong.

The problem is your logic doesn't actually correctly consider the
behavior of the H being called, so doesn't actually do a correct x86
emulation of its input.

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

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

<3O2dnX_5sOHXDF3_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35293&group=comp.theory#35293

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!3.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 02 Jul 2022 13:41:14 -0500
Date: Sat, 2 Jul 2022 13:41:14 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
<20220702192847.00000807@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220702192847.00000807@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <3O2dnX_5sOHXDF3_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 235
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-fHZjR16Jb3Mh8oExkCZwsH0dfVtXLs0M9+fx9OS6urLA79FCkXYtfj6wELiVIxShIRcekiD73MN05YR!RIpbf5dvAEpBxz3012e49tIxAJvAlzyupzywCUkB3bDsc2dOSjONht6jbYUEFYQJMvmjEioIhDMR
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 10704
 by: olcott - Sat, 2 Jul 2022 18:41 UTC

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
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering

<fk0wK.31270$Qd2.25823@fx37.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35294&group=comp.theory#35294

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx37.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 172
Message-ID: <fk0wK.31270$Qd2.25823@fx37.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 2 Jul 2022 14:42:19 -0400
X-Received-Bytes: 7697
 by: Richard Damon - Sat, 2 Jul 2022 18:42 UTC

On 7/2/22 12:42 PM, olcott 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.

And HERE IS YOUR PROBLEM ^^^^^

That statement isn't actually a correct basis for deciding Halting, as
it IGNORES parts of the actual probram P, as defined by the x86
languages, as that includes the code for H that it calls.

> (c) H aborts its emulation of Px before its call to H is emulated.

And thus made a WRONG decision, as it INCORRECTLY presumes that H(P,P)
will never return, when it does.

FAIL.

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

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

<20220702194448.00005117@reddwarf.jmc>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35295&group=comp.theory#35295

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx04.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Message-ID: <20220702194448.00005117@reddwarf.jmc>
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
<20220702192847.00000807@reddwarf.jmc>
<3O2dnX_5sOHXDF3_nZ2dnUU7_81g4p2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 259
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sat, 02 Jul 2022 18:44:43 UTC
Date: Sat, 2 Jul 2022 19:44:48 +0100
X-Received-Bytes: 11356
 by: Mr Flibble - Sat, 2 Jul 2022 18:44 UTC

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]


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering

<t9q44j$u8k$2@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35296&group=comp.theory#35296

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!42V55DPF/EHESwy7gmIc+w.user.46.165.242.75.POSTED!not-for-mail
From: hen...@galabbogosutionallity.net (Henrietta Stinkbottom)
Newsgroups: comp.theory
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Date: Sat, 2 Jul 2022 11:52:03 -0700
Organization: The Upstairs Milpitas Retarded Faggot Club for Gay Nazis
Message-ID: <t9q44j$u8k$2@gioia.aioe.org>
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
Reply-To: henri@galabbogosutionallity.net
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="30996"; posting-host="42V55DPF/EHESwy7gmIc+w.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.9.2
 by: Henrietta Stinkbotto - Sat, 2 Jul 2022 18:52 UTC

On 7/2/2022 8:34 AM, olcott wrote:
> This much more concise version of my paper focuseses on the actual
> execution of my three truly idiotic examples.

Post it 247,321 more times you impotent blithering wankmaggot.

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

<S-mdnfRt7a-LJV3_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35299&group=comp.theory#35299

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 02 Jul 2022 16:26:45 -0500
Date: Sat, 2 Jul 2022 16:26:45 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
<20220702192847.00000807@reddwarf.jmc>
<3O2dnX_5sOHXDF3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702194448.00005117@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220702194448.00005117@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <S-mdnfRt7a-LJV3_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 350
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-9LiGxP3It7BXK0Dil8beAjB/cmk5PRtswBJxuGEZv1Cy6YQe0L+MpKyIVipsGCE2rRkFWGkiBbEr7UY!6AFFOr9p+hWv8MLclWK/iReNlNNstV9lJ0Vso5nMLJdQ0xmm7ZLFWjGBwEtt50e/B27S/hx9feW3
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 15334
X-Received-Bytes: 15427
 by: olcott - Sat, 2 Jul 2022 21:26 UTC

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
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering

<20220702230537.00001259@reddwarf.jmc>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35300&group=comp.theory#35300

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx05.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Message-ID: <20220702230537.00001259@reddwarf.jmc>
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
<20220702192847.00000807@reddwarf.jmc>
<3O2dnX_5sOHXDF3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702194448.00005117@reddwarf.jmc>
<S-mdnfRt7a-LJV3_nZ2dnUU7_81g4p2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 360
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sat, 02 Jul 2022 22:05:31 UTC
Date: Sat, 2 Jul 2022 23:05:37 +0100
X-Received-Bytes: 15785
 by: Mr Flibble - Sat, 2 Jul 2022 22:05 UTC

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

Click here to read the complete article

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

<avudncmA4ZtwX13_nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35301&group=comp.theory#35301

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 02 Jul 2022 17:13:01 -0500
Date: Sat, 2 Jul 2022 17:13:01 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
<20220702192847.00000807@reddwarf.jmc>
<3O2dnX_5sOHXDF3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702194448.00005117@reddwarf.jmc>
<S-mdnfRt7a-LJV3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702230537.00001259@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220702230537.00001259@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <avudncmA4ZtwX13_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 375
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-P9Kkp13smoGNk2Sbmw2yD3ferenzeqE0Ik/lAvSIxF3ze+ya7/L2sY+AFv5Rf5Jo3FjCNcSdBCm77Wz!vAVBVPoFnxLDi/6mRjsWZ1+ftgezywef6ejNUBxdGqYaKThMwzm7LRfm20zkwvHzX9K8COrK3Cnm
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 16983
 by: olcott - Sat, 2 Jul 2022 22:13 UTC

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


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering

<sx4wK.34822$dh2.610@fx46.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35302&group=comp.theory#35302

 copy link   Newsgroups: comp.theory sci.logic sci.math
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx46.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
<20220702192847.00000807@reddwarf.jmc>
<3O2dnX_5sOHXDF3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702194448.00005117@reddwarf.jmc>
<S-mdnfRt7a-LJV3_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <S-mdnfRt7a-LJV3_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 352
Message-ID: <sx4wK.34822$dh2.610@fx46.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 2 Jul 2022 19:29:21 -0400
X-Received-Bytes: 16668
 by: Richard Damon - Sat, 2 Jul 2022 23:29 UTC

On 7/2/22 5:26 PM, olcott 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.
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering

<20220703152751.00001f74@reddwarf.jmc>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35303&group=comp.theory#35303

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!npeer.as286.net!npeer-ng0.as286.net!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx02.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Message-ID: <20220703152751.00001f74@reddwarf.jmc>
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
<20220702192847.00000807@reddwarf.jmc>
<3O2dnX_5sOHXDF3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702194448.00005117@reddwarf.jmc>
<S-mdnfRt7a-LJV3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702230537.00001259@reddwarf.jmc>
<avudncmA4ZtwX13_nZ2dnUU7_8xh4p2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 377
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sun, 03 Jul 2022 14:27:44 UTC
Date: Sun, 3 Jul 2022 15:27:51 +0100
X-Received-Bytes: 17402
 by: Mr Flibble - Sun, 3 Jul 2022 14:27 UTC

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.


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering

<Y72dndpURKjqM1z_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35304&group=comp.theory#35304

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 03 Jul 2022 09:57:59 -0500
Date: Sun, 3 Jul 2022 09:57:57 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
<20220702192847.00000807@reddwarf.jmc>
<3O2dnX_5sOHXDF3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702194448.00005117@reddwarf.jmc>
<S-mdnfRt7a-LJV3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702230537.00001259@reddwarf.jmc>
<avudncmA4ZtwX13_nZ2dnUU7_8xh4p2d@giganews.com>
<20220703152751.00001f74@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220703152751.00001f74@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <Y72dndpURKjqM1z_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 393
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-LFaAaWko/Hiw//uJB4Lm0jLGjuyjgSG7THz5QyPDutYC/QXZ+iGg/53SWCXqMF1sBa9aHhwu0KAg0Y8!OTfCcbpGURVBK11WGAMf+N+5dwChA9ZmCZDhZn0s19E/Ml0qbEXbXgHgqP3NlTFUopM5xhhOfVqn
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 18542
 by: olcott - Sun, 3 Jul 2022 14:57 UTC

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
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering

<20220703162148.00001389@reddwarf.jmc>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35305&group=comp.theory#35305

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx01.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Message-ID: <20220703162148.00001389@reddwarf.jmc>
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
<20220702192847.00000807@reddwarf.jmc>
<3O2dnX_5sOHXDF3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702194448.00005117@reddwarf.jmc>
<S-mdnfRt7a-LJV3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702230537.00001259@reddwarf.jmc>
<avudncmA4ZtwX13_nZ2dnUU7_8xh4p2d@giganews.com>
<20220703152751.00001f74@reddwarf.jmc>
<Y72dndpURKjqM1z_nZ2dnUU7_8zNnZ2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 400
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sun, 03 Jul 2022 15:21:41 UTC
Date: Sun, 3 Jul 2022 16:21:48 +0100
X-Received-Bytes: 19008
 by: Mr Flibble - Sun, 3 Jul 2022 15:21 UTC

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.

Click here to read the complete article

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

<Eqednf7muZ26K1z_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35306&group=comp.theory#35306

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 03 Jul 2022 10:30:46 -0500
Date: Sun, 3 Jul 2022 10:30:45 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
<20220702192847.00000807@reddwarf.jmc>
<3O2dnX_5sOHXDF3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702194448.00005117@reddwarf.jmc>
<S-mdnfRt7a-LJV3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702230537.00001259@reddwarf.jmc>
<avudncmA4ZtwX13_nZ2dnUU7_8xh4p2d@giganews.com>
<20220703152751.00001f74@reddwarf.jmc>
<Y72dndpURKjqM1z_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220703162148.00001389@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220703162148.00001389@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <Eqednf7muZ26K1z_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 414
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-e78ubDoyN7pwamUFulcmyHlpVc+NbEuZsMRApY0VwVaHOlE2oUDWlprjj9tnd5+JIs5xDGScBpPTQ/I!Yn5FrBgrvzb9RDDnRGZmAXU4LVV6AQJ39UsWBAQ3nShDyOUVqqDTGN+BPi7nbNIGjcaNocZVhif9
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 19934
 by: olcott - Sun, 3 Jul 2022 15:30 UTC

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
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering

<20220703164543.00004b55@reddwarf.jmc>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35307&group=comp.theory#35307

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx01.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Message-ID: <20220703164543.00004b55@reddwarf.jmc>
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
<20220702192847.00000807@reddwarf.jmc>
<3O2dnX_5sOHXDF3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702194448.00005117@reddwarf.jmc>
<S-mdnfRt7a-LJV3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702230537.00001259@reddwarf.jmc>
<avudncmA4ZtwX13_nZ2dnUU7_8xh4p2d@giganews.com>
<20220703152751.00001f74@reddwarf.jmc>
<Y72dndpURKjqM1z_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220703162148.00001389@reddwarf.jmc>
<Eqednf7muZ26K1z_nZ2dnUU7_81g4p2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 420
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sun, 03 Jul 2022 15:45:37 UTC
Date: Sun, 3 Jul 2022 16:45:43 +0100
X-Received-Bytes: 20736
 by: Mr Flibble - Sun, 3 Jul 2022 15:45 UTC

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.

Click here to read the complete article

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

<kcKdnc6XHIvZJ1z_nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35309&group=comp.theory#35309

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 03 Jul 2022 10:48:20 -0500
Date: Sun, 3 Jul 2022 10:48:18 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
<20220702192847.00000807@reddwarf.jmc>
<3O2dnX_5sOHXDF3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702194448.00005117@reddwarf.jmc>
<S-mdnfRt7a-LJV3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702230537.00001259@reddwarf.jmc>
<avudncmA4ZtwX13_nZ2dnUU7_8xh4p2d@giganews.com>
<20220703152751.00001f74@reddwarf.jmc>
<Y72dndpURKjqM1z_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220703162148.00001389@reddwarf.jmc>
<Eqednf7muZ26K1z_nZ2dnUU7_81g4p2d@giganews.com>
<20220703164543.00004b55@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220703164543.00004b55@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <kcKdnc6XHIvZJ1z_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 431
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-DfSgYXKzajZjWnJDFmnsf4nF3joX07P6r5+DlIDN3VgDLdBQ8wAdqaUhpFYNexmTWfxxrXpDb7Qv+jG!icrzfsJto7XQibeEfcHP8JeYo6zAlVgm15xpCw8r+zW28+dIAZxs67UvrDltPcTF86fsiblQUPjZ
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 21594
 by: olcott - Sun, 3 Jul 2022 15:48 UTC

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
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering

<20220703165111.00006d29@reddwarf.jmc>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35310&group=comp.theory#35310

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!news.neodome.net!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx01.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Message-ID: <20220703165111.00006d29@reddwarf.jmc>
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
<20220702192847.00000807@reddwarf.jmc>
<3O2dnX_5sOHXDF3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702194448.00005117@reddwarf.jmc>
<S-mdnfRt7a-LJV3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702230537.00001259@reddwarf.jmc>
<avudncmA4ZtwX13_nZ2dnUU7_8xh4p2d@giganews.com>
<20220703152751.00001f74@reddwarf.jmc>
<Y72dndpURKjqM1z_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220703162148.00001389@reddwarf.jmc>
<Eqednf7muZ26K1z_nZ2dnUU7_81g4p2d@giganews.com>
<20220703164543.00004b55@reddwarf.jmc>
<kcKdnc6XHIvZJ1z_nZ2dnUU7_8xh4p2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 439
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sun, 03 Jul 2022 15:51:05 UTC
Date: Sun, 3 Jul 2022 16:51:11 +0100
X-Received-Bytes: 22187
 by: Mr Flibble - Sun, 3 Jul 2022 15:51 UTC

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.

Click here to read the complete article

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor