Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #53330 > unrolled thread
| Started by | olcott <NoOne@NoWhere.com> |
|---|---|
| First post | 2022-07-02 10:34 -0500 |
| Last post | 2022-07-16 21:40 -0500 |
| Articles | 20 on this page of 125 — 12 participants |
Back to article view | Back to comp.theory
Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 10:34 -0500
Re: Halting problem proofs refuted on the basis of software engineering "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-02 09:20 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 11:32 -0500
Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-02 17:26 +0100
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 11:42 -0500
Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-02 18:10 +0100
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 12:15 -0500
Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-02 18:26 +0100
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 12:30 -0500
Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-02 19:28 +0100
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 13:41 -0500
Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-02 19:44 +0100
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 16:26 -0500
Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-02 23:05 +0100
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-02 17:13 -0500
Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-03 15:27 +0100
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-03 09:57 -0500
Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-03 16:21 +0100
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-03 10:30 -0500
Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-03 16:45 +0100
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-03 10:48 -0500
Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-03 16:51 +0100
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-03 11:05 -0500
Re: Halting problem proofs refuted on the basis of software engineering Mr Flibble <flibble@reddwarf.jmc> - 2022-07-03 17:07 +0100
Re: Halting problem proofs refuted on the basis of software engineering "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-03 12:35 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-03 14:51 -0500
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-03 16:21 -0400
Re: Halting problem proofs refuted on the basis of software engineering "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-03 16:10 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-03 19:44 -0500
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-04 07:45 -0400
Re: Halting problem proofs refuted on the basis of software engineering "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-04 09:36 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-04 11:57 -0500
Re: Halting problem proofs refuted on the basis of software engineering "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-04 11:42 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-04 14:17 -0500
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-04 14:21 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-04 18:08 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-05 11:50 -0700
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-05 14:31 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-05 16:21 -0700
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-05 18:37 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] Richard Damon <Richard@Damon-Family.org> - 2022-07-05 22:18 -0400
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] André G. Isaak <agisaak@gm.invalid> - 2022-07-05 14:24 -0600
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-05 15:42 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] Richard Damon <Richard@Damon-Family.org> - 2022-07-05 19:29 -0400
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-06 00:53 +0100
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-05 19:01 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-05 21:00 -0700
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-05 23:02 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-06 13:58 -0700
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-06 16:13 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-07 12:19 -0700
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-07 14:39 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-07 13:54 -0700
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-07 16:08 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-07 17:36 -0700
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-07 20:34 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-07 21:35 -0700
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-07 23:48 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-07 23:09 -0700
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-08 07:54 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-08 10:59 -0700
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-08 13:02 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-08 17:48 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Irrefutably Correct ] olcott <NoOne@NoWhere.com> - 2022-07-09 08:16 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Irrefutably Correct ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-07-09 10:22 -0700
Re: Halting problem proofs refuted on the basis of software engineering [ Irrefutably Correct ] olcott <NoOne@NoWhere.com> - 2022-07-09 13:40 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ Irrefutably Correct ] Richard Damon <Richard@Damon-Family.org> - 2022-07-09 15:06 -0400
Re: Halting problem proofs refuted on the basis of software engineering [ Irrefutably Correct ] Richard Damon <Richard@Damon-Family.org> - 2022-07-09 14:18 -0400
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] Richard Damon <Richard@Damon-Family.org> - 2022-07-07 22:16 -0400
Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] olcott <NoOne@NoWhere.com> - 2022-07-05 19:50 -0500
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-04 15:05 -0400
Re: Halting problem proofs refuted on the basis of software engineering Mikko <mikko.levanto@iki.fi> - 2022-07-05 11:53 +0300
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-05 07:59 -0500
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-05 08:00 -0500
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-05 19:31 -0400
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-03 13:34 -0400
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-02 19:29 -0400
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-02 14:42 -0400
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-02 14:40 -0400
Re: Halting problem proofs refuted on the basis of software engineering olcott <polcott2@gmail.com> - 2022-07-12 11:34 -0500
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-12 19:06 -0400
Re: Halting problem proofs refuted on the basis of software engineering Henrietta Stinkbottom <henri@galabbogosutionallity.net> - 2022-07-02 11:52 -0700
Re: Halting problem proofs refuted on the basis of software engineering wij <wyniijj2@gmail.com> - 2022-07-12 09:56 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-12 22:15 -0500
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-13 07:07 -0400
Re: Halting problem proofs refuted on the basis of software engineering Paul N <gw7rib@aol.com> - 2022-07-13 08:02 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-13 11:07 -0500
Re: Halting problem proofs refuted on the basis of software engineering Paul N <gw7rib@aol.com> - 2022-07-13 11:03 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-13 14:37 -0500
Re: Halting problem proofs refuted on the basis of software engineering wij <wyniijj2@gmail.com> - 2022-07-13 13:47 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-13 15:51 -0500
Re: Halting problem proofs refuted on the basis of software engineering wij <wyniijj2@gmail.com> - 2022-07-13 14:11 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-13 19:10 -0500
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-13 21:29 -0400
Re: Halting problem proofs refuted on the basis of software engineering wij <wyniijj2@gmail.com> - 2022-07-15 02:20 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-15 09:26 -0500
Re: Halting problem proofs refuted on the basis of software engineering wij <wyniijj2@gmail.com> - 2022-07-15 10:25 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-15 12:31 -0500
Re: Halting problem proofs refuted on the basis of software engineering wij <wyniijj2@gmail.com> - 2022-07-15 11:48 -0700
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-15 19:25 -0400
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-13 19:29 -0400
Re: Halting problem proofs refuted on the basis of software engineering Paul N <gw7rib@aol.com> - 2022-07-14 04:42 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-14 14:56 -0500
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-14 19:20 -0400
Re: Halting problem proofs refuted on the basis of software engineering Paul N <gw7rib@aol.com> - 2022-07-15 05:34 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-15 09:35 -0500
Re: Halting problem proofs refuted on the basis of software engineering Paul N <gw7rib@aol.com> - 2022-07-15 09:17 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-15 11:26 -0500
Re: Halting problem proofs refuted on the basis of software engineering Paul N <gw7rib@aol.com> - 2022-07-16 04:23 -0700
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-16 08:32 -0500
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-16 10:24 -0400
Re: Halting problem proofs refuted on the basis of software engineering Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-07-16 16:54 +0100
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-16 12:40 -0400
Re: Halting problem proofs refuted on the basis of software engineering Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-07-16 20:28 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Mike fails to comprehend) olcott <NoOne@NoWhere.com> - 2022-07-16 15:12 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Mike fails to comprehend) Richard Damon <Richard@Damon-Family.org> - 2022-07-16 18:05 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Mike fails to comprehend) Richard Damon <Richard@Damon-Family.org> - 2022-07-16 18:16 -0400
Re: Halting problem proofs refuted on the basis of software engineering [thanks Mike] olcott <NoOne@NoWhere.com> - 2022-07-17 12:00 -0500
Re: Halting problem proofs refuted on the basis of software engineering [thanks Mike] Richard Damon <Richard@Damon-Family.org> - 2022-07-17 13:06 -0400
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-16 12:43 -0500
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-16 13:56 -0400
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-16 19:18 -0500
Re: Halting problem proofs refuted on the basis of software engineering Richard Damon <Richard@Damon-Family.org> - 2022-07-16 20:38 -0400
Re: Halting problem proofs refuted on the basis of software engineering olcott <NoOne@NoWhere.com> - 2022-07-16 20:19 -0500
Re: Halting problem proofs refuted on the basis of software engineering [thanks Mike] olcott <polcott2@gmail.com> - 2022-07-16 21:40 -0500
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-03 10:48 -0500 |
| Message-ID | <kcKdnc6XHIvZJ1z_nZ2dnUU7_8xh4p2d@giganews.com> |
| In reply to | #53357 |
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.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-07-03 16:51 +0100 |
| Message-ID | <20220703165111.00006d29@reddwarf.jmc> |
| In reply to | #53359 |
On Sun, 3 Jul 2022 10:48:18 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/3/2022 10:45 AM, Mr Flibble wrote:
> > On Sun, 3 Jul 2022 10:30:45 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/3/2022 10:21 AM, Mr Flibble wrote:
> >>> On Sun, 3 Jul 2022 09:57:57 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 7/3/2022 9:27 AM, Mr Flibble wrote:
> >>>>> On Sat, 2 Jul 2022 17:13:01 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 7/2/2022 5:05 PM, Mr Flibble wrote:
> >>>>>>> On Sat, 2 Jul 2022 16:26:45 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 7/2/2022 1:44 PM, Mr Flibble wrote:
> >>>>>>>>> On Sat, 2 Jul 2022 13:41:14 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 7/2/2022 1:28 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Sat, 2 Jul 2022 12:30:03 -0500
> >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 7/2/2022 12:26 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Sat, 2 Jul 2022 12:15:58 -0500
> >>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 7/2/2022 12:10 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>> On Sat, 2 Jul 2022 11:42:48 -0500
> >>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 7/2/2022 11:26 AM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>> On Sat, 2 Jul 2022 10:34:34 -0500
> >>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> This much more concise version of my paper focuses
> >>>>>>>>>>>>>>>>>> on the actual execution of three fully operational
> >>>>>>>>>>>>>>>>>> examples.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> H0 correctly determines that Infinite_Loop() never
> >>>>>>>>>>>>>>>>>> halts H correctly determines that
> >>>>>>>>>>>>>>>>>> Infinite_Recursion() never halts H correctly
> >>>>>>>>>>>>>>>>>> determines that P() never halts
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P,
> >>>>>>>>>>>>>>>>>> (u32)P)); }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> As shown below the above P and H have the required
> >>>>>>>>>>>>>>>>>> (halting problem) pathological relationship to each
> >>>>>>>>>>>>>>>>>> other:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> For any program H that might
> >>>>>>>>>>>>>>>>>> determine if programs halt, a "pathological"
> >>>>>>>>>>>>>>>>>> program P, called with some input,
> >>>>>>>>>>>>>>>>>> can pass its own source and its input to
> >>>>>>>>>>>>>>>>>> H and then specifically do the
> >>>>>>>>>>>>>>>>>> opposite of what H predicts P will do. No H
> >>>>>>>>>>>>>>>>>> can exist that handles this case.
> >>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I really need software engineers to verify that H
> >>>>>>>>>>>>>>>>>> does correctly predict that its complete and
> >>>>>>>>>>>>>>>>>> correct x86 emulation of its input would never
> >>>>>>>>>>>>>>>>>> reach the "ret" instruction of this input.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> *Halting problem proofs refuted on the basis of
> >>>>>>>>>>>>>>>>>> software engineering*
> >>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> void Px(u32 x)
> >>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>> H(x, x);
> >>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px,
> >>>>>>>>>>>>>>>>> (u32)Px)); }
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408
> >>>>>>>>>>>>>>>>> add esp,+08 ...[000013eb][00102353][00000000] 50
> >>>>>>>>>>>>>>>>> push eax ...[000013ec][0010234f][00000427]
> >>>>>>>>>>>>>>>>> 6827040000 push 00000427
> >>>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call
> >>>>>>>>>>>>>>>>> 00000476 Input_Halts = 0
> >>>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408
> >>>>>>>>>>>>>>>>> add esp,+08 ...[000013f9][00102357][00000000] 33c0
> >>>>>>>>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d
> >>>>>>>>>>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3 ret
> >>>>>>>>>>>>>>>>> Number of Instructions Executed(16120)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> As can be seen above Olcott's H decides that Px does
> >>>>>>>>>>>>>>>>> not halt but it is obvious that Px should always
> >>>>>>>>>>>>>>>>> halt if H is a valid halt decider that always
> >>>>>>>>>>>>>>>>> returns a decision to its caller (Px). Olcott's H
> >>>>>>>>>>>>>>>>> does not return a decision to its caller (Px) and
> >>>>>>>>>>>>>>>>> is thus invalid.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Your false assumptions are directly contradicted by
> >>>>>>>>>>>>>>>> the semantics of the x86 programming language.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *x86 Instruction Set Reference* https://c9x.me/x86/
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> void Px(u32 x)
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> H(x, x);
> >>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px,
> >>>>>>>>>>>>>>>> (u32)Px)); }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> _Px()
> >>>>>>>>>>>>>>>> [00001192](01) 55 push ebp
> >>>>>>>>>>>>>>>> [00001193](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>> [00001195](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>> [00001198](01) 50 push eax
> >>>>>>>>>>>>>>>> [00001199](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>> [0000119c](01) 51 push ecx
> >>>>>>>>>>>>>>>> [0000119d](05) e8d0fdffff call 00000f72
> >>>>>>>>>>>>>>>> [000011a2](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>> [000011a5](01) 5d pop ebp
> >>>>>>>>>>>>>>>> [000011a6](01) c3 ret
> >>>>>>>>>>>>>>>> Size in bytes:(0021) [000011a6]
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> _main()
> >>>>>>>>>>>>>>>> [000011d2](01) 55 push ebp
> >>>>>>>>>>>>>>>> [000011d3](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>> [000011d5](05) 6892110000 push 00001192
> >>>>>>>>>>>>>>>> [000011da](05) 6892110000 push 00001192
> >>>>>>>>>>>>>>>> [000011df](05) e88efdffff call 00000f72
> >>>>>>>>>>>>>>>> [000011e4](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>> [000011e7](01) 50 push eax
> >>>>>>>>>>>>>>>> [000011e8](05) 68a3040000 push 000004a3
> >>>>>>>>>>>>>>>> [000011ed](05) e800f3ffff call 000004f2
> >>>>>>>>>>>>>>>> [000011f2](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>> [000011f5](02) 33c0 xor eax,eax
> >>>>>>>>>>>>>>>> [000011f7](01) 5d pop ebp
> >>>>>>>>>>>>>>>> [000011f8](01) c3 ret
> >>>>>>>>>>>>>>>> Size in bytes:(0039) [000011f8]
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> machine stack stack machine
> >>>>>>>>>>>>>>>> assembly address address data code
> >>>>>>>>>>>>>>>> language ======== ======== ======== =========
> >>>>>>>>>>>>>>>> ============= [000011d2][00101f7f][00000000] 55
> >>>>>>>>>>>>>>>> push ebp [000011d3][00101f7f][00000000] 8bec
> >>>>>>>>>>>>>>>> mov ebp,esp [000011d5][00101f7b][00001192]
> >>>>>>>>>>>>>>>> 6892110000 push 00001192
> >>>>>>>>>>>>>>>> [000011da][00101f77][00001192] 6892110000 push
> >>>>>>>>>>>>>>>> 00001192 [000011df][00101f73][000011e4] e88efdffff
> >>>>>>>>>>>>>>>> call 00000f72
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> H: Begin Simulation Execution Trace Stored
> >>>>>>>>>>>>>>>> at:11202b Address_of_H:f72
> >>>>>>>>>>>>>>>> [00001192][00112017][0011201b] 55 push ebp
> >>>>>>>>>>>>>>>> [00001193][00112017][0011201b] 8bec mov ebp,esp
> >>>>>>>>>>>>>>>> [00001195][00112017][0011201b] 8b4508 mov
> >>>>>>>>>>>>>>>> eax,[ebp+08] [00001198][00112013][00001192] 50
> >>>>>>>>>>>>>>>> push eax // push Px
> >>>>>>>>>>>>>>>> [00001199][00112013][00001192] 8b4d08 mov
> >>>>>>>>>>>>>>>> ecx,[ebp+08] [0000119c][0011200f][00001192] 51
> >>>>>>>>>>>>>>>> push ecx // push Px [0000119d][0011200b][000011a2]
> >>>>>>>>>>>>>>>> e8d0fdffff call 00000f72 // call H(Px,Px) H:
> >>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation
> >>>>>>>>>>>>>>>> Stopped
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> H knows its own machine address and on this basis it
> >>>>>>>>>>>>>>>> can easily examine its stored execution_trace of Px
> >>>>>>>>>>>>>>>> (see above) to determine: (a) Px is calling H with
> >>>>>>>>>>>>>>>> the same arguments that H was called with. (b) No
> >>>>>>>>>>>>>>>> instructions in Px could possibly escape this
> >>>>>>>>>>>>>>>> otherwise infinitely recursive emulation. (c) H
> >>>>>>>>>>>>>>>> aborts its emulation of Px before its call to H is
> >>>>>>>>>>>>>>>> emulated.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> [000011e4][00101f7f][00000000] 83c408 add esp,+08
> >>>>>>>>>>>>>>>> [000011e7][00101f7b][00000000] 50 push eax
> >>>>>>>>>>>>>>>> [000011e8][00101f77][000004a3] 68a3040000 push
> >>>>>>>>>>>>>>>> 000004a3 [000011ed][00101f77][000004a3] e800f3ffff
> >>>>>>>>>>>>>>>> call 000004f2 Input_Halts = 0
> >>>>>>>>>>>>>>>> [000011f2][00101f7f][00000000] 83c408 add esp,+08
> >>>>>>>>>>>>>>>> [000011f5][00101f7f][00000000] 33c0 xor eax,eax
> >>>>>>>>>>>>>>>> [000011f7][00101f83][00000018] 5d pop ebp
> >>>>>>>>>>>>>>>> [000011f8][00101f87][00000000] c3 ret
> >>>>>>>>>>>>>>>> Number of Instructions Executed(880) == 13 Pages
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If H wasn't a simulation-based halting decider then
> >>>>>>>>>>>>>>> Px() would always halt; the infinite recursion is a
> >>>>>>>>>>>>>>> manifestation of your invalid simulation-based halting
> >>>>>>>>>>>>>>> decider. There is no recursion in [Strachey 1965].
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> In other words you are rejecting the concept of a
> >>>>>>>>>>>>>> simulating halt decider even though I conclusively
> >>>>>>>>>>>>>> proved that it does correctly determine the halt
> >>>>>>>>>>>>>> status of: (see my new paper)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> No I am rejecting your simulating halt decider as it
> >>>>>>>>>>>>> gets the answer wrong for Px() which is not a
> >>>>>>>>>>>>> pathological input. Px() halts.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I just proved that H(Px,Px) does correctly predict that
> >>>>>>>>>>>> its complete and correct x86 emulation of its input
> >>>>>>>>>>>> would never reach the "ret" instruction of this input
> >>>>>>>>>>>> because of the pathological relationship between H and
> >>>>>>>>>>>> Px.
> >>>>>>>>>>>
> >>>>>>>>>>> Wrong. Px() is not a pathological input as defined by the
> >>>>>>>>>>> halting problem and [Strachey 1965] as it does not try to
> >>>>>>>>>>> do the opposite of what H decides.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Your lack of comprehension does not actually count as any
> >>>>>>>>>> rebuttal at all.
> >>>>>>>>>>
> >>>>>>>>>> void P(u32 x)
> >>>>>>>>>> {
> >>>>>>>>>> if (H(x, x))
> >>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>> return;
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> int main()
> >>>>>>>>>> {
> >>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> As shown below the above P and H have the required (halting
> >>>>>>>>>> problem) pathological relationship to each other:
> >>>>>>>>> [snip]
> >>>>>>>>>
> >>>>>>>>> P does but Px does not. I am talking about Px not P.
> >>>>>>>>>
> >>>>>>>>> void Px(u32 x)
> >>>>>>>>> {
> >>>>>>>>> H(x, x);
> >>>>>>>>> return;
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> int main()
> >>>>>>>>> {
> >>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add
> >>>>>>>>> esp,+08 ...[000013eb][00102353][00000000] 50
> >>>>>>>>> push eax ...[000013ec][0010234f][00000427] 6827040000
> >>>>>>>>> push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff
> >>>>>>>>> call 00000476 Input_Halts = 0
> >>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add
> >>>>>>>>> esp,+08 ...[000013f9][00102357][00000000] 33c0
> >>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d
> >>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3
> >>>>>>>>> ret Number of Instructions Executed(16120)
> >>>>>>>>>
> >>>>>>>>> As can be seen above Olcott's H decides that Px does not
> >>>>>>>>> halt but it is obvious that Px should always halt if H is a
> >>>>>>>>> valid halt decider that always returns a decision to its
> >>>>>>>>> caller (Px). Olcott's H does not return a decision to its
> >>>>>>>>> caller (Px) and is thus invalid.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> >
> >>>>>>>>
> >>>>>>>> Your false assumptions are directly contradicted by the
> >>>>>>>> semantics of the x86 programming language.
> >>>>>>>>
> >>>>>>>> *x86 Instruction Set Reference* https://c9x.me/x86/
> >>>>>>>>
> >>>>>>>> void Px(u32 x)
> >>>>>>>> {
> >>>>>>>> H(x, x);
> >>>>>>>> return;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> int main()
> >>>>>>>> {
> >>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> _Px()
> >>>>>>>> [00001192](01) 55 push ebp
> >>>>>>>> [00001193](02) 8bec mov ebp,esp
> >>>>>>>> [00001195](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>> [00001198](01) 50 push eax
> >>>>>>>> [00001199](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>> [0000119c](01) 51 push ecx
> >>>>>>>> [0000119d](05) e8d0fdffff call 00000f72
> >>>>>>>> [000011a2](03) 83c408 add esp,+08
> >>>>>>>> [000011a5](01) 5d pop ebp
> >>>>>>>> [000011a6](01) c3 ret
> >>>>>>>> Size in bytes:(0021) [000011a6]
> >>>>>>>>
> >>>>>>>> _main()
> >>>>>>>> [000011d2](01) 55 push ebp
> >>>>>>>> [000011d3](02) 8bec mov ebp,esp
> >>>>>>>> [000011d5](05) 6892110000 push 00001192
> >>>>>>>> [000011da](05) 6892110000 push 00001192
> >>>>>>>> [000011df](05) e88efdffff call 00000f72
> >>>>>>>> [000011e4](03) 83c408 add esp,+08
> >>>>>>>> [000011e7](01) 50 push eax
> >>>>>>>> [000011e8](05) 68a3040000 push 000004a3
> >>>>>>>> [000011ed](05) e800f3ffff call 000004f2
> >>>>>>>> [000011f2](03) 83c408 add esp,+08
> >>>>>>>> [000011f5](02) 33c0 xor eax,eax
> >>>>>>>> [000011f7](01) 5d pop ebp
> >>>>>>>> [000011f8](01) c3 ret
> >>>>>>>> Size in bytes:(0039) [000011f8]
> >>>>>>>>
> >>>>>>>> machine stack stack machine assembly
> >>>>>>>> address address data code language
> >>>>>>>> ======== ======== ======== ========= =============
> >>>>>>>> [000011d2][00101f7f][00000000] 55 push ebp
> >>>>>>>> [000011d3][00101f7f][00000000] 8bec mov ebp,esp
> >>>>>>>> [000011d5][00101f7b][00001192] 6892110000 push 00001192
> >>>>>>>> [000011da][00101f77][00001192] 6892110000 push 00001192
> >>>>>>>> [000011df][00101f73][000011e4] e88efdffff call 00000f72
> >>>>>>>>
> >>>>>>>> H: Begin Simulation Execution Trace Stored at:11202b
> >>>>>>>> Address_of_H:f72
> >>>>>>>> [00001192][00112017][0011201b] 55 push ebp
> >>>>>>>> [00001193][00112017][0011201b] 8bec mov ebp,esp
> >>>>>>>> [00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
> >>>>>>>> [00001198][00112013][00001192] 50 push eax //
> >>>>>>>> push Px [00001199][00112013][00001192] 8b4d08 mov
> >>>>>>>> ecx,[ebp+08] [0000119c][0011200f][00001192] 51 push
> >>>>>>>> ecx // push Px [0000119d][0011200b][000011a2]
> >>>>>>>> e8d0fdffff call 00000f72 // call H(Px,Px) H: Infinitely
> >>>>>>>> Recursive Simulation Detected Simulation Stopped
> >>>>>>>>
> >>>>>>>> H knows its own machine address and on this basis it can
> >>>>>>>> easily examine its stored execution_trace of Px (see above)
> >>>>>>>> to determine: (a) Px is calling H with the same arguments
> >>>>>>>> that H was called with. (b) No instructions in Px could
> >>>>>>>> possibly escape this otherwise infinitely recursive
> >>>>>>>> emulation. (c) H aborts its emulation of Px before its call
> >>>>>>>> to H is emulated.
> >>>>>>>>
> >>>>>>>> [000011e4][00101f7f][00000000] 83c408 add esp,+08
> >>>>>>>> [000011e7][00101f7b][00000000] 50 push eax
> >>>>>>>> [000011e8][00101f77][000004a3] 68a3040000 push 000004a3
> >>>>>>>> [000011ed][00101f77][000004a3] e800f3ffff call 000004f2
> >>>>>>>> Input_Halts = 0
> >>>>>>>> [000011f2][00101f7f][00000000] 83c408 add esp,+08
> >>>>>>>> [000011f5][00101f7f][00000000] 33c0 xor eax,eax
> >>>>>>>> [000011f7][00101f83][00000018] 5d pop ebp
> >>>>>>>> [000011f8][00101f87][00000000] c3 ret
> >>>>>>>> Number of Instructions Executed(880) == 13 Pages
> >>>>>>>
> >>>>>>> I see you wish to pointlessly go around in circles. Oh well.
> >>>>>>>
> >>>>>>> Px() is not a pathological input as defined by the halting
> >>>>>>> problem and [Strachey 1965] as it does not try to do the
> >>>>>>> opposite of what H decides.
> >>>>>>>
> >>>>>>> Px() always halts so your H gets the answer wrong.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>
> >>>>>> I found that my reply did not make it to all the groups so I
> >>>>>> posted it again.
> >>>>>>
> >>>>>> *This general principle refutes conventional halting problem
> >>>>>> proofs* Every simulating halt decider that correctly simulates
> >>>>>> its input until it correctly predicts that this simulated input
> >>>>>> would never reach its final state, correctly rejects this input
> >>>>>> as non-halting.
> >>>>>
> >>>>> Your H does not "correctly predict" that Px() does reach its
> >>>>> final state and so should accept the input as halting.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> (x86 Instruction Set Reference* https://c9x.me/x86/
> >>>>
> >>>> The semantics of the x86 language conclusively proves that the
> >>>> above code is correct. People that disagree with verified facts
> >>>> are either incompetent or liars. Since you cannot even understand
> >>>> that the return statement in Px is unreachable code, (to every
> >>>> simulating halt decider H) you would be incompetent.
> >>>
> >>> Not EVERY simulating halt decider, only YOURS gets the answer
> >>> wrong. Px() halts.
> >>>
> >>> /Flibble
> >>>
> >>
> >> Since you cannot even understand that the return statement in Px is
> >> unreachable code, (to *every simulating halt* decider H) you would
> >> be incompetent.
> >
> > Not at all. If I was to design a simulating halt decider then rather
> > than aborting the simulation at the point where P()/Px() calls H I
> > would instead fork the simulation, returning 0 to one branch (the
> > non-halting branch) and 1 to the other branch (the halting branch)
> > and then continue to simulate both branches in parallel thereby
> > getting rid of the "infinite recursion".
> >
> > /Flibble
> >
>
> Yet that is *not* what the actual code specifies. Every function
> called in infinite recursion is not allowed to return to its caller.
The infinite recursion is an artifact of how YOU are trying to solve
the problem; there is no infinite recursion in [Strachey 1965] and
associated proofs.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-03 11:05 -0500 |
| Message-ID | <4rydnbiMgrTeI1z_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #53360 |
On 7/3/2022 10:51 AM, Mr Flibble wrote:
> On Sun, 3 Jul 2022 10:48:18 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/3/2022 10:45 AM, Mr Flibble wrote:
>>> On Sun, 3 Jul 2022 10:30:45 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/3/2022 10:21 AM, Mr Flibble wrote:
>>>>> On Sun, 3 Jul 2022 09:57:57 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 7/3/2022 9:27 AM, Mr Flibble wrote:
>>>>>>> On Sat, 2 Jul 2022 17:13:01 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 7/2/2022 5:05 PM, Mr Flibble wrote:
>>>>>>>>> On Sat, 2 Jul 2022 16:26:45 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 7/2/2022 1:44 PM, Mr Flibble wrote:
>>>>>>>>>>> On Sat, 2 Jul 2022 13:41:14 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 7/2/2022 1:28 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sat, 2 Jul 2022 12:30:03 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7/2/2022 12:26 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Sat, 2 Jul 2022 12:15:58 -0500
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 7/2/2022 12:10 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Sat, 2 Jul 2022 11:42:48 -0500
>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 7/2/2022 11:26 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Sat, 2 Jul 2022 10:34:34 -0500
>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This much more concise version of my paper focuses
>>>>>>>>>>>>>>>>>>>> on the actual execution of three fully operational
>>>>>>>>>>>>>>>>>>>> examples.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H0 correctly determines that Infinite_Loop() never
>>>>>>>>>>>>>>>>>>>> halts H correctly determines that
>>>>>>>>>>>>>>>>>>>> Infinite_Recursion() never halts H correctly
>>>>>>>>>>>>>>>>>>>> determines that P() never halts
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P,
>>>>>>>>>>>>>>>>>>>> (u32)P)); }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> As shown below the above P and H have the required
>>>>>>>>>>>>>>>>>>>> (halting problem) pathological relationship to each
>>>>>>>>>>>>>>>>>>>> other:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> For any program H that might
>>>>>>>>>>>>>>>>>>>> determine if programs halt, a "pathological"
>>>>>>>>>>>>>>>>>>>> program P, called with some input,
>>>>>>>>>>>>>>>>>>>> can pass its own source and its input to
>>>>>>>>>>>>>>>>>>>> H and then specifically do the
>>>>>>>>>>>>>>>>>>>> opposite of what H predicts P will do. No H
>>>>>>>>>>>>>>>>>>>> can exist that handles this case.
>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I really need software engineers to verify that H
>>>>>>>>>>>>>>>>>>>> does correctly predict that its complete and
>>>>>>>>>>>>>>>>>>>> correct x86 emulation of its input would never
>>>>>>>>>>>>>>>>>>>> reach the "ret" instruction of this input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *Halting problem proofs refuted on the basis of
>>>>>>>>>>>>>>>>>>>> software engineering*
>>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px,
>>>>>>>>>>>>>>>>>>> (u32)Px)); }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408
>>>>>>>>>>>>>>>>>>> add esp,+08 ...[000013eb][00102353][00000000] 50
>>>>>>>>>>>>>>>>>>> push eax ...[000013ec][0010234f][00000427]
>>>>>>>>>>>>>>>>>>> 6827040000 push 00000427
>>>>>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call
>>>>>>>>>>>>>>>>>>> 00000476 Input_Halts = 0
>>>>>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408
>>>>>>>>>>>>>>>>>>> add esp,+08 ...[000013f9][00102357][00000000] 33c0
>>>>>>>>>>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d
>>>>>>>>>>>>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3 ret
>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As can be seen above Olcott's H decides that Px does
>>>>>>>>>>>>>>>>>>> not halt but it is obvious that Px should always
>>>>>>>>>>>>>>>>>>> halt if H is a valid halt decider that always
>>>>>>>>>>>>>>>>>>> returns a decision to its caller (Px). Olcott's H
>>>>>>>>>>>>>>>>>>> does not return a decision to its caller (Px) and
>>>>>>>>>>>>>>>>>>> is thus invalid.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Your false assumptions are directly contradicted by
>>>>>>>>>>>>>>>>>> the semantics of the x86 programming language.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *x86 Instruction Set Reference* https://c9x.me/x86/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px,
>>>>>>>>>>>>>>>>>> (u32)Px)); }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _Px()
>>>>>>>>>>>>>>>>>> [00001192](01) 55 push ebp
>>>>>>>>>>>>>>>>>> [00001193](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>> [00001195](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>> [00001198](01) 50 push eax
>>>>>>>>>>>>>>>>>> [00001199](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>> [0000119c](01) 51 push ecx
>>>>>>>>>>>>>>>>>> [0000119d](05) e8d0fdffff call 00000f72
>>>>>>>>>>>>>>>>>> [000011a2](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>> [000011a5](01) 5d pop ebp
>>>>>>>>>>>>>>>>>> [000011a6](01) c3 ret
>>>>>>>>>>>>>>>>>> Size in bytes:(0021) [000011a6]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _main()
>>>>>>>>>>>>>>>>>> [000011d2](01) 55 push ebp
>>>>>>>>>>>>>>>>>> [000011d3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>> [000011d5](05) 6892110000 push 00001192
>>>>>>>>>>>>>>>>>> [000011da](05) 6892110000 push 00001192
>>>>>>>>>>>>>>>>>> [000011df](05) e88efdffff call 00000f72
>>>>>>>>>>>>>>>>>> [000011e4](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>> [000011e7](01) 50 push eax
>>>>>>>>>>>>>>>>>> [000011e8](05) 68a3040000 push 000004a3
>>>>>>>>>>>>>>>>>> [000011ed](05) e800f3ffff call 000004f2
>>>>>>>>>>>>>>>>>> [000011f2](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>> [000011f5](02) 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>> [000011f7](01) 5d pop ebp
>>>>>>>>>>>>>>>>>> [000011f8](01) c3 ret
>>>>>>>>>>>>>>>>>> Size in bytes:(0039) [000011f8]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> machine stack stack machine
>>>>>>>>>>>>>>>>>> assembly address address data code
>>>>>>>>>>>>>>>>>> language ======== ======== ======== =========
>>>>>>>>>>>>>>>>>> ============= [000011d2][00101f7f][00000000] 55
>>>>>>>>>>>>>>>>>> push ebp [000011d3][00101f7f][00000000] 8bec
>>>>>>>>>>>>>>>>>> mov ebp,esp [000011d5][00101f7b][00001192]
>>>>>>>>>>>>>>>>>> 6892110000 push 00001192
>>>>>>>>>>>>>>>>>> [000011da][00101f77][00001192] 6892110000 push
>>>>>>>>>>>>>>>>>> 00001192 [000011df][00101f73][000011e4] e88efdffff
>>>>>>>>>>>>>>>>>> call 00000f72
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H: Begin Simulation Execution Trace Stored
>>>>>>>>>>>>>>>>>> at:11202b Address_of_H:f72
>>>>>>>>>>>>>>>>>> [00001192][00112017][0011201b] 55 push ebp
>>>>>>>>>>>>>>>>>> [00001193][00112017][0011201b] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>> [00001195][00112017][0011201b] 8b4508 mov
>>>>>>>>>>>>>>>>>> eax,[ebp+08] [00001198][00112013][00001192] 50
>>>>>>>>>>>>>>>>>> push eax // push Px
>>>>>>>>>>>>>>>>>> [00001199][00112013][00001192] 8b4d08 mov
>>>>>>>>>>>>>>>>>> ecx,[ebp+08] [0000119c][0011200f][00001192] 51
>>>>>>>>>>>>>>>>>> push ecx // push Px [0000119d][0011200b][000011a2]
>>>>>>>>>>>>>>>>>> e8d0fdffff call 00000f72 // call H(Px,Px) H:
>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation
>>>>>>>>>>>>>>>>>> Stopped
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it
>>>>>>>>>>>>>>>>>> can easily examine its stored execution_trace of Px
>>>>>>>>>>>>>>>>>> (see above) to determine: (a) Px is calling H with
>>>>>>>>>>>>>>>>>> the same arguments that H was called with. (b) No
>>>>>>>>>>>>>>>>>> instructions in Px could possibly escape this
>>>>>>>>>>>>>>>>>> otherwise infinitely recursive emulation. (c) H
>>>>>>>>>>>>>>>>>> aborts its emulation of Px before its call to H is
>>>>>>>>>>>>>>>>>> emulated.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> [000011e4][00101f7f][00000000] 83c408 add esp,+08
>>>>>>>>>>>>>>>>>> [000011e7][00101f7b][00000000] 50 push eax
>>>>>>>>>>>>>>>>>> [000011e8][00101f77][000004a3] 68a3040000 push
>>>>>>>>>>>>>>>>>> 000004a3 [000011ed][00101f77][000004a3] e800f3ffff
>>>>>>>>>>>>>>>>>> call 000004f2 Input_Halts = 0
>>>>>>>>>>>>>>>>>> [000011f2][00101f7f][00000000] 83c408 add esp,+08
>>>>>>>>>>>>>>>>>> [000011f5][00101f7f][00000000] 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>> [000011f7][00101f83][00000018] 5d pop ebp
>>>>>>>>>>>>>>>>>> [000011f8][00101f87][00000000] c3 ret
>>>>>>>>>>>>>>>>>> Number of Instructions Executed(880) == 13 Pages
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If H wasn't a simulation-based halting decider then
>>>>>>>>>>>>>>>>> Px() would always halt; the infinite recursion is a
>>>>>>>>>>>>>>>>> manifestation of your invalid simulation-based halting
>>>>>>>>>>>>>>>>> decider. There is no recursion in [Strachey 1965].
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In other words you are rejecting the concept of a
>>>>>>>>>>>>>>>> simulating halt decider even though I conclusively
>>>>>>>>>>>>>>>> proved that it does correctly determine the halt
>>>>>>>>>>>>>>>> status of: (see my new paper)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No I am rejecting your simulating halt decider as it
>>>>>>>>>>>>>>> gets the answer wrong for Px() which is not a
>>>>>>>>>>>>>>> pathological input. Px() halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I just proved that H(Px,Px) does correctly predict that
>>>>>>>>>>>>>> its complete and correct x86 emulation of its input
>>>>>>>>>>>>>> would never reach the "ret" instruction of this input
>>>>>>>>>>>>>> because of the pathological relationship between H and
>>>>>>>>>>>>>> Px.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Wrong. Px() is not a pathological input as defined by the
>>>>>>>>>>>>> halting problem and [Strachey 1965] as it does not try to
>>>>>>>>>>>>> do the opposite of what H decides.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Your lack of comprehension does not actually count as any
>>>>>>>>>>>> rebuttal at all.
>>>>>>>>>>>>
>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>> {
>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> As shown below the above P and H have the required (halting
>>>>>>>>>>>> problem) pathological relationship to each other:
>>>>>>>>>>> [snip]
>>>>>>>>>>>
>>>>>>>>>>> P does but Px does not. I am talking about Px not P.
>>>>>>>>>>>
>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>> {
>>>>>>>>>>> H(x, x);
>>>>>>>>>>> return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add
>>>>>>>>>>> esp,+08 ...[000013eb][00102353][00000000] 50
>>>>>>>>>>> push eax ...[000013ec][0010234f][00000427] 6827040000
>>>>>>>>>>> push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff
>>>>>>>>>>> call 00000476 Input_Halts = 0
>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add
>>>>>>>>>>> esp,+08 ...[000013f9][00102357][00000000] 33c0
>>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d
>>>>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3
>>>>>>>>>>> ret Number of Instructions Executed(16120)
>>>>>>>>>>>
>>>>>>>>>>> As can be seen above Olcott's H decides that Px does not
>>>>>>>>>>> halt but it is obvious that Px should always halt if H is a
>>>>>>>>>>> valid halt decider that always returns a decision to its
>>>>>>>>>>> caller (Px). Olcott's H does not return a decision to its
>>>>>>>>>>> caller (Px) and is thus invalid.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>> Your false assumptions are directly contradicted by the
>>>>>>>>>> semantics of the x86 programming language.
>>>>>>>>>>
>>>>>>>>>> *x86 Instruction Set Reference* https://c9x.me/x86/
>>>>>>>>>>
>>>>>>>>>> void Px(u32 x)
>>>>>>>>>> {
>>>>>>>>>> H(x, x);
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> _Px()
>>>>>>>>>> [00001192](01) 55 push ebp
>>>>>>>>>> [00001193](02) 8bec mov ebp,esp
>>>>>>>>>> [00001195](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>> [00001198](01) 50 push eax
>>>>>>>>>> [00001199](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>> [0000119c](01) 51 push ecx
>>>>>>>>>> [0000119d](05) e8d0fdffff call 00000f72
>>>>>>>>>> [000011a2](03) 83c408 add esp,+08
>>>>>>>>>> [000011a5](01) 5d pop ebp
>>>>>>>>>> [000011a6](01) c3 ret
>>>>>>>>>> Size in bytes:(0021) [000011a6]
>>>>>>>>>>
>>>>>>>>>> _main()
>>>>>>>>>> [000011d2](01) 55 push ebp
>>>>>>>>>> [000011d3](02) 8bec mov ebp,esp
>>>>>>>>>> [000011d5](05) 6892110000 push 00001192
>>>>>>>>>> [000011da](05) 6892110000 push 00001192
>>>>>>>>>> [000011df](05) e88efdffff call 00000f72
>>>>>>>>>> [000011e4](03) 83c408 add esp,+08
>>>>>>>>>> [000011e7](01) 50 push eax
>>>>>>>>>> [000011e8](05) 68a3040000 push 000004a3
>>>>>>>>>> [000011ed](05) e800f3ffff call 000004f2
>>>>>>>>>> [000011f2](03) 83c408 add esp,+08
>>>>>>>>>> [000011f5](02) 33c0 xor eax,eax
>>>>>>>>>> [000011f7](01) 5d pop ebp
>>>>>>>>>> [000011f8](01) c3 ret
>>>>>>>>>> Size in bytes:(0039) [000011f8]
>>>>>>>>>>
>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>> address address data code language
>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>> [000011d2][00101f7f][00000000] 55 push ebp
>>>>>>>>>> [000011d3][00101f7f][00000000] 8bec mov ebp,esp
>>>>>>>>>> [000011d5][00101f7b][00001192] 6892110000 push 00001192
>>>>>>>>>> [000011da][00101f77][00001192] 6892110000 push 00001192
>>>>>>>>>> [000011df][00101f73][000011e4] e88efdffff call 00000f72
>>>>>>>>>>
>>>>>>>>>> H: Begin Simulation Execution Trace Stored at:11202b
>>>>>>>>>> Address_of_H:f72
>>>>>>>>>> [00001192][00112017][0011201b] 55 push ebp
>>>>>>>>>> [00001193][00112017][0011201b] 8bec mov ebp,esp
>>>>>>>>>> [00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
>>>>>>>>>> [00001198][00112013][00001192] 50 push eax //
>>>>>>>>>> push Px [00001199][00112013][00001192] 8b4d08 mov
>>>>>>>>>> ecx,[ebp+08] [0000119c][0011200f][00001192] 51 push
>>>>>>>>>> ecx // push Px [0000119d][0011200b][000011a2]
>>>>>>>>>> e8d0fdffff call 00000f72 // call H(Px,Px) H: Infinitely
>>>>>>>>>> Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>
>>>>>>>>>> H knows its own machine address and on this basis it can
>>>>>>>>>> easily examine its stored execution_trace of Px (see above)
>>>>>>>>>> to determine: (a) Px is calling H with the same arguments
>>>>>>>>>> that H was called with. (b) No instructions in Px could
>>>>>>>>>> possibly escape this otherwise infinitely recursive
>>>>>>>>>> emulation. (c) H aborts its emulation of Px before its call
>>>>>>>>>> to H is emulated.
>>>>>>>>>>
>>>>>>>>>> [000011e4][00101f7f][00000000] 83c408 add esp,+08
>>>>>>>>>> [000011e7][00101f7b][00000000] 50 push eax
>>>>>>>>>> [000011e8][00101f77][000004a3] 68a3040000 push 000004a3
>>>>>>>>>> [000011ed][00101f77][000004a3] e800f3ffff call 000004f2
>>>>>>>>>> Input_Halts = 0
>>>>>>>>>> [000011f2][00101f7f][00000000] 83c408 add esp,+08
>>>>>>>>>> [000011f5][00101f7f][00000000] 33c0 xor eax,eax
>>>>>>>>>> [000011f7][00101f83][00000018] 5d pop ebp
>>>>>>>>>> [000011f8][00101f87][00000000] c3 ret
>>>>>>>>>> Number of Instructions Executed(880) == 13 Pages
>>>>>>>>>
>>>>>>>>> I see you wish to pointlessly go around in circles. Oh well.
>>>>>>>>>
>>>>>>>>> Px() is not a pathological input as defined by the halting
>>>>>>>>> problem and [Strachey 1965] as it does not try to do the
>>>>>>>>> opposite of what H decides.
>>>>>>>>>
>>>>>>>>> Px() always halts so your H gets the answer wrong.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> I found that my reply did not make it to all the groups so I
>>>>>>>> posted it again.
>>>>>>>>
>>>>>>>> *This general principle refutes conventional halting problem
>>>>>>>> proofs* Every simulating halt decider that correctly simulates
>>>>>>>> its input until it correctly predicts that this simulated input
>>>>>>>> would never reach its final state, correctly rejects this input
>>>>>>>> as non-halting.
>>>>>>>
>>>>>>> Your H does not "correctly predict" that Px() does reach its
>>>>>>> final state and so should accept the input as halting.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> (x86 Instruction Set Reference* https://c9x.me/x86/
>>>>>>
>>>>>> The semantics of the x86 language conclusively proves that the
>>>>>> above code is correct. People that disagree with verified facts
>>>>>> are either incompetent or liars. Since you cannot even understand
>>>>>> that the return statement in Px is unreachable code, (to every
>>>>>> simulating halt decider H) you would be incompetent.
>>>>>
>>>>> Not EVERY simulating halt decider, only YOURS gets the answer
>>>>> wrong. Px() halts.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> Since you cannot even understand that the return statement in Px is
>>>> unreachable code, (to *every simulating halt* decider H) you would
>>>> be incompetent.
>>>
>>> Not at all. If I was to design a simulating halt decider then rather
>>> than aborting the simulation at the point where P()/Px() calls H I
>>> would instead fork the simulation, returning 0 to one branch (the
>>> non-halting branch) and 1 to the other branch (the halting branch)
>>> and then continue to simulate both branches in parallel thereby
>>> getting rid of the "infinite recursion".
>>>
>>> /Flibble
>>>
>>
>> Yet that is *not* what the actual code specifies. Every function
>> called in infinite recursion is not allowed to return to its caller.
>
> The infinite recursion is an artifact of how YOU are trying to solve
> the problem; there is no infinite recursion in [Strachey 1965] and
> associated proofs.
>
> /Flibble
>
The halting problem expressly allows every algorithm in the universe as
long as it correctly predicts the behavior of the input.
*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.
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-07-03 17:07 +0100 |
| Message-ID | <20220703170707.00006ec9@reddwarf.jmc> |
| In reply to | #53362 |
On Sun, 3 Jul 2022 11:05:21 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/3/2022 10:51 AM, Mr Flibble wrote:
> > On Sun, 3 Jul 2022 10:48:18 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/3/2022 10:45 AM, Mr Flibble wrote:
> >>> On Sun, 3 Jul 2022 10:30:45 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 7/3/2022 10:21 AM, Mr Flibble wrote:
> >>>>> On Sun, 3 Jul 2022 09:57:57 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 7/3/2022 9:27 AM, Mr Flibble wrote:
> >>>>>>> On Sat, 2 Jul 2022 17:13:01 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 7/2/2022 5:05 PM, Mr Flibble wrote:
> >>>>>>>>> On Sat, 2 Jul 2022 16:26:45 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 7/2/2022 1:44 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Sat, 2 Jul 2022 13:41:14 -0500
> >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 7/2/2022 1:28 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Sat, 2 Jul 2022 12:30:03 -0500
> >>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 7/2/2022 12:26 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>> On Sat, 2 Jul 2022 12:15:58 -0500
> >>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 7/2/2022 12:10 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>> On Sat, 2 Jul 2022 11:42:48 -0500
> >>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 7/2/2022 11:26 AM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>> On Sat, 2 Jul 2022 10:34:34 -0500
> >>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> This much more concise version of my paper
> >>>>>>>>>>>>>>>>>>>> focuses on the actual execution of three fully
> >>>>>>>>>>>>>>>>>>>> operational examples.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> H0 correctly determines that Infinite_Loop()
> >>>>>>>>>>>>>>>>>>>> never halts H correctly determines that
> >>>>>>>>>>>>>>>>>>>> Infinite_Recursion() never halts H correctly
> >>>>>>>>>>>>>>>>>>>> determines that P() never halts
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P,
> >>>>>>>>>>>>>>>>>>>> (u32)P)); }
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> As shown below the above P and H have the
> >>>>>>>>>>>>>>>>>>>> required (halting problem) pathological
> >>>>>>>>>>>>>>>>>>>> relationship to each other:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> For any program H that might
> >>>>>>>>>>>>>>>>>>>> determine if programs halt, a "pathological"
> >>>>>>>>>>>>>>>>>>>> program P, called with some
> >>>>>>>>>>>>>>>>>>>> input, can pass its own source and its input to
> >>>>>>>>>>>>>>>>>>>> H and then specifically do the
> >>>>>>>>>>>>>>>>>>>> opposite of what H predicts P will do. No H
> >>>>>>>>>>>>>>>>>>>> can exist that handles this case.
> >>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I really need software engineers to verify that H
> >>>>>>>>>>>>>>>>>>>> does correctly predict that its complete and
> >>>>>>>>>>>>>>>>>>>> correct x86 emulation of its input would never
> >>>>>>>>>>>>>>>>>>>> reach the "ret" instruction of this input.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> *Halting problem proofs refuted on the basis of
> >>>>>>>>>>>>>>>>>>>> software engineering*
> >>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> void Px(u32 x)
> >>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>> H(x, x);
> >>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px,
> >>>>>>>>>>>>>>>>>>> (u32)Px)); }
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408
> >>>>>>>>>>>>>>>>>>> add esp,+08 ...[000013eb][00102353][00000000] 50
> >>>>>>>>>>>>>>>>>>> push eax ...[000013ec][0010234f][00000427]
> >>>>>>>>>>>>>>>>>>> 6827040000 push 00000427
> >>>>>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call
> >>>>>>>>>>>>>>>>>>> 00000476 Input_Halts = 0
> >>>>>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408
> >>>>>>>>>>>>>>>>>>> add esp,+08 ...[000013f9][00102357][00000000] 33c0
> >>>>>>>>>>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d
> >>>>>>>>>>>>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3 ret
> >>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120)
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> As can be seen above Olcott's H decides that Px
> >>>>>>>>>>>>>>>>>>> does not halt but it is obvious that Px should
> >>>>>>>>>>>>>>>>>>> always halt if H is a valid halt decider that
> >>>>>>>>>>>>>>>>>>> always returns a decision to its caller (Px).
> >>>>>>>>>>>>>>>>>>> Olcott's H does not return a decision to its
> >>>>>>>>>>>>>>>>>>> caller (Px) and is thus invalid.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Your false assumptions are directly contradicted by
> >>>>>>>>>>>>>>>>>> the semantics of the x86 programming language.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> *x86 Instruction Set Reference*
> >>>>>>>>>>>>>>>>>> https://c9x.me/x86/
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> void Px(u32 x)
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> H(x, x);
> >>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px,
> >>>>>>>>>>>>>>>>>> (u32)Px)); }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> _Px()
> >>>>>>>>>>>>>>>>>> [00001192](01) 55 push ebp
> >>>>>>>>>>>>>>>>>> [00001193](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>> [00001195](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>> [00001198](01) 50 push eax
> >>>>>>>>>>>>>>>>>> [00001199](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>> [0000119c](01) 51 push ecx
> >>>>>>>>>>>>>>>>>> [0000119d](05) e8d0fdffff call 00000f72
> >>>>>>>>>>>>>>>>>> [000011a2](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>>>> [000011a5](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>> [000011a6](01) c3 ret
> >>>>>>>>>>>>>>>>>> Size in bytes:(0021) [000011a6]
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> _main()
> >>>>>>>>>>>>>>>>>> [000011d2](01) 55 push ebp
> >>>>>>>>>>>>>>>>>> [000011d3](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>> [000011d5](05) 6892110000 push 00001192
> >>>>>>>>>>>>>>>>>> [000011da](05) 6892110000 push 00001192
> >>>>>>>>>>>>>>>>>> [000011df](05) e88efdffff call 00000f72
> >>>>>>>>>>>>>>>>>> [000011e4](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>>>> [000011e7](01) 50 push eax
> >>>>>>>>>>>>>>>>>> [000011e8](05) 68a3040000 push 000004a3
> >>>>>>>>>>>>>>>>>> [000011ed](05) e800f3ffff call 000004f2
> >>>>>>>>>>>>>>>>>> [000011f2](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>>>> [000011f5](02) 33c0 xor eax,eax
> >>>>>>>>>>>>>>>>>> [000011f7](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>> [000011f8](01) c3 ret
> >>>>>>>>>>>>>>>>>> Size in bytes:(0039) [000011f8]
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> machine stack stack machine
> >>>>>>>>>>>>>>>>>> assembly address address data code
> >>>>>>>>>>>>>>>>>> language ======== ======== ======== =========
> >>>>>>>>>>>>>>>>>> ============= [000011d2][00101f7f][00000000] 55
> >>>>>>>>>>>>>>>>>> push ebp [000011d3][00101f7f][00000000] 8bec
> >>>>>>>>>>>>>>>>>> mov ebp,esp [000011d5][00101f7b][00001192]
> >>>>>>>>>>>>>>>>>> 6892110000 push 00001192
> >>>>>>>>>>>>>>>>>> [000011da][00101f77][00001192] 6892110000 push
> >>>>>>>>>>>>>>>>>> 00001192 [000011df][00101f73][000011e4] e88efdffff
> >>>>>>>>>>>>>>>>>> call 00000f72
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> H: Begin Simulation Execution Trace Stored
> >>>>>>>>>>>>>>>>>> at:11202b Address_of_H:f72
> >>>>>>>>>>>>>>>>>> [00001192][00112017][0011201b] 55 push ebp
> >>>>>>>>>>>>>>>>>> [00001193][00112017][0011201b] 8bec mov
> >>>>>>>>>>>>>>>>>> ebp,esp [00001195][00112017][0011201b] 8b4508
> >>>>>>>>>>>>>>>>>> mov eax,[ebp+08] [00001198][00112013][00001192] 50
> >>>>>>>>>>>>>>>>>> push eax // push Px
> >>>>>>>>>>>>>>>>>> [00001199][00112013][00001192] 8b4d08 mov
> >>>>>>>>>>>>>>>>>> ecx,[ebp+08] [0000119c][0011200f][00001192] 51
> >>>>>>>>>>>>>>>>>> push ecx // push Px
> >>>>>>>>>>>>>>>>>> [0000119d][0011200b][000011a2] e8d0fdffff call
> >>>>>>>>>>>>>>>>>> 00000f72 // call H(Px,Px) H: Infinitely Recursive
> >>>>>>>>>>>>>>>>>> Simulation Detected Simulation Stopped
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis
> >>>>>>>>>>>>>>>>>> it can easily examine its stored execution_trace
> >>>>>>>>>>>>>>>>>> of Px (see above) to determine: (a) Px is calling
> >>>>>>>>>>>>>>>>>> H with the same arguments that H was called with.
> >>>>>>>>>>>>>>>>>> (b) No instructions in Px could possibly escape
> >>>>>>>>>>>>>>>>>> this otherwise infinitely recursive emulation. (c)
> >>>>>>>>>>>>>>>>>> H aborts its emulation of Px before its call to H
> >>>>>>>>>>>>>>>>>> is emulated.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> [000011e4][00101f7f][00000000] 83c408 add
> >>>>>>>>>>>>>>>>>> esp,+08 [000011e7][00101f7b][00000000] 50
> >>>>>>>>>>>>>>>>>> push eax [000011e8][00101f77][000004a3] 68a3040000
> >>>>>>>>>>>>>>>>>> push 000004a3 [000011ed][00101f77][000004a3]
> >>>>>>>>>>>>>>>>>> e800f3ffff call 000004f2 Input_Halts = 0
> >>>>>>>>>>>>>>>>>> [000011f2][00101f7f][00000000] 83c408 add
> >>>>>>>>>>>>>>>>>> esp,+08 [000011f5][00101f7f][00000000] 33c0
> >>>>>>>>>>>>>>>>>> xor eax,eax [000011f7][00101f83][00000018] 5d
> >>>>>>>>>>>>>>>>>> pop ebp [000011f8][00101f87][00000000] c3
> >>>>>>>>>>>>>>>>>> ret Number of Instructions Executed(880) == 13
> >>>>>>>>>>>>>>>>>> Pages
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> If H wasn't a simulation-based halting decider then
> >>>>>>>>>>>>>>>>> Px() would always halt; the infinite recursion is a
> >>>>>>>>>>>>>>>>> manifestation of your invalid simulation-based
> >>>>>>>>>>>>>>>>> halting decider. There is no recursion in
> >>>>>>>>>>>>>>>>> [Strachey 1965].
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> In other words you are rejecting the concept of a
> >>>>>>>>>>>>>>>> simulating halt decider even though I conclusively
> >>>>>>>>>>>>>>>> proved that it does correctly determine the halt
> >>>>>>>>>>>>>>>> status of: (see my new paper)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> No I am rejecting your simulating halt decider as it
> >>>>>>>>>>>>>>> gets the answer wrong for Px() which is not a
> >>>>>>>>>>>>>>> pathological input. Px() halts.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I just proved that H(Px,Px) does correctly predict that
> >>>>>>>>>>>>>> its complete and correct x86 emulation of its input
> >>>>>>>>>>>>>> would never reach the "ret" instruction of this input
> >>>>>>>>>>>>>> because of the pathological relationship between H and
> >>>>>>>>>>>>>> Px.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Wrong. Px() is not a pathological input as defined by
> >>>>>>>>>>>>> the halting problem and [Strachey 1965] as it does not
> >>>>>>>>>>>>> try to do the opposite of what H decides.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Your lack of comprehension does not actually count as any
> >>>>>>>>>>>> rebuttal at all.
> >>>>>>>>>>>>
> >>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>> {
> >>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>> return;
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> int main()
> >>>>>>>>>>>> {
> >>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> As shown below the above P and H have the required
> >>>>>>>>>>>> (halting problem) pathological relationship to each
> >>>>>>>>>>>> other:
> >>>>>>>>>>> [snip]
> >>>>>>>>>>>
> >>>>>>>>>>> P does but Px does not. I am talking about Px not P.
> >>>>>>>>>>>
> >>>>>>>>>>> void Px(u32 x)
> >>>>>>>>>>> {
> >>>>>>>>>>> H(x, x);
> >>>>>>>>>>> return;
> >>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>> int main()
> >>>>>>>>>>> {
> >>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add
> >>>>>>>>>>> esp,+08 ...[000013eb][00102353][00000000] 50
> >>>>>>>>>>> push eax ...[000013ec][0010234f][00000427] 6827040000
> >>>>>>>>>>> push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff
> >>>>>>>>>>> call 00000476 Input_Halts = 0
> >>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add
> >>>>>>>>>>> esp,+08 ...[000013f9][00102357][00000000] 33c0
> >>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d
> >>>>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3
> >>>>>>>>>>> ret Number of Instructions Executed(16120)
> >>>>>>>>>>>
> >>>>>>>>>>> As can be seen above Olcott's H decides that Px does not
> >>>>>>>>>>> halt but it is obvious that Px should always halt if H is
> >>>>>>>>>>> a valid halt decider that always returns a decision to its
> >>>>>>>>>>> caller (Px). Olcott's H does not return a decision to its
> >>>>>>>>>>> caller (Px) and is thus invalid.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> >
> >>>>>>>>>>
> >>>>>>>>>> Your false assumptions are directly contradicted by the
> >>>>>>>>>> semantics of the x86 programming language.
> >>>>>>>>>>
> >>>>>>>>>> *x86 Instruction Set Reference* https://c9x.me/x86/
> >>>>>>>>>>
> >>>>>>>>>> void Px(u32 x)
> >>>>>>>>>> {
> >>>>>>>>>> H(x, x);
> >>>>>>>>>> return;
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> int main()
> >>>>>>>>>> {
> >>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> _Px()
> >>>>>>>>>> [00001192](01) 55 push ebp
> >>>>>>>>>> [00001193](02) 8bec mov ebp,esp
> >>>>>>>>>> [00001195](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>> [00001198](01) 50 push eax
> >>>>>>>>>> [00001199](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>> [0000119c](01) 51 push ecx
> >>>>>>>>>> [0000119d](05) e8d0fdffff call 00000f72
> >>>>>>>>>> [000011a2](03) 83c408 add esp,+08
> >>>>>>>>>> [000011a5](01) 5d pop ebp
> >>>>>>>>>> [000011a6](01) c3 ret
> >>>>>>>>>> Size in bytes:(0021) [000011a6]
> >>>>>>>>>>
> >>>>>>>>>> _main()
> >>>>>>>>>> [000011d2](01) 55 push ebp
> >>>>>>>>>> [000011d3](02) 8bec mov ebp,esp
> >>>>>>>>>> [000011d5](05) 6892110000 push 00001192
> >>>>>>>>>> [000011da](05) 6892110000 push 00001192
> >>>>>>>>>> [000011df](05) e88efdffff call 00000f72
> >>>>>>>>>> [000011e4](03) 83c408 add esp,+08
> >>>>>>>>>> [000011e7](01) 50 push eax
> >>>>>>>>>> [000011e8](05) 68a3040000 push 000004a3
> >>>>>>>>>> [000011ed](05) e800f3ffff call 000004f2
> >>>>>>>>>> [000011f2](03) 83c408 add esp,+08
> >>>>>>>>>> [000011f5](02) 33c0 xor eax,eax
> >>>>>>>>>> [000011f7](01) 5d pop ebp
> >>>>>>>>>> [000011f8](01) c3 ret
> >>>>>>>>>> Size in bytes:(0039) [000011f8]
> >>>>>>>>>>
> >>>>>>>>>> machine stack stack machine assembly
> >>>>>>>>>> address address data code language
> >>>>>>>>>> ======== ======== ======== =========
> >>>>>>>>>> ============= [000011d2][00101f7f][00000000] 55
> >>>>>>>>>> push ebp [000011d3][00101f7f][00000000] 8bec mov
> >>>>>>>>>> ebp,esp [000011d5][00101f7b][00001192] 6892110000 push
> >>>>>>>>>> 00001192 [000011da][00101f77][00001192] 6892110000 push
> >>>>>>>>>> 00001192 [000011df][00101f73][000011e4] e88efdffff call
> >>>>>>>>>> 00000f72
> >>>>>>>>>>
> >>>>>>>>>> H: Begin Simulation Execution Trace Stored at:11202b
> >>>>>>>>>> Address_of_H:f72
> >>>>>>>>>> [00001192][00112017][0011201b] 55 push ebp
> >>>>>>>>>> [00001193][00112017][0011201b] 8bec mov ebp,esp
> >>>>>>>>>> [00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
> >>>>>>>>>> [00001198][00112013][00001192] 50 push eax //
> >>>>>>>>>> push Px [00001199][00112013][00001192] 8b4d08 mov
> >>>>>>>>>> ecx,[ebp+08] [0000119c][0011200f][00001192] 51 push
> >>>>>>>>>> ecx // push Px [0000119d][0011200b][000011a2]
> >>>>>>>>>> e8d0fdffff call 00000f72 // call H(Px,Px) H: Infinitely
> >>>>>>>>>> Recursive Simulation Detected Simulation Stopped
> >>>>>>>>>>
> >>>>>>>>>> H knows its own machine address and on this basis it can
> >>>>>>>>>> easily examine its stored execution_trace of Px (see above)
> >>>>>>>>>> to determine: (a) Px is calling H with the same arguments
> >>>>>>>>>> that H was called with. (b) No instructions in Px could
> >>>>>>>>>> possibly escape this otherwise infinitely recursive
> >>>>>>>>>> emulation. (c) H aborts its emulation of Px before its call
> >>>>>>>>>> to H is emulated.
> >>>>>>>>>>
> >>>>>>>>>> [000011e4][00101f7f][00000000] 83c408 add esp,+08
> >>>>>>>>>> [000011e7][00101f7b][00000000] 50 push eax
> >>>>>>>>>> [000011e8][00101f77][000004a3] 68a3040000 push 000004a3
> >>>>>>>>>> [000011ed][00101f77][000004a3] e800f3ffff call 000004f2
> >>>>>>>>>> Input_Halts = 0
> >>>>>>>>>> [000011f2][00101f7f][00000000] 83c408 add esp,+08
> >>>>>>>>>> [000011f5][00101f7f][00000000] 33c0 xor eax,eax
> >>>>>>>>>> [000011f7][00101f83][00000018] 5d pop ebp
> >>>>>>>>>> [000011f8][00101f87][00000000] c3 ret
> >>>>>>>>>> Number of Instructions Executed(880) == 13 Pages
> >>>>>>>>>
> >>>>>>>>> I see you wish to pointlessly go around in circles. Oh well.
> >>>>>>>>>
> >>>>>>>>> Px() is not a pathological input as defined by the halting
> >>>>>>>>> problem and [Strachey 1965] as it does not try to do the
> >>>>>>>>> opposite of what H decides.
> >>>>>>>>>
> >>>>>>>>> Px() always halts so your H gets the answer wrong.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>
> >>>>>>>> I found that my reply did not make it to all the groups so I
> >>>>>>>> posted it again.
> >>>>>>>>
> >>>>>>>> *This general principle refutes conventional halting problem
> >>>>>>>> proofs* Every simulating halt decider that correctly
> >>>>>>>> simulates its input until it correctly predicts that this
> >>>>>>>> simulated input would never reach its final state, correctly
> >>>>>>>> rejects this input as non-halting.
> >>>>>>>
> >>>>>>> Your H does not "correctly predict" that Px() does reach its
> >>>>>>> final state and so should accept the input as halting.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> (x86 Instruction Set Reference* https://c9x.me/x86/
> >>>>>>
> >>>>>> The semantics of the x86 language conclusively proves that the
> >>>>>> above code is correct. People that disagree with verified facts
> >>>>>> are either incompetent or liars. Since you cannot even
> >>>>>> understand that the return statement in Px is unreachable
> >>>>>> code, (to every simulating halt decider H) you would be
> >>>>>> incompetent.
> >>>>>
> >>>>> Not EVERY simulating halt decider, only YOURS gets the answer
> >>>>> wrong. Px() halts.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> Since you cannot even understand that the return statement in Px
> >>>> is unreachable code, (to *every simulating halt* decider H) you
> >>>> would be incompetent.
> >>>
> >>> Not at all. If I was to design a simulating halt decider then
> >>> rather than aborting the simulation at the point where P()/Px()
> >>> calls H I would instead fork the simulation, returning 0 to one
> >>> branch (the non-halting branch) and 1 to the other branch (the
> >>> halting branch) and then continue to simulate both branches in
> >>> parallel thereby getting rid of the "infinite recursion".
> >>>
> >>> /Flibble
> >>>
> >>
> >> Yet that is *not* what the actual code specifies. Every function
> >> called in infinite recursion is not allowed to return to its
> >> caller.
> >
> > The infinite recursion is an artifact of how YOU are trying to solve
> > the problem; there is no infinite recursion in [Strachey 1965] and
> > associated proofs.
> >
> > /Flibble
> >
>
> The halting problem expressly allows every algorithm in the universe
> as long as it correctly predicts the behavior of the input.
Your H does not correctly predict the behavior of Px() as Px() always
halts yet your H incorrectly says it doesn't.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | "dklei...@gmail.com" <dkleinecke@gmail.com> |
|---|---|
| Date | 2022-07-03 12:35 -0700 |
| Message-ID | <71cfc98c-0969-41c5-ba2a-a9ed6a17333an@googlegroups.com> |
| In reply to | #53362 |
On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote: > > *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. > This "general principle is" a trivial definition: A simulation of a called routine that stops when it can predict that the routine will never return is called a halt decider. In words of one syllable - so what?
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-03 14:51 -0500 |
| Message-ID | <KrednSkPVNrYblz_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #53378 |
On 7/3/2022 2:35 PM, dklei...@gmail.com wrote: > On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote: >> >> *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. >> > This "general principle is" a trivial definition: A simulation of a > called routine that stops when it can predict that the routine > will never return is called a halt decider. > > In words of one syllable - so what? *it refutes conventional halting problem proofs* -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-07-03 16:21 -0400 |
| Message-ID | <8TmwK.53186$f81.4489@fx43.iad> |
| In reply to | #53379 |
On 7/3/22 3:51 PM, olcott wrote: > On 7/3/2022 2:35 PM, dklei...@gmail.com wrote: >> On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote: >>> >>> *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. >>> >> This "general principle is" a trivial definition: A simulation of a >> called routine that stops when it can predict that the routine >> will never return is called a halt decider. >> >> In words of one syllable - so what? > > *it refutes conventional halting problem proofs* > > Only if you actually prove that you CAN correctly detect that the input will never halt, and do so in finite time. The problem, of course, is that H can't get arround the fact that if H decides to return a 0 for H(P,P) then P(P) will Halt, so the answer is wrong. The ACTUAL behavior, is that an H that refuses to be wrong, just won't answer, since ANY answer it gives will be wrong. This of course means if fails to be a decider, so still ends up being wrong. You seem to have the mistaken idea that it is allowed to presume the impossible as done, but that technique leads to inconssistent logic systems.
[toc] | [prev] | [next] | [standalone]
| From | "dklei...@gmail.com" <dkleinecke@gmail.com> |
|---|---|
| Date | 2022-07-03 16:10 -0700 |
| Message-ID | <ce6e3d21-842e-40a7-8c8c-0e9645a6123an@googlegroups.com> |
| In reply to | #53379 |
On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote: > On 7/3/2022 2:35 PM, dklei...@gmail.com wrote: > > On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote: > >> > >> *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. > >> > > This "general principle is" a trivial definition: A simulation of a > > called routine that stops when it can predict that the routine > > will never return is called a halt decider. > > > > In words of one syllable - so what? > > It refutes conventional halting problem proofs > It might if any such halt deciders existed. You need to prove such "halt deciders" exist.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-03 19:44 -0500 |
| Message-ID | <e_ydnYESOqx0ql__nZ2dnUU7_8xh4p2d@giganews.com> |
| In reply to | #53389 |
On 7/3/2022 6:10 PM, dklei...@gmail.com wrote: > On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote: >> On 7/3/2022 2:35 PM, dklei...@gmail.com wrote: >>> On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote: >>>> >>>> *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. >>>> >>> This "general principle is" a trivial definition: A simulation of a >>> called routine that stops when it can predict that the routine >>> will never return is called a halt decider. >>> >>> In words of one syllable - so what? >> >> It refutes conventional halting problem proofs >> > It might if any such halt deciders existed. You need to prove such "halt > deciders" exist. You can't keep ignoring my paper and claiming that I have not proved my point. *Halting problem proofs refuted on the basis of software engineering* https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-07-04 07:45 -0400 |
| Message-ID | <ypAwK.422046$zgr9.202542@fx13.iad> |
| In reply to | #53392 |
On 7/3/22 8:44 PM, olcott wrote: > On 7/3/2022 6:10 PM, dklei...@gmail.com wrote: >> On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote: >>> On 7/3/2022 2:35 PM, dklei...@gmail.com wrote: >>>> On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote: >>>>> >>>>> *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. >>>>> >>>> This "general principle is" a trivial definition: A simulation of a >>>> called routine that stops when it can predict that the routine >>>> will never return is called a halt decider. >>>> >>>> In words of one syllable - so what? >>> >>> It refutes conventional halting problem proofs >>> >> It might if any such halt deciders existed. You need to prove such "halt >> deciders" exist. > > > You can't keep ignoring my paper and claiming that I have not proved my > point. > > *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 > > > > Rule (b) is incorrect. FAIL.
[toc] | [prev] | [next] | [standalone]
| From | "dklei...@gmail.com" <dkleinecke@gmail.com> |
|---|---|
| Date | 2022-07-04 09:36 -0700 |
| Message-ID | <b6b11736-6b02-4ee0-a9c5-62a7e3a388afn@googlegroups.com> |
| In reply to | #53392 |
On Sunday, July 3, 2022 at 5:44:32 PM UTC-7, olcott wrote: > On 7/3/2022 6:10 PM, dklei...@gmail.com wrote: > > On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote: > >> On 7/3/2022 2:35 PM, dklei...@gmail.com wrote: > >>> On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote: > >>>> > >>>> *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. > >>>> > >>> This "general principle is" a trivial definition: A simulation of a > >>> called routine that stops when it can predict that the routine > >>> will never return is called a halt decider. > >>> > >>> In words of one syllable - so what? > >> > >> It refutes conventional halting problem proofs > >> > > It might if any such halt deciders existed. You need to prove such "halt > > deciders" exist. > > You can't keep ignoring my paper and claiming that I have not proved my > point. > *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 > Your paper is not acceptable as a proof of anything. But that is to be expected because my standard is mathematical proof and you don't even pretend to be doing mathematics.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-04 11:57 -0500 |
| Message-ID | <JZGdnTDV77xthl7_nZ2dnUU7_8xh4p2d@giganews.com> |
| In reply to | #53402 |
On 7/4/2022 11:36 AM, dklei...@gmail.com wrote: > On Sunday, July 3, 2022 at 5:44:32 PM UTC-7, olcott wrote: >> On 7/3/2022 6:10 PM, dklei...@gmail.com wrote: >>> On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote: >>>> On 7/3/2022 2:35 PM, dklei...@gmail.com wrote: >>>>> On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote: >>>>>> >>>>>> *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. >>>>>> >>>>> This "general principle is" a trivial definition: A simulation of a >>>>> called routine that stops when it can predict that the routine >>>>> will never return is called a halt decider. >>>>> >>>>> In words of one syllable - so what? >>>> >>>> It refutes conventional halting problem proofs >>>> >>> It might if any such halt deciders existed. You need to prove such "halt >>> deciders" exist. >> >> You can't keep ignoring my paper and claiming that I have not proved my >> point. >> *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 >> > Your paper is not acceptable as a proof of anything. But that is to > be expected because my standard is mathematical proof and > you don't even pretend to be doing mathematics. When we construe the x86 language and its associated semantics as a formal language with formal semantics then this becomes a formal proof: From a purely software engineering perspective (anchored in the semantics of the x86 language) it is proven that H(P,P) correctly predicts that its correct and complete x86 emulation of its input would never reach the "ret" instruction (final state) of this input. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "dklei...@gmail.com" <dkleinecke@gmail.com> |
|---|---|
| Date | 2022-07-04 11:42 -0700 |
| Message-ID | <a00e06f5-c295-40e1-92b1-3080eed69479n@googlegroups.com> |
| In reply to | #53404 |
On Monday, July 4, 2022 at 9:57:28 AM UTC-7, olcott wrote: > On 7/4/2022 11:36 AM, dklei...@gmail.com wrote: > > On Sunday, July 3, 2022 at 5:44:32 PM UTC-7, olcott wrote: > >> On 7/3/2022 6:10 PM, dklei...@gmail.com wrote: > >>> On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote: > >>>> On 7/3/2022 2:35 PM, dklei...@gmail.com wrote: > >>>>> On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote: > >>>>>> > >>>>>> *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. > >>>>>> > >>>>> This "general principle is" a trivial definition: A simulation of a > >>>>> called routine that stops when it can predict that the routine > >>>>> will never return is called a halt decider. > >>>>> > >>>>> In words of one syllable - so what? > >>>> > >>>> It refutes conventional halting problem proofs > >>>> > >>> It might if any such halt deciders existed. You need to prove such "halt > >>> deciders" exist. > >> > >> You can't keep ignoring my paper and claiming that I have not proved my > >> point. > >> *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 > >> > > Your paper is not acceptable as a proof of anything. But that is to > > be expected because my standard is mathematical proof and > > you don't even pretend to be doing mathematics. > > When we construe the x86 language and its associated semantics as a > formal language with formal semantics then this becomes a formal proof: > There is a great deal more to a mathematical proof than a formal language. I believe that you do not have training in mathematics and you do show little sympathy for the concerns of the mathematical community. What you call "software engineering" is essentially hostile to classical mathematics. Moreover if you wish us to take you seriously you must do more than "construing". You must exhibit the x86 "language" as a formal system and show how it is used in a formal proof.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-04 14:17 -0500 |
| Message-ID | <-vGdnazQwchWoV7_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #53412 |
On 7/4/2022 1:42 PM, dklei...@gmail.com wrote: > On Monday, July 4, 2022 at 9:57:28 AM UTC-7, olcott wrote: >> On 7/4/2022 11:36 AM, dklei...@gmail.com wrote: >>> On Sunday, July 3, 2022 at 5:44:32 PM UTC-7, olcott wrote: >>>> On 7/3/2022 6:10 PM, dklei...@gmail.com wrote: >>>>> On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote: >>>>>> On 7/3/2022 2:35 PM, dklei...@gmail.com wrote: >>>>>>> On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote: >>>>>>>> >>>>>>>> *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. >>>>>>>> >>>>>>> This "general principle is" a trivial definition: A simulation of a >>>>>>> called routine that stops when it can predict that the routine >>>>>>> will never return is called a halt decider. >>>>>>> >>>>>>> In words of one syllable - so what? >>>>>> >>>>>> It refutes conventional halting problem proofs >>>>>> >>>>> It might if any such halt deciders existed. You need to prove such "halt >>>>> deciders" exist. >>>> >>>> You can't keep ignoring my paper and claiming that I have not proved my >>>> point. >>>> *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 >>>> >>> Your paper is not acceptable as a proof of anything. But that is to >>> be expected because my standard is mathematical proof and >>> you don't even pretend to be doing mathematics. >> >> When we construe the x86 language and its associated semantics as a >> formal language with formal semantics then this becomes a formal proof: >> > There is a great deal more to a mathematical proof than a formal > language. I believe that you do not have training in mathematics and you > do show little sympathy for the concerns of the mathematical > community. What you call "software engineering" is essentially hostile to > classical mathematics. > > Moreover if you wish us to take you seriously you must do more than > "construing". You must exhibit the x86 "language" as a formal system > and show how it is used in a formal proof. What more is there to the essence of any formal proof besides applying the formal semantics specified by a formal language as a sequence of truth preserving steps? Instead of premises a computation has an initial state. Instead of a conclusion premises a computation has a final state. *Curry–Howard correspondence* In programming language theory and proof theory, the Curry–Howard correspondence (also known as the Curry–Howard isomorphism or equivalence, or the proofs-as-programs and propositions- or formulae-as-types interpretation) is the direct relationship between computer programs and mathematical proofs. https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-04 14:21 -0500 |
| Message-ID | <-vGdna_QwcgvoF7_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #53417 |
On 7/4/2022 2:17 PM, olcott wrote: > On 7/4/2022 1:42 PM, dklei...@gmail.com wrote: >> On Monday, July 4, 2022 at 9:57:28 AM UTC-7, olcott wrote: >>> On 7/4/2022 11:36 AM, dklei...@gmail.com wrote: >>>> On Sunday, July 3, 2022 at 5:44:32 PM UTC-7, olcott wrote: >>>>> On 7/3/2022 6:10 PM, dklei...@gmail.com wrote: >>>>>> On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote: >>>>>>> On 7/3/2022 2:35 PM, dklei...@gmail.com wrote: >>>>>>>> On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote: >>>>>>>>> >>>>>>>>> *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. >>>>>>>>> >>>>>>>> This "general principle is" a trivial definition: A simulation of a >>>>>>>> called routine that stops when it can predict that the routine >>>>>>>> will never return is called a halt decider. >>>>>>>> >>>>>>>> In words of one syllable - so what? >>>>>>> >>>>>>> It refutes conventional halting problem proofs >>>>>>> >>>>>> It might if any such halt deciders existed. You need to prove such >>>>>> "halt >>>>>> deciders" exist. >>>>> >>>>> You can't keep ignoring my paper and claiming that I have not >>>>> proved my >>>>> point. >>>>> *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 >>>>> >>>>> >>>> Your paper is not acceptable as a proof of anything. But that is to >>>> be expected because my standard is mathematical proof and >>>> you don't even pretend to be doing mathematics. >>> >>> When we construe the x86 language and its associated semantics as a >>> formal language with formal semantics then this becomes a formal proof: >>> >> There is a great deal more to a mathematical proof than a formal >> language. I believe that you do not have training in mathematics and you >> do show little sympathy for the concerns of the mathematical >> community. What you call "software engineering" is essentially hostile to >> classical mathematics. >> >> Moreover if you wish us to take you seriously you must do more than >> "construing". You must exhibit the x86 "language" as a formal system >> and show how it is used in a formal proof. > > What more is there to the essence of any formal proof besides applying > the formal semantics specified by a formal language as a sequence of > truth preserving steps? > > Instead of premises a computation has an initial state. > Instead of a conclusion premises a computation has a final state. Instead of a conclusion a computation has a final state. > > *Curry–Howard correspondence* > In programming language theory and proof theory, the Curry–Howard > correspondence (also known as the Curry–Howard isomorphism or > equivalence, or the proofs-as-programs and propositions- or > formulae-as-types interpretation) is the direct relationship between > computer programs and mathematical proofs. > > https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence > -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-04 18:08 -0500 |
| Subject | Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] |
| Message-ID | <SYWdnQoA9L5I717_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #53412 |
On 7/4/2022 1:42 PM, dklei...@gmail.com wrote: > On Monday, July 4, 2022 at 9:57:28 AM UTC-7, olcott wrote: >> On 7/4/2022 11:36 AM, dklei...@gmail.com wrote: >>> On Sunday, July 3, 2022 at 5:44:32 PM UTC-7, olcott wrote: >>>> On 7/3/2022 6:10 PM, dklei...@gmail.com wrote: >>>>> On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote: >>>>>> On 7/3/2022 2:35 PM, dklei...@gmail.com wrote: >>>>>>> On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote: >>>>>>>> >>>>>>>> *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. >>>>>>>> >>>>>>> This "general principle is" a trivial definition: A simulation of a >>>>>>> called routine that stops when it can predict that the routine >>>>>>> will never return is called a halt decider. >>>>>>> >>>>>>> In words of one syllable - so what? >>>>>> >>>>>> It refutes conventional halting problem proofs >>>>>> >>>>> It might if any such halt deciders existed. You need to prove such "halt >>>>> deciders" exist. >>>> >>>> You can't keep ignoring my paper and claiming that I have not proved my >>>> point. >>>> *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 >>>> >>> Your paper is not acceptable as a proof of anything. But that is to >>> be expected because my standard is mathematical proof and >>> you don't even pretend to be doing mathematics. >> >> When we construe the x86 language and its associated semantics as a >> formal language with formal semantics then this becomes a formal proof: >> > There is a great deal more to a mathematical proof than a formal > language. I believe that you do not have training in mathematics and you > do show little sympathy for the concerns of the mathematical > community. What you call "software engineering" is essentially hostile to > classical mathematics. > > Moreover if you wish us to take you seriously you must do more than > "construing". You must exhibit the x86 "language" as a formal system > and show how it is used in a formal proof. It would seem that *Curry–Howard correspondence* https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence would allow the x86 language and its semantics to be construed as a formal system such that the initial state and final state of a computable function along with all of the state transitions between could be construed as a formal proof. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "dklei...@gmail.com" <dkleinecke@gmail.com> |
|---|---|
| Date | 2022-07-05 11:50 -0700 |
| Subject | Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] |
| Message-ID | <811d7421-acdc-4586-a027-15f5faf7ee3fn@googlegroups.com> |
| In reply to | #53420 |
On Monday, July 4, 2022 at 4:08:12 PM UTC-7, olcott wrote: > On 7/4/2022 1:42 PM, dklei...@gmail.com wrote: > > On Monday, July 4, 2022 at 9:57:28 AM UTC-7, olcott wrote: > >> On 7/4/2022 11:36 AM, dklei...@gmail.com wrote: > >>> On Sunday, July 3, 2022 at 5:44:32 PM UTC-7, olcott wrote: > >>>> On 7/3/2022 6:10 PM, dklei...@gmail.com wrote: > >>>>> On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote: > >>>>>> On 7/3/2022 2:35 PM, dklei...@gmail.com wrote: > >>>>>>> On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote: > >>>>>>>> > >>>>>>>> *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. > >>>>>>>> > >>>>>>> This "general principle is" a trivial definition: A simulation of a > >>>>>>> called routine that stops when it can predict that the routine > >>>>>>> will never return is called a halt decider. > >>>>>>> > >>>>>>> In words of one syllable - so what? > >>>>>> > >>>>>> It refutes conventional halting problem proofs > >>>>>> > >>>>> It might if any such halt deciders existed. You need to prove such "halt > >>>>> deciders" exist. > >>>> > >>>> You can't keep ignoring my paper and claiming that I have not proved my > >>>> point. > >>>> *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 > >>>> > >>> Your paper is not acceptable as a proof of anything. But that is to > >>> be expected because my standard is mathematical proof and > >>> you don't even pretend to be doing mathematics. > >> > >> When we construe the x86 language and its associated semantics as a > >> formal language with formal semantics then this becomes a formal proof: > >> > > There is a great deal more to a mathematical proof than a formal > > language. I believe that you do not have training in mathematics and you > > do show little sympathy for the concerns of the mathematical > > community. What you call "software engineering" is essentially hostile to > > classical mathematics. > > > > Moreover if you wish us to take you seriously you must do more than > > "construing". You must exhibit the x86 "language" as a formal system > > and show how it is used in a formal proof. > It would seem that *Curry–Howard correspondence* > https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence > would allow the x86 language and its semantics to be construed as a > formal system such that the initial state and final state of a > computable function along with all of the state transitions between > could be construed as a formal proof. I am afraid you don't see mathematical proof like a mathematician might. A good and simple example is the theorem that proves all Burnside three groups are finite. But if you do want to use the Curry-Howard correspondence as a proof method you must either reference the formal x86 language formulation or yourself supply such a formal language description. Your task would be much easier were you to use C as the formal language. And much easier to follow.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-05 14:31 -0500 |
| Subject | Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] |
| Message-ID | <f8ednbiyxKkBDFn_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #53429 |
On 7/5/2022 1:50 PM, dklei...@gmail.com wrote:
> On Monday, July 4, 2022 at 4:08:12 PM UTC-7, olcott wrote:
>> On 7/4/2022 1:42 PM, dklei...@gmail.com wrote:
>>> On Monday, July 4, 2022 at 9:57:28 AM UTC-7, olcott wrote:
>>>> On 7/4/2022 11:36 AM, dklei...@gmail.com wrote:
>>>>> On Sunday, July 3, 2022 at 5:44:32 PM UTC-7, olcott wrote:
>>>>>> On 7/3/2022 6:10 PM, dklei...@gmail.com wrote:
>>>>>>> On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote:
>>>>>>>> On 7/3/2022 2:35 PM, dklei...@gmail.com wrote:
>>>>>>>>> On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote:
>>>>>>>>>>
>>>>>>>>>> *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.
>>>>>>>>>>
>>>>>>>>> This "general principle is" a trivial definition: A simulation of a
>>>>>>>>> called routine that stops when it can predict that the routine
>>>>>>>>> will never return is called a halt decider.
>>>>>>>>>
>>>>>>>>> In words of one syllable - so what?
>>>>>>>>
>>>>>>>> It refutes conventional halting problem proofs
>>>>>>>>
>>>>>>> It might if any such halt deciders existed. You need to prove such "halt
>>>>>>> deciders" exist.
>>>>>>
>>>>>> You can't keep ignoring my paper and claiming that I have not proved my
>>>>>> point.
>>>>>> *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
>>>>>>
>>>>> Your paper is not acceptable as a proof of anything. But that is to
>>>>> be expected because my standard is mathematical proof and
>>>>> you don't even pretend to be doing mathematics.
>>>>
>>>> When we construe the x86 language and its associated semantics as a
>>>> formal language with formal semantics then this becomes a formal proof:
>>>>
>>> There is a great deal more to a mathematical proof than a formal
>>> language. I believe that you do not have training in mathematics and you
>>> do show little sympathy for the concerns of the mathematical
>>> community. What you call "software engineering" is essentially hostile to
>>> classical mathematics.
>>>
>>> Moreover if you wish us to take you seriously you must do more than
>>> "construing". You must exhibit the x86 "language" as a formal system
>>> and show how it is used in a formal proof.
>> It would seem that *Curry–Howard correspondence*
>> https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence
>> would allow the x86 language and its semantics to be construed as a
>> formal system such that the initial state and final state of a
>> computable function along with all of the state transitions between
>> could be construed as a formal proof.
>
> I am afraid you don't see mathematical proof like a mathematician
> might. A good and simple example is the theorem that proves all
> Burnside three groups are finite.
>
> But if you do want to use the Curry-Howard correspondence as a
> proof method you must either reference the formal x86 language
> formulation or yourself supply such a formal language description.
>
I already provided this:
x86 Instruction Set Reference
https://c9x.me/x86/
> Your task would be much easier were you to use C as the formal
> language. And much easier to follow.
If we use C as the formal language then we have to translate it into its
corresponding directed graph of control flow ourselves or the computer
will not be able to process it.
I use C/x86 together so the human can examine the C and the machine can
examine the machine code and the human can see the bijection between the
C and the machine code as assembly language generated from the C.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
_P()
[00001202](01) 55 push ebp
[00001203](02) 8bec mov ebp,esp
[00001205](03) 8b4508 mov eax,[ebp+08]
[00001208](01) 50 push eax
[00001209](03) 8b4d08 mov ecx,[ebp+08]
[0000120c](01) 51 push ecx
[0000120d](05) e820feffff call 00001032
[00001212](03) 83c408 add esp,+08
[00001215](02) 85c0 test eax,eax
[00001217](02) 7402 jz 0000121b
[00001219](02) ebfe jmp 00001219
[0000121b](01) 5d pop ebp
[0000121c](01) c3 ret
Size in bytes:(0027) [0000121c]
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "dklei...@gmail.com" <dkleinecke@gmail.com> |
|---|---|
| Date | 2022-07-05 16:21 -0700 |
| Subject | Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] |
| Message-ID | <45f4edee-967a-4d82-bf82-e08ed3c022een@googlegroups.com> |
| In reply to | #53431 |
On Tuesday, July 5, 2022 at 12:31:47 PM UTC-7, olcott wrote: > On 7/5/2022 1:50 PM, dklei...@gmail.com wrote: > > > > But if you do want to use the Curry-Howard correspondence as a > > proof method you must either reference the formal x86 language > > formulation or yourself supply such a formal language description. > > > I already provided this: > x86 Instruction Set Reference > https://c9x.me/x86/ .> We have been here before. A list of op-codes is not a formal language description. > > > Your task would be much easier were you to use C as the formal > > language. And much easier to follow. > >> If we use C as the formal language then we have to translate it into its > corresponding directed graph of control flow ourselves or the computer > will not be able to process it. > You don't need to compile. The readers whom you want to convince can read and follow C. That's the level mathematics is done at. > > I use C/x86 together so the human can examine the C and the machine can > examine the machine code and the human can see the bijection between the > C and the machine code as assembly language generated from the C. .> Nobody cares about that "bijection" and messing with it wastes everybody's time.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-05 18:37 -0500 |
| Subject | Re: Halting problem proofs refuted on the basis of software engineering [ Curry–Howard correspondence ] |
| Message-ID | <hbudnSRlFM-2Vln_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #53445 |
On 7/5/2022 6:21 PM, dklei...@gmail.com wrote: > On Tuesday, July 5, 2022 at 12:31:47 PM UTC-7, olcott wrote: >> On 7/5/2022 1:50 PM, dklei...@gmail.com wrote: >>> >>> But if you do want to use the Curry-Howard correspondence as a >>> proof method you must either reference the formal x86 language >>> formulation or yourself supply such a formal language description. >>> >> I already provided this: >> x86 Instruction Set Reference >> https://c9x.me/x86/ > .> > We have been here before. A list of op-codes is not a formal language > description. Read the rest of the 500 pages. >> >>> Your task would be much easier were you to use C as the formal >>> language. And much easier to follow. >> >>> If we use C as the formal language then we have to translate it into its >> corresponding directed graph of control flow ourselves or the computer >> will not be able to process it. >> > You don't need to compile. The readers whom you want to convince can > read and follow C. That's the level mathematics is done at. The halt decider itself must have machine code. >> >> I use C/x86 together so the human can examine the C and the machine can >> examine the machine code and the human can see the bijection between the >> C and the machine code as assembly language generated from the C. > .> > Nobody cares about that "bijection" and messing with it wastes everybody's > time. The halt decider must have machine code the human users can see this in C and the assembly language mapping from C to x86 assembly language allows the human users to see what the halt decider is doing and verify that it is correct. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.theory
csiph-web