Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #85176 > unrolled thread
| Started by | olcott <NoOne@NoWhere.com> |
|---|---|
| First post | 2022-07-14 14:19 -0500 |
| Last post | 2022-07-15 13:19 -0700 |
| Articles | 20 on this page of 161 — 11 participants |
Back to article view | Back to comp.lang.c++
Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 14:19 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-14 20:28 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 15:02 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-14 21:22 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 16:02 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-14 23:30 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 17:41 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 07:23 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 01:46 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-15 07:48 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 13:06 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 09:19 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 15:32 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 10:07 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 16:18 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 10:27 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 16:29 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 16:49 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 10:58 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 17:03 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 12:00 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 18:08 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 12:26 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 18:28 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 12:39 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 18:46 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 12:57 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 19:04 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 13:17 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 19:23 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 13:34 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 19:46 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 13:31 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 19:41 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 14:04 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 20:11 +0100
Re: Halting problem proofs refuted on the basis of software engineering [ establishing my authorship and asserting my copyrights ] olcott <NoOne@NoWhere.com> - 2022-07-15 14:28 -0500
Re: Halting problem proofs refuted on the basis of software engineering [ establishing my authorship and asserting my copyrights ] Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 20:33 +0100
Re: Halting problem proofs refuted on the basis of software engineering [ establishing my authorship and asserting my copyrights ] Richard Damon <Richard@Damon-Family.org> - 2022-07-15 19:32 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 12:20 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 20:23 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 12:26 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 20:27 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) scott@slp53.sl.home (Scott Lurndal) - 2022-07-15 19:37 +0000
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 12:39 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 20:41 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 12:53 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 15:03 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 13:06 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 15:16 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 13:23 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 21:26 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 13:36 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 21:39 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 13:44 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 21:49 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 14:08 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 22:10 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 14:14 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 22:20 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 14:27 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 22:29 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 14:36 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 22:39 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 15:03 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 23:05 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick23@gmail.com> - 2022-07-15 15:43 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 23:47 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick23@gmail.com> - 2022-07-15 16:01 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-16 00:08 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick23@gmail.com> - 2022-07-15 16:18 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 18:12 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick23@gmail.com> - 2022-07-15 16:22 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 18:44 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick23@gmail.com> - 2022-07-15 16:51 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 18:59 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick23@gmail.com> - 2022-07-15 17:08 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-15 20:59 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 20:24 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-15 23:17 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 22:50 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-16 06:47 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-16 10:15 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-16 11:41 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick23@gmail.com> - 2022-07-15 16:34 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 18:54 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick23@gmail.com> - 2022-07-15 16:58 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 19:07 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick23@gmail.com> - 2022-07-15 17:17 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-15 19:44 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 17:50 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Big Dick <bigdick22@gmail.com> - 2022-07-15 22:42 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Big Dick <Big.Dick@olcott.crap> - 2022-07-15 21:22 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-15 19:49 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-15 19:38 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 18:56 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-15 21:05 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 20:36 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-15 21:47 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 20:57 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-15 22:12 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 21:27 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-15 22:39 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-16 00:15 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick23@gmail.com> - 2022-07-16 00:59 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-16 08:38 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-16 06:36 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-16 08:39 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-16 10:15 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-16 10:16 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-16 08:33 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-14 21:21 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 13:27 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Harnden <richard.nospam@gmail.com> - 2022-07-14 21:53 +0100
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 16:09 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 14:21 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 16:32 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-14 21:32 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 16:06 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 14:16 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 16:24 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 14:32 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 16:35 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 14:39 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 16:45 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 18:34 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 20:43 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 18:46 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 14:45 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 16:57 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 15:21 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 17:37 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 15:44 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 17:54 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 16:05 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 16:07 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 16:08 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 18:15 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 16:18 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 16:19 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 18:25 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 17:15 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Siri Cruise <chine.bleu@yahoo.com> - 2022-07-14 17:24 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 19:33 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-14 21:53 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-15 00:01 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Richard Damon <Richard@Damon-Family.org> - 2022-07-15 07:56 -0400
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 09:22 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 17:51 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 20:00 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 18:28 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 18:29 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Siri Cruise <chine.bleu@yahoo.com> - 2022-07-14 18:28 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 18:28 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-14 18:12 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-14 16:17 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 12:14 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 14:48 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 13:01 -0700
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) olcott <NoOne@NoWhere.com> - 2022-07-15 15:11 -0500
Re: Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) Skep Dick <skepdick22@gmail.com> - 2022-07-15 13:19 -0700
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-14 14:19 -0500 |
| Subject | Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it) |
| Message-ID | <FcSdnWH56LrW8U3_nZ2dnUU7_8zNnZ2d@giganews.com> |
This is an explanation of a key new insight into the halting problem
provided in the language of software engineering. Technical computer
science terms are explained using software engineering terms. No
knowledge of the halting problem is required.
It is based on fully operational software executed in the x86utm
operating system. The x86utm operating system (based on an excellent
open source x86 emulator) was created to study the details of the
halting problem proof counter-examples at the much higher level of
abstraction of C/x86.
typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
When simulating halt decider H(P,P) simulates its input we can see that:
(1) Function H() is called from P().
(2) With the same arguments to H().
(3) With no instructions in P preceding its invocation of H(P,P).
The above shows that the simulated P cannot possibly terminate normally.
Because H can see the same (1)(2)(3) that we see H aborts its simulation
of P and rejects P as non-halting.
In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program
and an input, whether the program will finish running, or continue
to run forever. Alan Turing proved in 1936 that a general
algorithm to solve the halting problem for all possible program-
input pairs cannot exist.
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
H and P implement the exact pathological relationship to each other as
described above. Because H(P,P) does handle this case the above halting
problem undecidable input template has been refuted.
*When this halt deciding principle understood to be correct*
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
*Then (by logical necessity) this implements that principle*
Every simulating halt decider that correctly simulates its input until
it correctly predicts that this simulated input would never terminate
normally, correctly rejects this input as non-halting.
*H is a Pure function*
https://en.wikipedia.org/wiki/Pure_function
thus implements a *Computable function*
https://en.wikipedia.org/wiki/Computable_function
Thus H is Turing computable.
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-07-14 20:28 +0100 |
| Message-ID | <20220714202849.0000684f@reddwarf.jmc.corp> |
| In reply to | #85176 |
On Thu, 14 Jul 2022 14:19:38 -0500
olcott <NoOne@NoWhere.com> wrote:
> This is an explanation of a key new insight into the halting problem
> provided in the language of software engineering. Technical computer
> science terms are explained using software engineering terms. No
> knowledge of the halting problem is required.
>
> It is based on fully operational software executed in the x86utm
> operating system. The x86utm operating system (based on an excellent
> open source x86 emulator) was created to study the details of the
> halting problem proof counter-examples at the much higher level of
> abstraction of C/x86.
>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
>
> When simulating halt decider H(P,P) simulates its input we can see
> that: (1) Function H() is called from P().
> (2) With the same arguments to H().
> (3) With no instructions in P preceding its invocation of H(P,P).
>
> The above shows that the simulated P cannot possibly terminate
> normally. Because H can see the same (1)(2)(3) that we see H aborts
> its simulation of P and rejects P as non-halting.
>
> In computability theory, the halting problem is the problem of
> determining, from a description of an arbitrary computer program
> and an input, whether the program will finish running, or
> continue to run forever. Alan Turing proved in 1936 that a general
> algorithm to solve the halting problem for all possible program-
> input pairs cannot exist.
>
> 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
>
> H and P implement the exact pathological relationship to each other
> as described above. Because H(P,P) does handle this case the above
> halting problem undecidable input template has been refuted.
>
> *When this halt deciding principle understood to be correct*
> A halt decider must compute the mapping from its inputs to an accept
> or reject state on the basis of the actual behavior that is actually
> specified by these inputs.
>
> *Then (by logical necessity) this implements that principle*
> Every simulating halt decider that correctly simulates its input
> until it correctly predicts that this simulated input would never
> terminate normally, correctly rejects this input as non-halting.
>
> *H is a Pure function*
> https://en.wikipedia.org/wiki/Pure_function
>
> thus implements a *Computable function*
> https://en.wikipedia.org/wiki/Computable_function
>
> Thus H is Turing computable.
>
> *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
You forgot to mention infinite recursion which I suppose is progress.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-14 15:02 -0500 |
| Message-ID | <BY2dncVqJfnT603_nZ2dnUU7_8xg4p2d@giganews.com> |
| In reply to | #85177 |
On 7/14/2022 2:28 PM, Mr Flibble wrote:
> On Thu, 14 Jul 2022 14:19:38 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> This is an explanation of a key new insight into the halting problem
>> provided in the language of software engineering. Technical computer
>> science terms are explained using software engineering terms. No
>> knowledge of the halting problem is required.
>>
>> It is based on fully operational software executed in the x86utm
>> operating system. The x86utm operating system (based on an excellent
>> open source x86 emulator) was created to study the details of the
>> halting problem proof counter-examples at the much higher level of
>> abstraction of C/x86.
>>
>> typedef void (*ptr)();
>> int H(ptr p, ptr i); // simulating halt decider
>>
>> void P(ptr x)
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(P, P));
>> }
>>
>> When simulating halt decider H(P,P) simulates its input we can see
>> that: (1) Function H() is called from P().
>> (2) With the same arguments to H().
>> (3) With no instructions in P preceding its invocation of H(P,P).
>>
>> The above shows that the simulated P cannot possibly terminate
>> normally. Because H can see the same (1)(2)(3) that we see H aborts
>> its simulation of P and rejects P as non-halting.
>>
>> In computability theory, the halting problem is the problem of
>> determining, from a description of an arbitrary computer program
>> and an input, whether the program will finish running, or
>> continue to run forever. Alan Turing proved in 1936 that a general
>> algorithm to solve the halting problem for all possible program-
>> input pairs cannot exist.
>>
>> 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
>>
>> H and P implement the exact pathological relationship to each other
>> as described above. Because H(P,P) does handle this case the above
>> halting problem undecidable input template has been refuted.
>>
>> *When this halt deciding principle understood to be correct*
>> A halt decider must compute the mapping from its inputs to an accept
>> or reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>>
>> *Then (by logical necessity) this implements that principle*
>> Every simulating halt decider that correctly simulates its input
>> until it correctly predicts that this simulated input would never
>> terminate normally, correctly rejects this input as non-halting.
>>
>> *H is a Pure function*
>> https://en.wikipedia.org/wiki/Pure_function
>>
>> thus implements a *Computable function*
>> https://en.wikipedia.org/wiki/Computable_function
>>
>> Thus H is Turing computable.
>>
>> *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
>
> You forgot to mention infinite recursion which I suppose is progress.
>
> /Flibble
>
I have proved that H(P,P) == 0 is correct.
I have shown that H/P does implement the HP's "impossible input" template.
Therefore I have refuted all of the halting problem proofs that rely on
this template.
--
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.corp> |
|---|---|
| Date | 2022-07-14 21:22 +0100 |
| Message-ID | <20220714212232.000073ab@reddwarf.jmc.corp> |
| In reply to | #85178 |
On Thu, 14 Jul 2022 15:02:21 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/14/2022 2:28 PM, Mr Flibble wrote:
> > On Thu, 14 Jul 2022 14:19:38 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> This is an explanation of a key new insight into the halting
> >> problem provided in the language of software engineering.
> >> Technical computer science terms are explained using software
> >> engineering terms. No knowledge of the halting problem is required.
> >>
> >> It is based on fully operational software executed in the x86utm
> >> operating system. The x86utm operating system (based on an
> >> excellent open source x86 emulator) was created to study the
> >> details of the halting problem proof counter-examples at the much
> >> higher level of abstraction of C/x86.
> >>
> >> typedef void (*ptr)();
> >> int H(ptr p, ptr i); // simulating halt decider
> >>
> >> void P(ptr x)
> >> {
> >> int Halt_Status = H(x, x);
> >> if (Halt_Status)
> >> HERE: goto HERE;
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H(P, P));
> >> }
> >>
> >> When simulating halt decider H(P,P) simulates its input we can see
> >> that: (1) Function H() is called from P().
> >> (2) With the same arguments to H().
> >> (3) With no instructions in P preceding its invocation of H(P,P).
> >>
> >> The above shows that the simulated P cannot possibly terminate
> >> normally. Because H can see the same (1)(2)(3) that we see H aborts
> >> its simulation of P and rejects P as non-halting.
> >>
> >> In computability theory, the halting problem is the problem
> >> of determining, from a description of an arbitrary computer program
> >> and an input, whether the program will finish running, or
> >> continue to run forever. Alan Turing proved in 1936 that a general
> >> algorithm to solve the halting problem for all possible
> >> program- input pairs cannot exist.
> >>
> >> 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
> >>
> >> H and P implement the exact pathological relationship to each other
> >> as described above. Because H(P,P) does handle this case the above
> >> halting problem undecidable input template has been refuted.
> >>
> >> *When this halt deciding principle understood to be correct*
> >> A halt decider must compute the mapping from its inputs to an
> >> accept or reject state on the basis of the actual behavior that is
> >> actually specified by these inputs.
> >>
> >> *Then (by logical necessity) this implements that principle*
> >> Every simulating halt decider that correctly simulates its input
> >> until it correctly predicts that this simulated input would never
> >> terminate normally, correctly rejects this input as non-halting.
> >>
> >> *H is a Pure function*
> >> https://en.wikipedia.org/wiki/Pure_function
> >>
> >> thus implements a *Computable function*
> >> https://en.wikipedia.org/wiki/Computable_function
> >>
> >> Thus H is Turing computable.
> >>
> >> *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
> >>
> >
> > You forgot to mention infinite recursion which I suppose is
> > progress.
> >
> > /Flibble
> >
>
> I have proved that H(P,P) == 0 is correct.
>
> I have shown that H/P does implement the HP's "impossible input"
> template.
>
> Therefore I have refuted all of the halting problem proofs that rely
> on this template.
Equating pathological input with non-halting is erroneous: you are only
doing that because your broken solution treats it as "infinite
recursion". There is no recursion in [Strachey 1965] and the HP proofs
based on it.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-14 16:02 -0500 |
| Message-ID | <5e-dnXyI2LDxGU3_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #85179 |
On 7/14/2022 3:22 PM, Mr Flibble wrote:
> On Thu, 14 Jul 2022 15:02:21 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
>>> On Thu, 14 Jul 2022 14:19:38 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> This is an explanation of a key new insight into the halting
>>>> problem provided in the language of software engineering.
>>>> Technical computer science terms are explained using software
>>>> engineering terms. No knowledge of the halting problem is required.
>>>>
>>>> It is based on fully operational software executed in the x86utm
>>>> operating system. The x86utm operating system (based on an
>>>> excellent open source x86 emulator) was created to study the
>>>> details of the halting problem proof counter-examples at the much
>>>> higher level of abstraction of C/x86.
>>>>
>>>> typedef void (*ptr)();
>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>
>>>> void P(ptr x)
>>>> {
>>>> int Halt_Status = H(x, x);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H(P, P));
>>>> }
>>>>
>>>> When simulating halt decider H(P,P) simulates its input we can see
>>>> that: (1) Function H() is called from P().
>>>> (2) With the same arguments to H().
>>>> (3) With no instructions in P preceding its invocation of H(P,P).
>>>>
>>>> The above shows that the simulated P cannot possibly terminate
>>>> normally. Because H can see the same (1)(2)(3) that we see H aborts
>>>> its simulation of P and rejects P as non-halting.
>>>>
>>>> In computability theory, the halting problem is the problem
>>>> of determining, from a description of an arbitrary computer program
>>>> and an input, whether the program will finish running, or
>>>> continue to run forever. Alan Turing proved in 1936 that a general
>>>> algorithm to solve the halting problem for all possible
>>>> program- input pairs cannot exist.
>>>>
>>>> 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
>>>>
>>>> H and P implement the exact pathological relationship to each other
>>>> as described above. Because H(P,P) does handle this case the above
>>>> halting problem undecidable input template has been refuted.
>>>>
>>>> *When this halt deciding principle understood to be correct*
>>>> A halt decider must compute the mapping from its inputs to an
>>>> accept or reject state on the basis of the actual behavior that is
>>>> actually specified by these inputs.
>>>>
>>>> *Then (by logical necessity) this implements that principle*
>>>> Every simulating halt decider that correctly simulates its input
>>>> until it correctly predicts that this simulated input would never
>>>> terminate normally, correctly rejects this input as non-halting.
>>>>
>>>> *H is a Pure function*
>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>
>>>> thus implements a *Computable function*
>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>
>>>> Thus H is Turing computable.
>>>>
>>>> *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
>>>>
>>>
>>> You forgot to mention infinite recursion which I suppose is
>>> progress.
>>>
>>> /Flibble
>>>
>>
>> I have proved that H(P,P) == 0 is correct.
>>
>> I have shown that H/P does implement the HP's "impossible input"
>> template.
>>
>> Therefore I have refuted all of the halting problem proofs that rely
>> on this template.
>
> Equating pathological input with non-halting is erroneous: you are only
> doing that because your broken solution treats it as "infinite
> recursion". There is no recursion in [Strachey 1965] and the HP proofs
> based on it.
>
> /Flibble
>
There is no recursion in any of the conventional proofs only because no
one ever previously bothered to fully examine how a simulating halt
decider would address these otherwise "impossible" inputs.
I first addressed this here: comp.theory (more than five years ago)
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
Prior to this I made this discovery:
"It looks like the original specification provided in the Linz text may
be infinitely recursive in that each TM requires its own input."
In this Researchgate paper:
Self Modifying Turing Machine (SMTM) Solution to the Halting Problem
(concrete example) August 2016 (almost six years ago)
This revision that I made today is much simpler than all the rest:
*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.corp> |
|---|---|
| Date | 2022-07-14 23:30 +0100 |
| Message-ID | <20220714233028.00001007@reddwarf.jmc.corp> |
| In reply to | #85182 |
On Thu, 14 Jul 2022 16:02:35 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/14/2022 3:22 PM, Mr Flibble wrote:
> > On Thu, 14 Jul 2022 15:02:21 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/14/2022 2:28 PM, Mr Flibble wrote:
> >>> On Thu, 14 Jul 2022 14:19:38 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> This is an explanation of a key new insight into the halting
> >>>> problem provided in the language of software engineering.
> >>>> Technical computer science terms are explained using software
> >>>> engineering terms. No knowledge of the halting problem is
> >>>> required.
> >>>>
> >>>> It is based on fully operational software executed in the x86utm
> >>>> operating system. The x86utm operating system (based on an
> >>>> excellent open source x86 emulator) was created to study the
> >>>> details of the halting problem proof counter-examples at the much
> >>>> higher level of abstraction of C/x86.
> >>>>
> >>>> typedef void (*ptr)();
> >>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>
> >>>> void P(ptr x)
> >>>> {
> >>>> int Halt_Status = H(x, x);
> >>>> if (Halt_Status)
> >>>> HERE: goto HERE;
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H(P, P));
> >>>> }
> >>>>
> >>>> When simulating halt decider H(P,P) simulates its input we can
> >>>> see that: (1) Function H() is called from P().
> >>>> (2) With the same arguments to H().
> >>>> (3) With no instructions in P preceding its invocation of H(P,P).
> >>>>
> >>>> The above shows that the simulated P cannot possibly terminate
> >>>> normally. Because H can see the same (1)(2)(3) that we see H
> >>>> aborts its simulation of P and rejects P as non-halting.
> >>>>
> >>>> In computability theory, the halting problem is the
> >>>> problem of determining, from a description of an arbitrary
> >>>> computer program and an input, whether the program will finish
> >>>> running, or continue to run forever. Alan Turing proved in 1936
> >>>> that a general algorithm to solve the halting problem for all
> >>>> possible program- input pairs cannot exist.
> >>>>
> >>>> 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
> >>>>
> >>>> H and P implement the exact pathological relationship to each
> >>>> other as described above. Because H(P,P) does handle this case
> >>>> the above halting problem undecidable input template has been
> >>>> refuted.
> >>>>
> >>>> *When this halt deciding principle understood to be correct*
> >>>> A halt decider must compute the mapping from its inputs to an
> >>>> accept or reject state on the basis of the actual behavior that
> >>>> is actually specified by these inputs.
> >>>>
> >>>> *Then (by logical necessity) this implements that principle*
> >>>> Every simulating halt decider that correctly simulates its input
> >>>> until it correctly predicts that this simulated input would never
> >>>> terminate normally, correctly rejects this input as non-halting.
> >>>>
> >>>> *H is a Pure function*
> >>>> https://en.wikipedia.org/wiki/Pure_function
> >>>>
> >>>> thus implements a *Computable function*
> >>>> https://en.wikipedia.org/wiki/Computable_function
> >>>>
> >>>> Thus H is Turing computable.
> >>>>
> >>>> *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
> >>>>
> >>>
> >>> You forgot to mention infinite recursion which I suppose is
> >>> progress.
> >>>
> >>> /Flibble
> >>>
> >>
> >> I have proved that H(P,P) == 0 is correct.
> >>
> >> I have shown that H/P does implement the HP's "impossible input"
> >> template.
> >>
> >> Therefore I have refuted all of the halting problem proofs that
> >> rely on this template.
> >
> > Equating pathological input with non-halting is erroneous: you are
> > only doing that because your broken solution treats it as "infinite
> > recursion". There is no recursion in [Strachey 1965] and the HP
> > proofs based on it.
> >
> > /Flibble
> >
>
> There is no recursion in any of the conventional proofs only because
> no one ever previously bothered to fully examine how a simulating
> halt decider would address these otherwise "impossible" inputs.
I have shown that a simulating halt decider needn't be recursive in
nature:
https://github.com/i42output/halting-problem/blob/main/README.txt
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-14 17:41 -0500 |
| Message-ID | <9eKdnWguSIkeBk3_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #85198 |
On 7/14/2022 5:30 PM, Mr Flibble wrote:
> On Thu, 14 Jul 2022 16:02:35 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/14/2022 3:22 PM, Mr Flibble wrote:
>>> On Thu, 14 Jul 2022 15:02:21 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
>>>>> On Thu, 14 Jul 2022 14:19:38 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> This is an explanation of a key new insight into the halting
>>>>>> problem provided in the language of software engineering.
>>>>>> Technical computer science terms are explained using software
>>>>>> engineering terms. No knowledge of the halting problem is
>>>>>> required.
>>>>>>
>>>>>> It is based on fully operational software executed in the x86utm
>>>>>> operating system. The x86utm operating system (based on an
>>>>>> excellent open source x86 emulator) was created to study the
>>>>>> details of the halting problem proof counter-examples at the much
>>>>>> higher level of abstraction of C/x86.
>>>>>>
>>>>>> typedef void (*ptr)();
>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>
>>>>>> void P(ptr x)
>>>>>> {
>>>>>> int Halt_Status = H(x, x);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>> }
>>>>>>
>>>>>> When simulating halt decider H(P,P) simulates its input we can
>>>>>> see that: (1) Function H() is called from P().
>>>>>> (2) With the same arguments to H().
>>>>>> (3) With no instructions in P preceding its invocation of H(P,P).
>>>>>>
>>>>>> The above shows that the simulated P cannot possibly terminate
>>>>>> normally. Because H can see the same (1)(2)(3) that we see H
>>>>>> aborts its simulation of P and rejects P as non-halting.
>>>>>>
>>>>>> In computability theory, the halting problem is the
>>>>>> problem of determining, from a description of an arbitrary
>>>>>> computer program and an input, whether the program will finish
>>>>>> running, or continue to run forever. Alan Turing proved in 1936
>>>>>> that a general algorithm to solve the halting problem for all
>>>>>> possible program- input pairs cannot exist.
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> H and P implement the exact pathological relationship to each
>>>>>> other as described above. Because H(P,P) does handle this case
>>>>>> the above halting problem undecidable input template has been
>>>>>> refuted.
>>>>>>
>>>>>> *When this halt deciding principle understood to be correct*
>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>> accept or reject state on the basis of the actual behavior that
>>>>>> is actually specified by these inputs.
>>>>>>
>>>>>> *Then (by logical necessity) this implements that principle*
>>>>>> Every simulating halt decider that correctly simulates its input
>>>>>> until it correctly predicts that this simulated input would never
>>>>>> terminate normally, correctly rejects this input as non-halting.
>>>>>>
>>>>>> *H is a Pure function*
>>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>>
>>>>>> thus implements a *Computable function*
>>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>>
>>>>>> Thus H is Turing computable.
>>>>>>
>>>>>> *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
>>>>>>
>>>>>
>>>>> You forgot to mention infinite recursion which I suppose is
>>>>> progress.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> I have proved that H(P,P) == 0 is correct.
>>>>
>>>> I have shown that H/P does implement the HP's "impossible input"
>>>> template.
>>>>
>>>> Therefore I have refuted all of the halting problem proofs that
>>>> rely on this template.
>>>
>>> Equating pathological input with non-halting is erroneous: you are
>>> only doing that because your broken solution treats it as "infinite
>>> recursion". There is no recursion in [Strachey 1965] and the HP
>>> proofs based on it.
>>>
>>> /Flibble
>>>
>>
>> There is no recursion in any of the conventional proofs only because
>> no one ever previously bothered to fully examine how a simulating
>> halt decider would address these otherwise "impossible" inputs.
>
> I have shown that a simulating halt decider needn't be recursive in
> nature:
>
> https://github.com/i42output/halting-problem/blob/main/README.txt
>
> /Flibble
>
You sure do make it easy to review your work.
"When the simulator detects the call to H in P it forks
the simulation into a non-halting branch"
There is an infinite set of cases where this overly simplistic criteria
gets the wrong answer.
--
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.corp> |
|---|---|
| Date | 2022-07-15 07:23 +0100 |
| Message-ID | <20220715072333.00006b93@reddwarf.jmc.corp> |
| In reply to | #85200 |
On Thu, 14 Jul 2022 17:41:06 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/14/2022 5:30 PM, Mr Flibble wrote:
> > On Thu, 14 Jul 2022 16:02:35 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/14/2022 3:22 PM, Mr Flibble wrote:
> >>> On Thu, 14 Jul 2022 15:02:21 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
> >>>>> On Thu, 14 Jul 2022 14:19:38 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> This is an explanation of a key new insight into the halting
> >>>>>> problem provided in the language of software engineering.
> >>>>>> Technical computer science terms are explained using software
> >>>>>> engineering terms. No knowledge of the halting problem is
> >>>>>> required.
> >>>>>>
> >>>>>> It is based on fully operational software executed in the
> >>>>>> x86utm operating system. The x86utm operating system (based on
> >>>>>> an excellent open source x86 emulator) was created to study the
> >>>>>> details of the halting problem proof counter-examples at the
> >>>>>> much higher level of abstraction of C/x86.
> >>>>>>
> >>>>>> typedef void (*ptr)();
> >>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>
> >>>>>> void P(ptr x)
> >>>>>> {
> >>>>>> int Halt_Status = H(x, x);
> >>>>>> if (Halt_Status)
> >>>>>> HERE: goto HERE;
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>> }
> >>>>>>
> >>>>>> When simulating halt decider H(P,P) simulates its input we can
> >>>>>> see that: (1) Function H() is called from P().
> >>>>>> (2) With the same arguments to H().
> >>>>>> (3) With no instructions in P preceding its invocation of
> >>>>>> H(P,P).
> >>>>>>
> >>>>>> The above shows that the simulated P cannot possibly terminate
> >>>>>> normally. Because H can see the same (1)(2)(3) that we see H
> >>>>>> aborts its simulation of P and rejects P as non-halting.
> >>>>>>
> >>>>>> In computability theory, the halting problem is the
> >>>>>> problem of determining, from a description of an arbitrary
> >>>>>> computer program and an input, whether the program will finish
> >>>>>> running, or continue to run forever. Alan Turing proved in 1936
> >>>>>> that a general algorithm to solve the halting problem for all
> >>>>>> possible program- input pairs cannot exist.
> >>>>>>
> >>>>>> 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
> >>>>>>
> >>>>>> H and P implement the exact pathological relationship to each
> >>>>>> other as described above. Because H(P,P) does handle this case
> >>>>>> the above halting problem undecidable input template has been
> >>>>>> refuted.
> >>>>>>
> >>>>>> *When this halt deciding principle understood to be correct*
> >>>>>> A halt decider must compute the mapping from its inputs to an
> >>>>>> accept or reject state on the basis of the actual behavior that
> >>>>>> is actually specified by these inputs.
> >>>>>>
> >>>>>> *Then (by logical necessity) this implements that principle*
> >>>>>> Every simulating halt decider that correctly simulates its
> >>>>>> input until it correctly predicts that this simulated input
> >>>>>> would never terminate normally, correctly rejects this input
> >>>>>> as non-halting.
> >>>>>>
> >>>>>> *H is a Pure function*
> >>>>>> https://en.wikipedia.org/wiki/Pure_function
> >>>>>>
> >>>>>> thus implements a *Computable function*
> >>>>>> https://en.wikipedia.org/wiki/Computable_function
> >>>>>>
> >>>>>> Thus H is Turing computable.
> >>>>>>
> >>>>>> *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
> >>>>>>
> >>>>>
> >>>>> You forgot to mention infinite recursion which I suppose is
> >>>>> progress.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> I have proved that H(P,P) == 0 is correct.
> >>>>
> >>>> I have shown that H/P does implement the HP's "impossible input"
> >>>> template.
> >>>>
> >>>> Therefore I have refuted all of the halting problem proofs that
> >>>> rely on this template.
> >>>
> >>> Equating pathological input with non-halting is erroneous: you are
> >>> only doing that because your broken solution treats it as
> >>> "infinite recursion". There is no recursion in [Strachey 1965]
> >>> and the HP proofs based on it.
> >>>
> >>> /Flibble
> >>>
> >>
> >> There is no recursion in any of the conventional proofs only
> >> because no one ever previously bothered to fully examine how a
> >> simulating halt decider would address these otherwise "impossible"
> >> inputs.
> >
> > I have shown that a simulating halt decider needn't be recursive in
> > nature:
> >
> > https://github.com/i42output/halting-problem/blob/main/README.txt
> >
> > /Flibble
> >
>
> You sure do make it easy to review your work.
>
> "When the simulator detects the call to H in P it forks
> the simulation into a non-halting branch"
>
> There is an infinite set of cases where this overly simplistic
> criteria gets the wrong answer.
That is neither an honest review or any kind of rebuttal: I have told
you before: assertions made without evidence can be dismissed without
evidence.
If you claim there are an infinite number of cases where it gets the
wrong answer then it shouldn't be too hard for to provide ONE case
backing up your claim.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-15 01:46 -0500 |
| Message-ID | <F6SdnTz0ef3dkEz_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #85229 |
On 7/15/2022 1:23 AM, Mr Flibble wrote:
> On Thu, 14 Jul 2022 17:41:06 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/14/2022 5:30 PM, Mr Flibble wrote:
>>> On Thu, 14 Jul 2022 16:02:35 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/14/2022 3:22 PM, Mr Flibble wrote:
>>>>> On Thu, 14 Jul 2022 15:02:21 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
>>>>>>> On Thu, 14 Jul 2022 14:19:38 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> This is an explanation of a key new insight into the halting
>>>>>>>> problem provided in the language of software engineering.
>>>>>>>> Technical computer science terms are explained using software
>>>>>>>> engineering terms. No knowledge of the halting problem is
>>>>>>>> required.
>>>>>>>>
>>>>>>>> It is based on fully operational software executed in the
>>>>>>>> x86utm operating system. The x86utm operating system (based on
>>>>>>>> an excellent open source x86 emulator) was created to study the
>>>>>>>> details of the halting problem proof counter-examples at the
>>>>>>>> much higher level of abstraction of C/x86.
>>>>>>>>
>>>>>>>> typedef void (*ptr)();
>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>
>>>>>>>> void P(ptr x)
>>>>>>>> {
>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>> if (Halt_Status)
>>>>>>>> HERE: goto HERE;
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> When simulating halt decider H(P,P) simulates its input we can
>>>>>>>> see that: (1) Function H() is called from P().
>>>>>>>> (2) With the same arguments to H().
>>>>>>>> (3) With no instructions in P preceding its invocation of
>>>>>>>> H(P,P).
>>>>>>>>
>>>>>>>> The above shows that the simulated P cannot possibly terminate
>>>>>>>> normally. Because H can see the same (1)(2)(3) that we see H
>>>>>>>> aborts its simulation of P and rejects P as non-halting.
>>>>>>>>
>>>>>>>> In computability theory, the halting problem is the
>>>>>>>> problem of determining, from a description of an arbitrary
>>>>>>>> computer program and an input, whether the program will finish
>>>>>>>> running, or continue to run forever. Alan Turing proved in 1936
>>>>>>>> that a general algorithm to solve the halting problem for all
>>>>>>>> possible program- input pairs cannot exist.
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>> H and P implement the exact pathological relationship to each
>>>>>>>> other as described above. Because H(P,P) does handle this case
>>>>>>>> the above halting problem undecidable input template has been
>>>>>>>> refuted.
>>>>>>>>
>>>>>>>> *When this halt deciding principle understood to be correct*
>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>> accept or reject state on the basis of the actual behavior that
>>>>>>>> is actually specified by these inputs.
>>>>>>>>
>>>>>>>> *Then (by logical necessity) this implements that principle*
>>>>>>>> Every simulating halt decider that correctly simulates its
>>>>>>>> input until it correctly predicts that this simulated input
>>>>>>>> would never terminate normally, correctly rejects this input
>>>>>>>> as non-halting.
>>>>>>>>
>>>>>>>> *H is a Pure function*
>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>>>>
>>>>>>>> thus implements a *Computable function*
>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>>>>
>>>>>>>> Thus H is Turing computable.
>>>>>>>>
>>>>>>>> *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
>>>>>>>>
>>>>>>>
>>>>>>> You forgot to mention infinite recursion which I suppose is
>>>>>>> progress.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> I have proved that H(P,P) == 0 is correct.
>>>>>>
>>>>>> I have shown that H/P does implement the HP's "impossible input"
>>>>>> template.
>>>>>>
>>>>>> Therefore I have refuted all of the halting problem proofs that
>>>>>> rely on this template.
>>>>>
>>>>> Equating pathological input with non-halting is erroneous: you are
>>>>> only doing that because your broken solution treats it as
>>>>> "infinite recursion". There is no recursion in [Strachey 1965]
>>>>> and the HP proofs based on it.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> There is no recursion in any of the conventional proofs only
>>>> because no one ever previously bothered to fully examine how a
>>>> simulating halt decider would address these otherwise "impossible"
>>>> inputs.
>>>
>>> I have shown that a simulating halt decider needn't be recursive in
>>> nature:
>>>
>>> https://github.com/i42output/halting-problem/blob/main/README.txt
>>>
>>> /Flibble
>>>
>>
>> You sure do make it easy to review your work.
>>
>> "When the simulator detects the call to H in P it forks
>> the simulation into a non-halting branch"
>>
>> There is an infinite set of cases where this overly simplistic
>> criteria gets the wrong answer.
>
> That is neither an honest review or any kind of rebuttal: I have told
> you before: assertions made without evidence can be dismissed without
> evidence.
>
> If you claim there are an infinite number of cases where it gets the
> wrong answer then it shouldn't be too hard for to provide ONE case
> backing up your claim.
>
> /Flibble
>
Sure:
void P(ptr x)
{
static int count = 3;
count--;
if (!count) goto exit;
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
exit:
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
--
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-15 07:48 -0400 |
| Message-ID | <rucAK.472014$ntj.124254@fx15.iad> |
| In reply to | #85230 |
On 7/15/22 2:46 AM, olcott wrote:
> On 7/15/2022 1:23 AM, Mr Flibble wrote:
>> On Thu, 14 Jul 2022 17:41:06 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 7/14/2022 5:30 PM, Mr Flibble wrote:
>>>> On Thu, 14 Jul 2022 16:02:35 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 7/14/2022 3:22 PM, Mr Flibble wrote:
>>>>>> On Thu, 14 Jul 2022 15:02:21 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
>>>>>>>> On Thu, 14 Jul 2022 14:19:38 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> This is an explanation of a key new insight into the halting
>>>>>>>>> problem provided in the language of software engineering.
>>>>>>>>> Technical computer science terms are explained using software
>>>>>>>>> engineering terms. No knowledge of the halting problem is
>>>>>>>>> required.
>>>>>>>>>
>>>>>>>>> It is based on fully operational software executed in the
>>>>>>>>> x86utm operating system. The x86utm operating system (based on
>>>>>>>>> an excellent open source x86 emulator) was created to study the
>>>>>>>>> details of the halting problem proof counter-examples at the
>>>>>>>>> much higher level of abstraction of C/x86.
>>>>>>>>>
>>>>>>>>> typedef void (*ptr)();
>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>
>>>>>>>>> void P(ptr x)
>>>>>>>>> {
>>>>>>>>> Â Â Â Â Â Â int Halt_Status = H(x, x);
>>>>>>>>> Â Â Â Â Â Â if (Halt_Status)
>>>>>>>>> Â Â Â Â Â Â Â Â HERE: goto HERE;
>>>>>>>>> Â Â Â Â Â Â return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> Â Â Â Â Â Â Output("Input_Halts = ", H(P, P));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> When simulating halt decider H(P,P) simulates its input we can
>>>>>>>>> see that: (1) Function H() is called from P().
>>>>>>>>> (2) With the same arguments to H().
>>>>>>>>> (3) With no instructions in P preceding its invocation of
>>>>>>>>> H(P,P).
>>>>>>>>>
>>>>>>>>> The above shows that the simulated P cannot possibly terminate
>>>>>>>>> normally. Because H can see the same (1)(2)(3) that we see H
>>>>>>>>> aborts its simulation of P and rejects P as non-halting.
>>>>>>>>>
>>>>>>>>> Â Â Â Â Â Â Â Â Â In computability theory, the halting problem is the
>>>>>>>>> problem of determining, from a description of an arbitrary
>>>>>>>>> computer program and an input, whether the program will finish
>>>>>>>>> running, or continue to run forever. Alan Turing proved in 1936
>>>>>>>>> that a general algorithm to solve the halting problem for all
>>>>>>>>> possible program- input pairs cannot exist.
>>>>>>>>>
>>>>>>>>> Â Â Â Â Â Â Â Â Â 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
>>>>>>>>>
>>>>>>>>> H and P implement the exact pathological relationship to each
>>>>>>>>> other as described above. Because H(P,P) does handle this case
>>>>>>>>> the above halting problem undecidable input template has been
>>>>>>>>> refuted.
>>>>>>>>>
>>>>>>>>> *When this halt deciding principle understood to be correct*
>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>> accept or reject state on the basis of the actual behavior that
>>>>>>>>> is actually specified by these inputs.
>>>>>>>>>
>>>>>>>>> *Then (by logical necessity) this implements that principle*
>>>>>>>>> Every simulating halt decider that correctly simulates its
>>>>>>>>> input until it correctly predicts that this simulated input
>>>>>>>>> would never terminate normally, correctly rejects this input
>>>>>>>>> as non-halting.
>>>>>>>>>
>>>>>>>>> *H is a Pure function*
>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>>>>>
>>>>>>>>> thus implements a *Computable function*
>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>>>>>
>>>>>>>>> Thus H is Turing computable.
>>>>>>>>>
>>>>>>>>> *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
>>>>>>>>>
>>>>>>>>
>>>>>>>> You forgot to mention infinite recursion which I suppose is
>>>>>>>> progress.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> I have proved that H(P,P) == 0 is correct.
>>>>>>>
>>>>>>> I have shown that H/P does implement the HP's "impossible input"
>>>>>>> template.
>>>>>>>
>>>>>>> Therefore I have refuted all of the halting problem proofs that
>>>>>>> rely on this template.
>>>>>> Equating pathological input with non-halting is erroneous: you are
>>>>>> only doing that because your broken solution treats it as
>>>>>> "infinite recursion". There is no recursion in [Strachey 1965]
>>>>>> and the HP proofs based on it.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> There is no recursion in any of the conventional proofs only
>>>>> because no one ever previously bothered to fully examine how a
>>>>> simulating halt decider would address these otherwise "impossible"
>>>>> inputs.
>>>>
>>>> I have shown that a simulating halt decider needn't be recursive in
>>>> nature:
>>>>
>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
>>>>
>>>> /Flibble
>>>
>>> You sure do make it easy to review your work.
>>>
>>> Â Â Â "When the simulator detects the call to H in P it forks
>>> Â Â Â Â the simulation into a non-halting branch"
>>>
>>> There is an infinite set of cases where this overly simplistic
>>> criteria gets the wrong answer.
>>
>> That is neither an honest review or any kind of rebuttal: I have told
>> you before: assertions made without evidence can be dismissed without
>> evidence.
>>
>> If you claim there are an infinite number of cases where it gets the
>> wrong answer then it shouldn't be too hard for to provide ONE case
>> backing up your claim.
>>
>> /Flibble
>>
> Sure:
>
> void P(ptr x)
> {
> static int count = 3;
> Â count--;
> Â if (!count) goto exit;
> Â int Halt_Status = H(x, x);
> Â if (Halt_Status)
> Â Â Â HERE: goto HERE;
> exit:
> Â return;
> }
>
> int main()
> {
> Â Output("Input_Halts = ", H(P, P));
> }
>
>
I thought that program was illegal in your system as your system didn't
allow the use of static memory?
Note, P isn't a pure function, as there is a variable that affects it
that isn't an actual defined input.
Note, properly per a real definition of what a Halt Decider should do,
the H(P,P) needs to create a BRAND NEW instance of P to simulate, just
like starting a new program, so that P has ITS OWN copy of count, that
has been initialized to 3.
Remember, you have defined H to SIMULATE its input, which means that its
input is ISOLATED from the current environment, so it shouldn't be
accessing the count from the calling routine.
That is violating the concept of what is a computation.
Of course, you just don't understand ANY of that, which is why you think
you have actually acheived something when you haven't.
Remember, in the C context, Halting Deciders work on PROGRAMS, as
complete entities, because C functions don't represent represent the
Mathematical function BECAUSE they can cross communicate in ways that
aren't allowed.
WHen you try to translate that above code into a Turing Machine, you
will find out that if H sctually is a Turing Machine, based on using a
modified UTM to decide, the the P that the H will simulate will start
with its own value of count starting at 3.
Since P NEVER calls P, the first decrement from 3 to 2 is the ONLY
change in value that count will have.
H isn't allowed to access it to let its copy of P that it is simulating
to affect it.
You are just PROVING that you H isn't actually a Pure Function, as its
behavior is shown to be a changed by things other than its direct
parameters.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-07-15 13:06 +0100 |
| Message-ID | <20220715130620.0000483f@reddwarf.jmc.corp> |
| In reply to | #85230 |
On Fri, 15 Jul 2022 01:46:23 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/15/2022 1:23 AM, Mr Flibble wrote:
> > On Thu, 14 Jul 2022 17:41:06 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/14/2022 5:30 PM, Mr Flibble wrote:
> >>> On Thu, 14 Jul 2022 16:02:35 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 7/14/2022 3:22 PM, Mr Flibble wrote:
> >>>>> On Thu, 14 Jul 2022 15:02:21 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
> >>>>>>> On Thu, 14 Jul 2022 14:19:38 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> This is an explanation of a key new insight into the halting
> >>>>>>>> problem provided in the language of software engineering.
> >>>>>>>> Technical computer science terms are explained using software
> >>>>>>>> engineering terms. No knowledge of the halting problem is
> >>>>>>>> required.
> >>>>>>>>
> >>>>>>>> It is based on fully operational software executed in the
> >>>>>>>> x86utm operating system. The x86utm operating system (based
> >>>>>>>> on an excellent open source x86 emulator) was created to
> >>>>>>>> study the details of the halting problem proof
> >>>>>>>> counter-examples at the much higher level of abstraction of
> >>>>>>>> C/x86.
> >>>>>>>>
> >>>>>>>> typedef void (*ptr)();
> >>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>
> >>>>>>>> void P(ptr x)
> >>>>>>>> {
> >>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>> if (Halt_Status)
> >>>>>>>> HERE: goto HERE;
> >>>>>>>> return;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> int main()
> >>>>>>>> {
> >>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> When simulating halt decider H(P,P) simulates its input we
> >>>>>>>> can see that: (1) Function H() is called from P().
> >>>>>>>> (2) With the same arguments to H().
> >>>>>>>> (3) With no instructions in P preceding its invocation of
> >>>>>>>> H(P,P).
> >>>>>>>>
> >>>>>>>> The above shows that the simulated P cannot possibly
> >>>>>>>> terminate normally. Because H can see the same (1)(2)(3)
> >>>>>>>> that we see H aborts its simulation of P and rejects P as
> >>>>>>>> non-halting.
> >>>>>>>>
> >>>>>>>> In computability theory, the halting problem is the
> >>>>>>>> problem of determining, from a description of an arbitrary
> >>>>>>>> computer program and an input, whether the program will
> >>>>>>>> finish running, or continue to run forever. Alan Turing
> >>>>>>>> proved in 1936 that a general algorithm to solve the halting
> >>>>>>>> problem for all possible program- input pairs cannot exist.
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>>
> >>>>>>>> H and P implement the exact pathological relationship to each
> >>>>>>>> other as described above. Because H(P,P) does handle this
> >>>>>>>> case the above halting problem undecidable input template
> >>>>>>>> has been refuted.
> >>>>>>>>
> >>>>>>>> *When this halt deciding principle understood to be correct*
> >>>>>>>> A halt decider must compute the mapping from its inputs to an
> >>>>>>>> accept or reject state on the basis of the actual behavior
> >>>>>>>> that is actually specified by these inputs.
> >>>>>>>>
> >>>>>>>> *Then (by logical necessity) this implements that principle*
> >>>>>>>> Every simulating halt decider that correctly simulates its
> >>>>>>>> input until it correctly predicts that this simulated input
> >>>>>>>> would never terminate normally, correctly rejects this input
> >>>>>>>> as non-halting.
> >>>>>>>>
> >>>>>>>> *H is a Pure function*
> >>>>>>>> https://en.wikipedia.org/wiki/Pure_function
> >>>>>>>>
> >>>>>>>> thus implements a *Computable function*
> >>>>>>>> https://en.wikipedia.org/wiki/Computable_function
> >>>>>>>>
> >>>>>>>> Thus H is Turing computable.
> >>>>>>>>
> >>>>>>>> *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
> >>>>>>>>
> >>>>>>>
> >>>>>>> You forgot to mention infinite recursion which I suppose is
> >>>>>>> progress.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> I have proved that H(P,P) == 0 is correct.
> >>>>>>
> >>>>>> I have shown that H/P does implement the HP's "impossible
> >>>>>> input" template.
> >>>>>>
> >>>>>> Therefore I have refuted all of the halting problem proofs that
> >>>>>> rely on this template.
> >>>>>
> >>>>> Equating pathological input with non-halting is erroneous: you
> >>>>> are only doing that because your broken solution treats it as
> >>>>> "infinite recursion". There is no recursion in [Strachey 1965]
> >>>>> and the HP proofs based on it.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> There is no recursion in any of the conventional proofs only
> >>>> because no one ever previously bothered to fully examine how a
> >>>> simulating halt decider would address these otherwise
> >>>> "impossible" inputs.
> >>>
> >>> I have shown that a simulating halt decider needn't be recursive
> >>> in nature:
> >>>
> >>> https://github.com/i42output/halting-problem/blob/main/README.txt
> >>>
> >>> /Flibble
> >>>
> >>
> >> You sure do make it easy to review your work.
> >>
> >> "When the simulator detects the call to H in P it forks
> >> the simulation into a non-halting branch"
> >>
> >> There is an infinite set of cases where this overly simplistic
> >> criteria gets the wrong answer.
> >
> > That is neither an honest review or any kind of rebuttal: I have
> > told you before: assertions made without evidence can be dismissed
> > without evidence.
> >
> > If you claim there are an infinite number of cases where it gets the
> > wrong answer then it shouldn't be too hard for to provide ONE case
> > backing up your claim.
> >
> > /Flibble
> >
> Sure:
>
> void P(ptr x)
> {
> static int count = 3;
> count--;
> if (!count) goto exit;
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> exit:
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
Nope; you seem to have forgotten that my decider is not recursive in
nature: my decider will correctly determine that that input is
pathological so will signal an exception.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-15 09:19 -0500 |
| Message-ID | <esudnY0OB8EN6kz_nZ2dnUU7_81j4p2d@giganews.com> |
| In reply to | #85235 |
On 7/15/2022 7:06 AM, Mr Flibble wrote:
> On Fri, 15 Jul 2022 01:46:23 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/15/2022 1:23 AM, Mr Flibble wrote:
>>> On Thu, 14 Jul 2022 17:41:06 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/14/2022 5:30 PM, Mr Flibble wrote:
>>>>> On Thu, 14 Jul 2022 16:02:35 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 7/14/2022 3:22 PM, Mr Flibble wrote:
>>>>>>> On Thu, 14 Jul 2022 15:02:21 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
>>>>>>>>> On Thu, 14 Jul 2022 14:19:38 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> This is an explanation of a key new insight into the halting
>>>>>>>>>> problem provided in the language of software engineering.
>>>>>>>>>> Technical computer science terms are explained using software
>>>>>>>>>> engineering terms. No knowledge of the halting problem is
>>>>>>>>>> required.
>>>>>>>>>>
>>>>>>>>>> It is based on fully operational software executed in the
>>>>>>>>>> x86utm operating system. The x86utm operating system (based
>>>>>>>>>> on an excellent open source x86 emulator) was created to
>>>>>>>>>> study the details of the halting problem proof
>>>>>>>>>> counter-examples at the much higher level of abstraction of
>>>>>>>>>> C/x86.
>>>>>>>>>>
>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>> if (Halt_Status)
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> When simulating halt decider H(P,P) simulates its input we
>>>>>>>>>> can see that: (1) Function H() is called from P().
>>>>>>>>>> (2) With the same arguments to H().
>>>>>>>>>> (3) With no instructions in P preceding its invocation of
>>>>>>>>>> H(P,P).
>>>>>>>>>>
>>>>>>>>>> The above shows that the simulated P cannot possibly
>>>>>>>>>> terminate normally. Because H can see the same (1)(2)(3)
>>>>>>>>>> that we see H aborts its simulation of P and rejects P as
>>>>>>>>>> non-halting.
>>>>>>>>>>
>>>>>>>>>> In computability theory, the halting problem is the
>>>>>>>>>> problem of determining, from a description of an arbitrary
>>>>>>>>>> computer program and an input, whether the program will
>>>>>>>>>> finish running, or continue to run forever. Alan Turing
>>>>>>>>>> proved in 1936 that a general algorithm to solve the halting
>>>>>>>>>> problem for all possible program- input pairs cannot exist.
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> H and P implement the exact pathological relationship to each
>>>>>>>>>> other as described above. Because H(P,P) does handle this
>>>>>>>>>> case the above halting problem undecidable input template
>>>>>>>>>> has been refuted.
>>>>>>>>>>
>>>>>>>>>> *When this halt deciding principle understood to be correct*
>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>> accept or reject state on the basis of the actual behavior
>>>>>>>>>> that is actually specified by these inputs.
>>>>>>>>>>
>>>>>>>>>> *Then (by logical necessity) this implements that principle*
>>>>>>>>>> Every simulating halt decider that correctly simulates its
>>>>>>>>>> input until it correctly predicts that this simulated input
>>>>>>>>>> would never terminate normally, correctly rejects this input
>>>>>>>>>> as non-halting.
>>>>>>>>>>
>>>>>>>>>> *H is a Pure function*
>>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>>>>>>
>>>>>>>>>> thus implements a *Computable function*
>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>>>>>>
>>>>>>>>>> Thus H is Turing computable.
>>>>>>>>>>
>>>>>>>>>> *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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You forgot to mention infinite recursion which I suppose is
>>>>>>>>> progress.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> I have proved that H(P,P) == 0 is correct.
>>>>>>>>
>>>>>>>> I have shown that H/P does implement the HP's "impossible
>>>>>>>> input" template.
>>>>>>>>
>>>>>>>> Therefore I have refuted all of the halting problem proofs that
>>>>>>>> rely on this template.
>>>>>>>
>>>>>>> Equating pathological input with non-halting is erroneous: you
>>>>>>> are only doing that because your broken solution treats it as
>>>>>>> "infinite recursion". There is no recursion in [Strachey 1965]
>>>>>>> and the HP proofs based on it.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> There is no recursion in any of the conventional proofs only
>>>>>> because no one ever previously bothered to fully examine how a
>>>>>> simulating halt decider would address these otherwise
>>>>>> "impossible" inputs.
>>>>>
>>>>> I have shown that a simulating halt decider needn't be recursive
>>>>> in nature:
>>>>>
>>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> You sure do make it easy to review your work.
>>>>
>>>> "When the simulator detects the call to H in P it forks
>>>> the simulation into a non-halting branch"
>>>>
>>>> There is an infinite set of cases where this overly simplistic
>>>> criteria gets the wrong answer.
>>>
>>> That is neither an honest review or any kind of rebuttal: I have
>>> told you before: assertions made without evidence can be dismissed
>>> without evidence.
>>>
>>> If you claim there are an infinite number of cases where it gets the
>>> wrong answer then it shouldn't be too hard for to provide ONE case
>>> backing up your claim.
>>>
>>> /Flibble
>>>
>> Sure:
>>
>> void P(ptr x)
>> {
>> static int count = 3;
>> count--;
>> if (!count) goto exit;
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> exit:
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(P, P));
>> }
>
> Nope; you seem to have forgotten that my decider is not recursive in
> nature: my decider will correctly determine that that input is
> pathological so will signal an exception.
>
> /Flibble
>
>
The above terminates normally so your decider gets the wrong answer.
--
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.corp> |
|---|---|
| Date | 2022-07-15 15:32 +0100 |
| Message-ID | <20220715153211.00005430@reddwarf.jmc.corp> |
| In reply to | #85239 |
On Fri, 15 Jul 2022 09:19:59 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/15/2022 7:06 AM, Mr Flibble wrote:
> > On Fri, 15 Jul 2022 01:46:23 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/15/2022 1:23 AM, Mr Flibble wrote:
> >>> On Thu, 14 Jul 2022 17:41:06 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 7/14/2022 5:30 PM, Mr Flibble wrote:
> >>>>> On Thu, 14 Jul 2022 16:02:35 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 7/14/2022 3:22 PM, Mr Flibble wrote:
> >>>>>>> On Thu, 14 Jul 2022 15:02:21 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
> >>>>>>>>> On Thu, 14 Jul 2022 14:19:38 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> This is an explanation of a key new insight into the
> >>>>>>>>>> halting problem provided in the language of software
> >>>>>>>>>> engineering. Technical computer science terms are
> >>>>>>>>>> explained using software engineering terms. No knowledge
> >>>>>>>>>> of the halting problem is required.
> >>>>>>>>>>
> >>>>>>>>>> It is based on fully operational software executed in the
> >>>>>>>>>> x86utm operating system. The x86utm operating system (based
> >>>>>>>>>> on an excellent open source x86 emulator) was created to
> >>>>>>>>>> study the details of the halting problem proof
> >>>>>>>>>> counter-examples at the much higher level of abstraction of
> >>>>>>>>>> C/x86.
> >>>>>>>>>>
> >>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>
> >>>>>>>>>> void P(ptr x)
> >>>>>>>>>> {
> >>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>> if (Halt_Status)
> >>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>> return;
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> int main()
> >>>>>>>>>> {
> >>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> When simulating halt decider H(P,P) simulates its input we
> >>>>>>>>>> can see that: (1) Function H() is called from P().
> >>>>>>>>>> (2) With the same arguments to H().
> >>>>>>>>>> (3) With no instructions in P preceding its invocation of
> >>>>>>>>>> H(P,P).
> >>>>>>>>>>
> >>>>>>>>>> The above shows that the simulated P cannot possibly
> >>>>>>>>>> terminate normally. Because H can see the same (1)(2)(3)
> >>>>>>>>>> that we see H aborts its simulation of P and rejects P as
> >>>>>>>>>> non-halting.
> >>>>>>>>>>
> >>>>>>>>>> In computability theory, the halting problem is
> >>>>>>>>>> the problem of determining, from a description of an
> >>>>>>>>>> arbitrary computer program and an input, whether the
> >>>>>>>>>> program will finish running, or continue to run forever.
> >>>>>>>>>> Alan Turing proved in 1936 that a general algorithm to
> >>>>>>>>>> solve the halting problem for all possible program- input
> >>>>>>>>>> pairs cannot exist.
> >>>>>>>>>>
> >>>>>>>>>> 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
> >>>>>>>>>>
> >>>>>>>>>> H and P implement the exact pathological relationship to
> >>>>>>>>>> each other as described above. Because H(P,P) does handle
> >>>>>>>>>> this case the above halting problem undecidable input
> >>>>>>>>>> template has been refuted.
> >>>>>>>>>>
> >>>>>>>>>> *When this halt deciding principle understood to be
> >>>>>>>>>> correct* A halt decider must compute the mapping from its
> >>>>>>>>>> inputs to an accept or reject state on the basis of the
> >>>>>>>>>> actual behavior that is actually specified by these inputs.
> >>>>>>>>>>
> >>>>>>>>>> *Then (by logical necessity) this implements that
> >>>>>>>>>> principle* Every simulating halt decider that correctly
> >>>>>>>>>> simulates its input until it correctly predicts that this
> >>>>>>>>>> simulated input would never terminate normally, correctly
> >>>>>>>>>> rejects this input as non-halting.
> >>>>>>>>>>
> >>>>>>>>>> *H is a Pure function*
> >>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
> >>>>>>>>>>
> >>>>>>>>>> thus implements a *Computable function*
> >>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
> >>>>>>>>>>
> >>>>>>>>>> Thus H is Turing computable.
> >>>>>>>>>>
> >>>>>>>>>> *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
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> You forgot to mention infinite recursion which I suppose is
> >>>>>>>>> progress.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I have proved that H(P,P) == 0 is correct.
> >>>>>>>>
> >>>>>>>> I have shown that H/P does implement the HP's "impossible
> >>>>>>>> input" template.
> >>>>>>>>
> >>>>>>>> Therefore I have refuted all of the halting problem proofs
> >>>>>>>> that rely on this template.
> >>>>>>>
> >>>>>>> Equating pathological input with non-halting is erroneous: you
> >>>>>>> are only doing that because your broken solution treats it as
> >>>>>>> "infinite recursion". There is no recursion in [Strachey
> >>>>>>> 1965] and the HP proofs based on it.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> There is no recursion in any of the conventional proofs only
> >>>>>> because no one ever previously bothered to fully examine how a
> >>>>>> simulating halt decider would address these otherwise
> >>>>>> "impossible" inputs.
> >>>>>
> >>>>> I have shown that a simulating halt decider needn't be recursive
> >>>>> in nature:
> >>>>>
> >>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> You sure do make it easy to review your work.
> >>>>
> >>>> "When the simulator detects the call to H in P it forks
> >>>> the simulation into a non-halting branch"
> >>>>
> >>>> There is an infinite set of cases where this overly simplistic
> >>>> criteria gets the wrong answer.
> >>>
> >>> That is neither an honest review or any kind of rebuttal: I have
> >>> told you before: assertions made without evidence can be dismissed
> >>> without evidence.
> >>>
> >>> If you claim there are an infinite number of cases where it gets
> >>> the wrong answer then it shouldn't be too hard for to provide ONE
> >>> case backing up your claim.
> >>>
> >>> /Flibble
> >>>
> >> Sure:
> >>
> >> void P(ptr x)
> >> {
> >> static int count = 3;
> >> count--;
> >> if (!count) goto exit;
> >> int Halt_Status = H(x, x);
> >> if (Halt_Status)
> >> HERE: goto HERE;
> >> exit:
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H(P, P));
> >> }
> >
> > Nope; you seem to have forgotten that my decider is not recursive in
> > nature: my decider will correctly determine that that input is
> > pathological so will signal an exception.
> >
> > /Flibble
> >
> >
>
> The above terminates normally so your decider gets the wrong answer.
It is a pathological input so neither halts nor doesn't halt:
pathological input is INVALID so the correct "answer" is to signal an
exception.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-15 10:07 -0500 |
| Message-ID | <JeidnSoS1rskH0z_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #85241 |
On 7/15/2022 9:32 AM, Mr Flibble wrote:
> On Fri, 15 Jul 2022 09:19:59 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/15/2022 7:06 AM, Mr Flibble wrote:
>>> On Fri, 15 Jul 2022 01:46:23 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/15/2022 1:23 AM, Mr Flibble wrote:
>>>>> On Thu, 14 Jul 2022 17:41:06 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 7/14/2022 5:30 PM, Mr Flibble wrote:
>>>>>>> On Thu, 14 Jul 2022 16:02:35 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 7/14/2022 3:22 PM, Mr Flibble wrote:
>>>>>>>>> On Thu, 14 Jul 2022 15:02:21 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
>>>>>>>>>>> On Thu, 14 Jul 2022 14:19:38 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> This is an explanation of a key new insight into the
>>>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>>>> engineering. Technical computer science terms are
>>>>>>>>>>>> explained using software engineering terms. No knowledge
>>>>>>>>>>>> of the halting problem is required.
>>>>>>>>>>>>
>>>>>>>>>>>> It is based on fully operational software executed in the
>>>>>>>>>>>> x86utm operating system. The x86utm operating system (based
>>>>>>>>>>>> on an excellent open source x86 emulator) was created to
>>>>>>>>>>>> study the details of the halting problem proof
>>>>>>>>>>>> counter-examples at the much higher level of abstraction of
>>>>>>>>>>>> C/x86.
>>>>>>>>>>>>
>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>
>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>> {
>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> When simulating halt decider H(P,P) simulates its input we
>>>>>>>>>>>> can see that: (1) Function H() is called from P().
>>>>>>>>>>>> (2) With the same arguments to H().
>>>>>>>>>>>> (3) With no instructions in P preceding its invocation of
>>>>>>>>>>>> H(P,P).
>>>>>>>>>>>>
>>>>>>>>>>>> The above shows that the simulated P cannot possibly
>>>>>>>>>>>> terminate normally. Because H can see the same (1)(2)(3)
>>>>>>>>>>>> that we see H aborts its simulation of P and rejects P as
>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>
>>>>>>>>>>>> In computability theory, the halting problem is
>>>>>>>>>>>> the problem of determining, from a description of an
>>>>>>>>>>>> arbitrary computer program and an input, whether the
>>>>>>>>>>>> program will finish running, or continue to run forever.
>>>>>>>>>>>> Alan Turing proved in 1936 that a general algorithm to
>>>>>>>>>>>> solve the halting problem for all possible program- input
>>>>>>>>>>>> pairs cannot exist.
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>> H and P implement the exact pathological relationship to
>>>>>>>>>>>> each other as described above. Because H(P,P) does handle
>>>>>>>>>>>> this case the above halting problem undecidable input
>>>>>>>>>>>> template has been refuted.
>>>>>>>>>>>>
>>>>>>>>>>>> *When this halt deciding principle understood to be
>>>>>>>>>>>> correct* A halt decider must compute the mapping from its
>>>>>>>>>>>> inputs to an accept or reject state on the basis of the
>>>>>>>>>>>> actual behavior that is actually specified by these inputs.
>>>>>>>>>>>>
>>>>>>>>>>>> *Then (by logical necessity) this implements that
>>>>>>>>>>>> principle* Every simulating halt decider that correctly
>>>>>>>>>>>> simulates its input until it correctly predicts that this
>>>>>>>>>>>> simulated input would never terminate normally, correctly
>>>>>>>>>>>> rejects this input as non-halting.
>>>>>>>>>>>>
>>>>>>>>>>>> *H is a Pure function*
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>>>>>>>>
>>>>>>>>>>>> thus implements a *Computable function*
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>>>>>>>>
>>>>>>>>>>>> Thus H is Turing computable.
>>>>>>>>>>>>
>>>>>>>>>>>> *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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You forgot to mention infinite recursion which I suppose is
>>>>>>>>>>> progress.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have proved that H(P,P) == 0 is correct.
>>>>>>>>>>
>>>>>>>>>> I have shown that H/P does implement the HP's "impossible
>>>>>>>>>> input" template.
>>>>>>>>>>
>>>>>>>>>> Therefore I have refuted all of the halting problem proofs
>>>>>>>>>> that rely on this template.
>>>>>>>>>
>>>>>>>>> Equating pathological input with non-halting is erroneous: you
>>>>>>>>> are only doing that because your broken solution treats it as
>>>>>>>>> "infinite recursion". There is no recursion in [Strachey
>>>>>>>>> 1965] and the HP proofs based on it.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> There is no recursion in any of the conventional proofs only
>>>>>>>> because no one ever previously bothered to fully examine how a
>>>>>>>> simulating halt decider would address these otherwise
>>>>>>>> "impossible" inputs.
>>>>>>>
>>>>>>> I have shown that a simulating halt decider needn't be recursive
>>>>>>> in nature:
>>>>>>>
>>>>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> You sure do make it easy to review your work.
>>>>>>
>>>>>> "When the simulator detects the call to H in P it forks
>>>>>> the simulation into a non-halting branch"
>>>>>>
>>>>>> There is an infinite set of cases where this overly simplistic
>>>>>> criteria gets the wrong answer.
>>>>>
>>>>> That is neither an honest review or any kind of rebuttal: I have
>>>>> told you before: assertions made without evidence can be dismissed
>>>>> without evidence.
>>>>>
>>>>> If you claim there are an infinite number of cases where it gets
>>>>> the wrong answer then it shouldn't be too hard for to provide ONE
>>>>> case backing up your claim.
>>>>>
>>>>> /Flibble
>>>>>
>>>> Sure:
>>>>
>>>> void P(ptr x)
>>>> {
>>>> static int count = 3;
>>>> count--;
>>>> if (!count) goto exit;
>>>> int Halt_Status = H(x, x);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> exit:
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H(P, P));
>>>> }
>>>
>>> Nope; you seem to have forgotten that my decider is not recursive in
>>> nature: my decider will correctly determine that that input is
>>> pathological so will signal an exception.
>>>
>>> /Flibble
>>>
>>>
>>
>> The above terminates normally so your decider gets the wrong answer.
>
> It is a pathological input so neither halts nor doesn't halt:
> pathological input is INVALID so the correct "answer" is to signal an
> exception.
>
> /Flibble
>
So you don't know how static variables work?
I am not surprised.
void P(ptr x)
{
static int count = 0;
if (count++ >= 2) goto exit;
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
exit:
return;
}
int main()
{
Output("Input_Halts = ", H(P,P));
}
_Pm()
[0000141e](01) 55 push ebp
[0000141f](02) 8bec mov ebp,esp
[00001421](03) 83ec08 sub esp,+08
[00001424](05) a100000000 mov eax,[00000000]
[00001429](03) 8945fc mov [ebp-04],eax
[0000142c](06) 8b0d00000000 mov ecx,[00000000]
[00001432](03) 83c101 add ecx,+01
[00001435](06) 890d00000000 mov [00000000],ecx
[0000143b](04) 837dfc02 cmp dword [ebp-04],+02
[0000143f](02) 7c02 jl 00001443
[00001441](02) eb1b jmp 0000145e
[00001443](03) 8b5508 mov edx,[ebp+08]
[00001446](01) 52 push edx
[00001447](03) 8b4508 mov eax,[ebp+08]
[0000144a](01) 50 push eax
[0000144b](05) e8defcffff call 0000112e
[00001450](03) 83c408 add esp,+08
[00001453](03) 8945f8 mov [ebp-08],eax
[00001456](04) 837df800 cmp dword [ebp-08],+00
[0000145a](02) 7402 jz 0000145e
[0000145c](02) ebfe jmp 0000145c
[0000145e](02) 8be5 mov esp,ebp
[00001460](01) 5d pop ebp
[00001461](01) c3 ret
Size in bytes:(0068) [00001461]
_main()
[0000146e](01) 55 push ebp
[0000146f](02) 8bec mov ebp,esp
[00001471](05) 681e140000 push 0000141e
[00001476](05) 681e140000 push 0000141e
[0000147b](05) e8aefcffff call 0000112e
[00001480](03) 83c408 add esp,+08
[00001483](01) 50 push eax
[00001484](05) 685f050000 push 0000055f
[00001489](05) e820f1ffff call 000005ae
[0000148e](03) 83c408 add esp,+08
[00001491](02) 33c0 xor eax,eax
[00001493](01) 5d pop ebp
[00001494](01) c3 ret
Size in bytes:(0039) [00001494]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[0000146e][00102462][00000000] 55 push ebp
[0000146f][00102462][00000000] 8bec mov ebp,esp
[00001471][0010245e][0000141e] 681e140000 push 0000141e
[00001476][0010245a][0000141e] 681e140000 push 0000141e
[0000147b][00102456][00001480] e8aefcffff call 0000112e
H: Begin Simulation Execution Trace Stored at:11250e
Address_of_H:112e
[0000141e][001124fa][001124fe] 55 push ebp
[0000141f][001124fa][001124fe] 8bec mov ebp,esp
[00001421][001124f2][90909090] 83ec08 sub esp,+08
[00001424][001124f2][90909090] a100000000 mov eax,[00000000]
[00001429][001124f2][90909090] 8945fc mov [ebp-04],eax
[0000142c][001124f2][90909090] 8b0d00000000 mov ecx,[00000000]
[00001432][001124f2][90909090] 83c101 add ecx,+01
[00001435][001124f2][90909090] 890d00000000 mov [00000000],ecx
[0000143b][001124f2][90909090] 837dfc02 cmp dword [ebp-04],+02
[0000143f][001124f2][90909090] 7c02 jl 00001443
[00001441][001124f2][90909090] eb1b jmp 0000145e
[0000145e][001124fa][001124fe] 8be5 mov esp,ebp
[00001460][001124fe][00001217] 5d pop ebp
[00001461][00112502][0000141e] c3 ret
H: End Simulation Input Terminated Normally
[00001480][00102462][00000000] 83c408 add esp,+08
[00001483][0010245e][00000001] 50 push eax
[00001484][0010245a][0000055f] 685f050000 push 0000055f
[00001489][0010245a][0000055f] e820f1ffff call 000005ae
Input_Halts = 1
[0000148e][00102462][00000000] 83c408 add esp,+08
[00001491][00102462][00000000] 33c0 xor eax,eax
[00001493][00102466][00000018] 5d pop ebp
[00001494][0010246a][00000000] c3 ret
Number of Instructions Executed(1317) == 20 Pages
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-07-15 16:18 +0100 |
| Message-ID | <20220715161850.00003456@reddwarf.jmc.corp> |
| In reply to | #85242 |
On Fri, 15 Jul 2022 10:07:36 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/15/2022 9:32 AM, Mr Flibble wrote:
> > On Fri, 15 Jul 2022 09:19:59 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/15/2022 7:06 AM, Mr Flibble wrote:
> >>> On Fri, 15 Jul 2022 01:46:23 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 7/15/2022 1:23 AM, Mr Flibble wrote:
> >>>>> On Thu, 14 Jul 2022 17:41:06 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 7/14/2022 5:30 PM, Mr Flibble wrote:
> >>>>>>> On Thu, 14 Jul 2022 16:02:35 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 7/14/2022 3:22 PM, Mr Flibble wrote:
> >>>>>>>>> On Thu, 14 Jul 2022 15:02:21 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Thu, 14 Jul 2022 14:19:38 -0500
> >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> This is an explanation of a key new insight into the
> >>>>>>>>>>>> halting problem provided in the language of software
> >>>>>>>>>>>> engineering. Technical computer science terms are
> >>>>>>>>>>>> explained using software engineering terms. No knowledge
> >>>>>>>>>>>> of the halting problem is required.
> >>>>>>>>>>>>
> >>>>>>>>>>>> It is based on fully operational software executed in the
> >>>>>>>>>>>> x86utm operating system. The x86utm operating system
> >>>>>>>>>>>> (based on an excellent open source x86 emulator) was
> >>>>>>>>>>>> created to study the details of the halting problem proof
> >>>>>>>>>>>> counter-examples at the much higher level of abstraction
> >>>>>>>>>>>> of C/x86.
> >>>>>>>>>>>>
> >>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>
> >>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>> {
> >>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>> return;
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> int main()
> >>>>>>>>>>>> {
> >>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> When simulating halt decider H(P,P) simulates its input
> >>>>>>>>>>>> we can see that: (1) Function H() is called from P().
> >>>>>>>>>>>> (2) With the same arguments to H().
> >>>>>>>>>>>> (3) With no instructions in P preceding its invocation of
> >>>>>>>>>>>> H(P,P).
> >>>>>>>>>>>>
> >>>>>>>>>>>> The above shows that the simulated P cannot possibly
> >>>>>>>>>>>> terminate normally. Because H can see the same (1)(2)(3)
> >>>>>>>>>>>> that we see H aborts its simulation of P and rejects P as
> >>>>>>>>>>>> non-halting.
> >>>>>>>>>>>>
> >>>>>>>>>>>> In computability theory, the halting problem
> >>>>>>>>>>>> is the problem of determining, from a description of an
> >>>>>>>>>>>> arbitrary computer program and an input, whether the
> >>>>>>>>>>>> program will finish running, or continue to run forever.
> >>>>>>>>>>>> Alan Turing proved in 1936 that a general algorithm to
> >>>>>>>>>>>> solve the halting problem for all possible program- input
> >>>>>>>>>>>> pairs cannot exist.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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
> >>>>>>>>>>>>
> >>>>>>>>>>>> H and P implement the exact pathological relationship to
> >>>>>>>>>>>> each other as described above. Because H(P,P) does handle
> >>>>>>>>>>>> this case the above halting problem undecidable input
> >>>>>>>>>>>> template has been refuted.
> >>>>>>>>>>>>
> >>>>>>>>>>>> *When this halt deciding principle understood to be
> >>>>>>>>>>>> correct* A halt decider must compute the mapping from its
> >>>>>>>>>>>> inputs to an accept or reject state on the basis of the
> >>>>>>>>>>>> actual behavior that is actually specified by these
> >>>>>>>>>>>> inputs.
> >>>>>>>>>>>>
> >>>>>>>>>>>> *Then (by logical necessity) this implements that
> >>>>>>>>>>>> principle* Every simulating halt decider that correctly
> >>>>>>>>>>>> simulates its input until it correctly predicts that this
> >>>>>>>>>>>> simulated input would never terminate normally, correctly
> >>>>>>>>>>>> rejects this input as non-halting.
> >>>>>>>>>>>>
> >>>>>>>>>>>> *H is a Pure function*
> >>>>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
> >>>>>>>>>>>>
> >>>>>>>>>>>> thus implements a *Computable function*
> >>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thus H is Turing computable.
> >>>>>>>>>>>>
> >>>>>>>>>>>> *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
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> You forgot to mention infinite recursion which I suppose
> >>>>>>>>>>> is progress.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I have proved that H(P,P) == 0 is correct.
> >>>>>>>>>>
> >>>>>>>>>> I have shown that H/P does implement the HP's "impossible
> >>>>>>>>>> input" template.
> >>>>>>>>>>
> >>>>>>>>>> Therefore I have refuted all of the halting problem proofs
> >>>>>>>>>> that rely on this template.
> >>>>>>>>>
> >>>>>>>>> Equating pathological input with non-halting is erroneous:
> >>>>>>>>> you are only doing that because your broken solution treats
> >>>>>>>>> it as "infinite recursion". There is no recursion in
> >>>>>>>>> [Strachey 1965] and the HP proofs based on it.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> There is no recursion in any of the conventional proofs only
> >>>>>>>> because no one ever previously bothered to fully examine how
> >>>>>>>> a simulating halt decider would address these otherwise
> >>>>>>>> "impossible" inputs.
> >>>>>>>
> >>>>>>> I have shown that a simulating halt decider needn't be
> >>>>>>> recursive in nature:
> >>>>>>>
> >>>>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> You sure do make it easy to review your work.
> >>>>>>
> >>>>>> "When the simulator detects the call to H in P it forks
> >>>>>> the simulation into a non-halting branch"
> >>>>>>
> >>>>>> There is an infinite set of cases where this overly simplistic
> >>>>>> criteria gets the wrong answer.
> >>>>>
> >>>>> That is neither an honest review or any kind of rebuttal: I have
> >>>>> told you before: assertions made without evidence can be
> >>>>> dismissed without evidence.
> >>>>>
> >>>>> If you claim there are an infinite number of cases where it gets
> >>>>> the wrong answer then it shouldn't be too hard for to provide
> >>>>> ONE case backing up your claim.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>> Sure:
> >>>>
> >>>> void P(ptr x)
> >>>> {
> >>>> static int count = 3;
> >>>> count--;
> >>>> if (!count) goto exit;
> >>>> int Halt_Status = H(x, x);
> >>>> if (Halt_Status)
> >>>> HERE: goto HERE;
> >>>> exit:
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H(P, P));
> >>>> }
> >>>
> >>> Nope; you seem to have forgotten that my decider is not recursive
> >>> in nature: my decider will correctly determine that that input is
> >>> pathological so will signal an exception.
> >>>
> >>> /Flibble
> >>>
> >>>
> >>
> >> The above terminates normally so your decider gets the wrong
> >> answer.
> >
> > It is a pathological input so neither halts nor doesn't halt:
> > pathological input is INVALID so the correct "answer" is to signal
> > an exception.
> >
> > /Flibble
> >
>
> So you don't know how static variables work?
> I am not surprised.
Of course I know how static variables work: in this case the static
variable is initialised to 3 when P is first entered and then
decremented however P is *not* called again as my decider is not
recursive so its value will stay at 2 and never reach zero meaning the
input is always pathological.
>
>
> void P(ptr x)
> {
> static int count = 0;
> if (count++ >= 2) goto exit;
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> exit:
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P,P));
> }
>
> _Pm()
> [0000141e](01) 55 push ebp
> [0000141f](02) 8bec mov ebp,esp
> [00001421](03) 83ec08 sub esp,+08
> [00001424](05) a100000000 mov eax,[00000000]
> [00001429](03) 8945fc mov [ebp-04],eax
> [0000142c](06) 8b0d00000000 mov ecx,[00000000]
> [00001432](03) 83c101 add ecx,+01
> [00001435](06) 890d00000000 mov [00000000],ecx
> [0000143b](04) 837dfc02 cmp dword [ebp-04],+02
> [0000143f](02) 7c02 jl 00001443
> [00001441](02) eb1b jmp 0000145e
> [00001443](03) 8b5508 mov edx,[ebp+08]
> [00001446](01) 52 push edx
> [00001447](03) 8b4508 mov eax,[ebp+08]
> [0000144a](01) 50 push eax
> [0000144b](05) e8defcffff call 0000112e
> [00001450](03) 83c408 add esp,+08
> [00001453](03) 8945f8 mov [ebp-08],eax
> [00001456](04) 837df800 cmp dword [ebp-08],+00
> [0000145a](02) 7402 jz 0000145e
> [0000145c](02) ebfe jmp 0000145c
> [0000145e](02) 8be5 mov esp,ebp
> [00001460](01) 5d pop ebp
> [00001461](01) c3 ret
> Size in bytes:(0068) [00001461]
>
> _main()
> [0000146e](01) 55 push ebp
> [0000146f](02) 8bec mov ebp,esp
> [00001471](05) 681e140000 push 0000141e
> [00001476](05) 681e140000 push 0000141e
> [0000147b](05) e8aefcffff call 0000112e
> [00001480](03) 83c408 add esp,+08
> [00001483](01) 50 push eax
> [00001484](05) 685f050000 push 0000055f
> [00001489](05) e820f1ffff call 000005ae
> [0000148e](03) 83c408 add esp,+08
> [00001491](02) 33c0 xor eax,eax
> [00001493](01) 5d pop ebp
> [00001494](01) c3 ret
> Size in bytes:(0039) [00001494]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [0000146e][00102462][00000000] 55 push ebp
> [0000146f][00102462][00000000] 8bec mov ebp,esp
> [00001471][0010245e][0000141e] 681e140000 push 0000141e
> [00001476][0010245a][0000141e] 681e140000 push 0000141e
> [0000147b][00102456][00001480] e8aefcffff call 0000112e
>
> H: Begin Simulation Execution Trace Stored at:11250e
> Address_of_H:112e
> [0000141e][001124fa][001124fe] 55 push ebp
> [0000141f][001124fa][001124fe] 8bec mov ebp,esp
> [00001421][001124f2][90909090] 83ec08 sub esp,+08
> [00001424][001124f2][90909090] a100000000 mov eax,[00000000]
> [00001429][001124f2][90909090] 8945fc mov [ebp-04],eax
> [0000142c][001124f2][90909090] 8b0d00000000 mov ecx,[00000000]
> [00001432][001124f2][90909090] 83c101 add ecx,+01
> [00001435][001124f2][90909090] 890d00000000 mov [00000000],ecx
> [0000143b][001124f2][90909090] 837dfc02 cmp dword [ebp-04],+02
> [0000143f][001124f2][90909090] 7c02 jl 00001443
> [00001441][001124f2][90909090] eb1b jmp 0000145e
> [0000145e][001124fa][001124fe] 8be5 mov esp,ebp
> [00001460][001124fe][00001217] 5d pop ebp
> [00001461][00112502][0000141e] c3 ret
> H: End Simulation Input Terminated Normally
>
> [00001480][00102462][00000000] 83c408 add esp,+08
> [00001483][0010245e][00000001] 50 push eax
> [00001484][0010245a][0000055f] 685f050000 push 0000055f
> [00001489][0010245a][0000055f] e820f1ffff call 000005ae
> Input_Halts = 1
> [0000148e][00102462][00000000] 83c408 add esp,+08
> [00001491][00102462][00000000] 33c0 xor eax,eax
> [00001493][00102466][00000018] 5d pop ebp
> [00001494][0010246a][00000000] c3 ret
> Number of Instructions Executed(1317) == 20 Pages
This is a different P that also is also always pathological in nature
which means your H is getting the answer wrong.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-15 10:27 -0500 |
| Message-ID | <-P6dnXy9_obVGkz_nZ2dnUU7_81j4p2d@giganews.com> |
| In reply to | #85243 |
On 7/15/2022 10:18 AM, Mr Flibble wrote:
> On Fri, 15 Jul 2022 10:07:36 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/15/2022 9:32 AM, Mr Flibble wrote:
>>> On Fri, 15 Jul 2022 09:19:59 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/15/2022 7:06 AM, Mr Flibble wrote:
>>>>> On Fri, 15 Jul 2022 01:46:23 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 7/15/2022 1:23 AM, Mr Flibble wrote:
>>>>>>> On Thu, 14 Jul 2022 17:41:06 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 7/14/2022 5:30 PM, Mr Flibble wrote:
>>>>>>>>> On Thu, 14 Jul 2022 16:02:35 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 7/14/2022 3:22 PM, Mr Flibble wrote:
>>>>>>>>>>> On Thu, 14 Jul 2022 15:02:21 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Thu, 14 Jul 2022 14:19:38 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is an explanation of a key new insight into the
>>>>>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>>>>>> engineering. Technical computer science terms are
>>>>>>>>>>>>>> explained using software engineering terms. No knowledge
>>>>>>>>>>>>>> of the halting problem is required.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is based on fully operational software executed in the
>>>>>>>>>>>>>> x86utm operating system. The x86utm operating system
>>>>>>>>>>>>>> (based on an excellent open source x86 emulator) was
>>>>>>>>>>>>>> created to study the details of the halting problem proof
>>>>>>>>>>>>>> counter-examples at the much higher level of abstraction
>>>>>>>>>>>>>> of C/x86.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When simulating halt decider H(P,P) simulates its input
>>>>>>>>>>>>>> we can see that: (1) Function H() is called from P().
>>>>>>>>>>>>>> (2) With the same arguments to H().
>>>>>>>>>>>>>> (3) With no instructions in P preceding its invocation of
>>>>>>>>>>>>>> H(P,P).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The above shows that the simulated P cannot possibly
>>>>>>>>>>>>>> terminate normally. Because H can see the same (1)(2)(3)
>>>>>>>>>>>>>> that we see H aborts its simulation of P and rejects P as
>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In computability theory, the halting problem
>>>>>>>>>>>>>> is the problem of determining, from a description of an
>>>>>>>>>>>>>> arbitrary computer program and an input, whether the
>>>>>>>>>>>>>> program will finish running, or continue to run forever.
>>>>>>>>>>>>>> Alan Turing proved in 1936 that a general algorithm to
>>>>>>>>>>>>>> solve the halting problem for all possible program- input
>>>>>>>>>>>>>> pairs cannot exist.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H and P implement the exact pathological relationship to
>>>>>>>>>>>>>> each other as described above. Because H(P,P) does handle
>>>>>>>>>>>>>> this case the above halting problem undecidable input
>>>>>>>>>>>>>> template has been refuted.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *When this halt deciding principle understood to be
>>>>>>>>>>>>>> correct* A halt decider must compute the mapping from its
>>>>>>>>>>>>>> inputs to an accept or reject state on the basis of the
>>>>>>>>>>>>>> actual behavior that is actually specified by these
>>>>>>>>>>>>>> inputs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Then (by logical necessity) this implements that
>>>>>>>>>>>>>> principle* Every simulating halt decider that correctly
>>>>>>>>>>>>>> simulates its input until it correctly predicts that this
>>>>>>>>>>>>>> simulated input would never terminate normally, correctly
>>>>>>>>>>>>>> rejects this input as non-halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *H is a Pure function*
>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thus implements a *Computable function*
>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thus H is Turing computable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You forgot to mention infinite recursion which I suppose
>>>>>>>>>>>>> is progress.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I have proved that H(P,P) == 0 is correct.
>>>>>>>>>>>>
>>>>>>>>>>>> I have shown that H/P does implement the HP's "impossible
>>>>>>>>>>>> input" template.
>>>>>>>>>>>>
>>>>>>>>>>>> Therefore I have refuted all of the halting problem proofs
>>>>>>>>>>>> that rely on this template.
>>>>>>>>>>>
>>>>>>>>>>> Equating pathological input with non-halting is erroneous:
>>>>>>>>>>> you are only doing that because your broken solution treats
>>>>>>>>>>> it as "infinite recursion". There is no recursion in
>>>>>>>>>>> [Strachey 1965] and the HP proofs based on it.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> There is no recursion in any of the conventional proofs only
>>>>>>>>>> because no one ever previously bothered to fully examine how
>>>>>>>>>> a simulating halt decider would address these otherwise
>>>>>>>>>> "impossible" inputs.
>>>>>>>>>
>>>>>>>>> I have shown that a simulating halt decider needn't be
>>>>>>>>> recursive in nature:
>>>>>>>>>
>>>>>>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> You sure do make it easy to review your work.
>>>>>>>>
>>>>>>>> "When the simulator detects the call to H in P it forks
>>>>>>>> the simulation into a non-halting branch"
>>>>>>>>
>>>>>>>> There is an infinite set of cases where this overly simplistic
>>>>>>>> criteria gets the wrong answer.
>>>>>>>
>>>>>>> That is neither an honest review or any kind of rebuttal: I have
>>>>>>> told you before: assertions made without evidence can be
>>>>>>> dismissed without evidence.
>>>>>>>
>>>>>>> If you claim there are an infinite number of cases where it gets
>>>>>>> the wrong answer then it shouldn't be too hard for to provide
>>>>>>> ONE case backing up your claim.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>> Sure:
>>>>>>
>>>>>> void P(ptr x)
>>>>>> {
>>>>>> static int count = 3;
>>>>>> count--;
>>>>>> if (!count) goto exit;
>>>>>> int Halt_Status = H(x, x);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> exit:
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>> }
>>>>>
>>>>> Nope; you seem to have forgotten that my decider is not recursive
>>>>> in nature: my decider will correctly determine that that input is
>>>>> pathological so will signal an exception.
>>>>>
>>>>> /Flibble
>>>>>
>>>>>
>>>>
>>>> The above terminates normally so your decider gets the wrong
>>>> answer.
>>>
>>> It is a pathological input so neither halts nor doesn't halt:
>>> pathological input is INVALID so the correct "answer" is to signal
>>> an exception.
>>>
>>> /Flibble
>>>
>>
>> So you don't know how static variables work?
>> I am not surprised.
>
> Of course I know how static variables work: in this case the static
> variable is initialised to 3 when P is first entered and then
> decremented however P is *not* called again as my decider is not
> recursive so its value will stay at 2 and never reach zero meaning the
> input is always pathological.
>
Yet the actual behavior of the correct simulation of this input proves
that it halts. So although it is pathological this does not prevent its
halt status from being correctly determined.
>>
>>
>> void P(ptr x)
>> {
>> static int count = 0;
>> if (count++ >= 2) goto exit;
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> exit:
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(P,P));
>> }
>>
>> _Pm()
>> [0000141e](01) 55 push ebp
>> [0000141f](02) 8bec mov ebp,esp
>> [00001421](03) 83ec08 sub esp,+08
>> [00001424](05) a100000000 mov eax,[00000000]
>> [00001429](03) 8945fc mov [ebp-04],eax
>> [0000142c](06) 8b0d00000000 mov ecx,[00000000]
>> [00001432](03) 83c101 add ecx,+01
>> [00001435](06) 890d00000000 mov [00000000],ecx
>> [0000143b](04) 837dfc02 cmp dword [ebp-04],+02
>> [0000143f](02) 7c02 jl 00001443
>> [00001441](02) eb1b jmp 0000145e
>> [00001443](03) 8b5508 mov edx,[ebp+08]
>> [00001446](01) 52 push edx
>> [00001447](03) 8b4508 mov eax,[ebp+08]
>> [0000144a](01) 50 push eax
>> [0000144b](05) e8defcffff call 0000112e
>> [00001450](03) 83c408 add esp,+08
>> [00001453](03) 8945f8 mov [ebp-08],eax
>> [00001456](04) 837df800 cmp dword [ebp-08],+00
>> [0000145a](02) 7402 jz 0000145e
>> [0000145c](02) ebfe jmp 0000145c
>> [0000145e](02) 8be5 mov esp,ebp
>> [00001460](01) 5d pop ebp
>> [00001461](01) c3 ret
>> Size in bytes:(0068) [00001461]
>>
>> _main()
>> [0000146e](01) 55 push ebp
>> [0000146f](02) 8bec mov ebp,esp
>> [00001471](05) 681e140000 push 0000141e
>> [00001476](05) 681e140000 push 0000141e
>> [0000147b](05) e8aefcffff call 0000112e
>> [00001480](03) 83c408 add esp,+08
>> [00001483](01) 50 push eax
>> [00001484](05) 685f050000 push 0000055f
>> [00001489](05) e820f1ffff call 000005ae
>> [0000148e](03) 83c408 add esp,+08
>> [00001491](02) 33c0 xor eax,eax
>> [00001493](01) 5d pop ebp
>> [00001494](01) c3 ret
>> Size in bytes:(0039) [00001494]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [0000146e][00102462][00000000] 55 push ebp
>> [0000146f][00102462][00000000] 8bec mov ebp,esp
>> [00001471][0010245e][0000141e] 681e140000 push 0000141e
>> [00001476][0010245a][0000141e] 681e140000 push 0000141e
>> [0000147b][00102456][00001480] e8aefcffff call 0000112e
>>
>> H: Begin Simulation Execution Trace Stored at:11250e
>> Address_of_H:112e
>> [0000141e][001124fa][001124fe] 55 push ebp
>> [0000141f][001124fa][001124fe] 8bec mov ebp,esp
>> [00001421][001124f2][90909090] 83ec08 sub esp,+08
>> [00001424][001124f2][90909090] a100000000 mov eax,[00000000]
>> [00001429][001124f2][90909090] 8945fc mov [ebp-04],eax
>> [0000142c][001124f2][90909090] 8b0d00000000 mov ecx,[00000000]
>> [00001432][001124f2][90909090] 83c101 add ecx,+01
>> [00001435][001124f2][90909090] 890d00000000 mov [00000000],ecx
>> [0000143b][001124f2][90909090] 837dfc02 cmp dword [ebp-04],+02
>> [0000143f][001124f2][90909090] 7c02 jl 00001443
>> [00001441][001124f2][90909090] eb1b jmp 0000145e
>> [0000145e][001124fa][001124fe] 8be5 mov esp,ebp
>> [00001460][001124fe][00001217] 5d pop ebp
>> [00001461][00112502][0000141e] c3 ret
>> H: End Simulation Input Terminated Normally
>>
>> [00001480][00102462][00000000] 83c408 add esp,+08
>> [00001483][0010245e][00000001] 50 push eax
>> [00001484][0010245a][0000055f] 685f050000 push 0000055f
>> [00001489][0010245a][0000055f] e820f1ffff call 000005ae
>> Input_Halts = 1
>> [0000148e][00102462][00000000] 83c408 add esp,+08
>> [00001491][00102462][00000000] 33c0 xor eax,eax
>> [00001493][00102466][00000018] 5d pop ebp
>> [00001494][0010246a][00000000] c3 ret
>> Number of Instructions Executed(1317) == 20 Pages
>
> This is a different P that also is also always pathological in nature
> which means your H is getting the answer wrong.
>
> /Flibble
>
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-07-15 16:29 +0100 |
| Message-ID | <20220715162937.00000d4a@reddwarf.jmc.corp> |
| In reply to | #85244 |
On Fri, 15 Jul 2022 10:27:04 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/15/2022 10:18 AM, Mr Flibble wrote:
> > On Fri, 15 Jul 2022 10:07:36 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/15/2022 9:32 AM, Mr Flibble wrote:
> >>> On Fri, 15 Jul 2022 09:19:59 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 7/15/2022 7:06 AM, Mr Flibble wrote:
> >>>>> On Fri, 15 Jul 2022 01:46:23 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 7/15/2022 1:23 AM, Mr Flibble wrote:
> >>>>>>> On Thu, 14 Jul 2022 17:41:06 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 7/14/2022 5:30 PM, Mr Flibble wrote:
> >>>>>>>>> On Thu, 14 Jul 2022 16:02:35 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 7/14/2022 3:22 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Thu, 14 Jul 2022 15:02:21 -0500
> >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Thu, 14 Jul 2022 14:19:38 -0500
> >>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> This is an explanation of a key new insight into the
> >>>>>>>>>>>>>> halting problem provided in the language of software
> >>>>>>>>>>>>>> engineering. Technical computer science terms are
> >>>>>>>>>>>>>> explained using software engineering terms. No
> >>>>>>>>>>>>>> knowledge of the halting problem is required.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It is based on fully operational software executed in
> >>>>>>>>>>>>>> the x86utm operating system. The x86utm operating
> >>>>>>>>>>>>>> system (based on an excellent open source x86
> >>>>>>>>>>>>>> emulator) was created to study the details of the
> >>>>>>>>>>>>>> halting problem proof counter-examples at the much
> >>>>>>>>>>>>>> higher level of abstraction of C/x86.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> When simulating halt decider H(P,P) simulates its input
> >>>>>>>>>>>>>> we can see that: (1) Function H() is called from P().
> >>>>>>>>>>>>>> (2) With the same arguments to H().
> >>>>>>>>>>>>>> (3) With no instructions in P preceding its invocation
> >>>>>>>>>>>>>> of H(P,P).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The above shows that the simulated P cannot possibly
> >>>>>>>>>>>>>> terminate normally. Because H can see the same
> >>>>>>>>>>>>>> (1)(2)(3) that we see H aborts its simulation of P and
> >>>>>>>>>>>>>> rejects P as non-halting.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> In computability theory, the halting
> >>>>>>>>>>>>>> problem is the problem of determining, from a
> >>>>>>>>>>>>>> description of an arbitrary computer program and an
> >>>>>>>>>>>>>> input, whether the program will finish running, or
> >>>>>>>>>>>>>> continue to run forever. Alan Turing proved in 1936
> >>>>>>>>>>>>>> that a general algorithm to solve the halting problem
> >>>>>>>>>>>>>> for all possible program- input pairs cannot exist.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> H and P implement the exact pathological relationship
> >>>>>>>>>>>>>> to each other as described above. Because H(P,P) does
> >>>>>>>>>>>>>> handle this case the above halting problem undecidable
> >>>>>>>>>>>>>> input template has been refuted.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> *When this halt deciding principle understood to be
> >>>>>>>>>>>>>> correct* A halt decider must compute the mapping from
> >>>>>>>>>>>>>> its inputs to an accept or reject state on the basis
> >>>>>>>>>>>>>> of the actual behavior that is actually specified by
> >>>>>>>>>>>>>> these inputs.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> *Then (by logical necessity) this implements that
> >>>>>>>>>>>>>> principle* Every simulating halt decider that correctly
> >>>>>>>>>>>>>> simulates its input until it correctly predicts that
> >>>>>>>>>>>>>> this simulated input would never terminate normally,
> >>>>>>>>>>>>>> correctly rejects this input as non-halting.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> *H is a Pure function*
> >>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> thus implements a *Computable function*
> >>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thus H is Turing computable.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> *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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> You forgot to mention infinite recursion which I suppose
> >>>>>>>>>>>>> is progress.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I have proved that H(P,P) == 0 is correct.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I have shown that H/P does implement the HP's "impossible
> >>>>>>>>>>>> input" template.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Therefore I have refuted all of the halting problem
> >>>>>>>>>>>> proofs that rely on this template.
> >>>>>>>>>>>
> >>>>>>>>>>> Equating pathological input with non-halting is erroneous:
> >>>>>>>>>>> you are only doing that because your broken solution
> >>>>>>>>>>> treats it as "infinite recursion". There is no recursion
> >>>>>>>>>>> in [Strachey 1965] and the HP proofs based on it.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> There is no recursion in any of the conventional proofs
> >>>>>>>>>> only because no one ever previously bothered to fully
> >>>>>>>>>> examine how a simulating halt decider would address these
> >>>>>>>>>> otherwise "impossible" inputs.
> >>>>>>>>>
> >>>>>>>>> I have shown that a simulating halt decider needn't be
> >>>>>>>>> recursive in nature:
> >>>>>>>>>
> >>>>>>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> You sure do make it easy to review your work.
> >>>>>>>>
> >>>>>>>> "When the simulator detects the call to H in P it
> >>>>>>>> forks the simulation into a non-halting branch"
> >>>>>>>>
> >>>>>>>> There is an infinite set of cases where this overly
> >>>>>>>> simplistic criteria gets the wrong answer.
> >>>>>>>
> >>>>>>> That is neither an honest review or any kind of rebuttal: I
> >>>>>>> have told you before: assertions made without evidence can be
> >>>>>>> dismissed without evidence.
> >>>>>>>
> >>>>>>> If you claim there are an infinite number of cases where it
> >>>>>>> gets the wrong answer then it shouldn't be too hard for to
> >>>>>>> provide ONE case backing up your claim.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>> Sure:
> >>>>>>
> >>>>>> void P(ptr x)
> >>>>>> {
> >>>>>> static int count = 3;
> >>>>>> count--;
> >>>>>> if (!count) goto exit;
> >>>>>> int Halt_Status = H(x, x);
> >>>>>> if (Halt_Status)
> >>>>>> HERE: goto HERE;
> >>>>>> exit:
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>> }
> >>>>>
> >>>>> Nope; you seem to have forgotten that my decider is not
> >>>>> recursive in nature: my decider will correctly determine that
> >>>>> that input is pathological so will signal an exception.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>>
> >>>>
> >>>> The above terminates normally so your decider gets the wrong
> >>>> answer.
> >>>
> >>> It is a pathological input so neither halts nor doesn't halt:
> >>> pathological input is INVALID so the correct "answer" is to signal
> >>> an exception.
> >>>
> >>> /Flibble
> >>>
> >>
> >> So you don't know how static variables work?
> >> I am not surprised.
> >
> > Of course I know how static variables work: in this case the static
> > variable is initialised to 3 when P is first entered and then
> > decremented however P is *not* called again as my decider is not
> > recursive so its value will stay at 2 and never reach zero meaning
> > the input is always pathological.
> >
>
> Yet the actual behavior of the correct simulation of this input
> proves that it halts. So although it is pathological this does not
> prevent its halt status from being correctly determined.
No, this input is pathological in nature, i.e. a [Strachey 1965]
"impossible program" so to say it halts is incorrect.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-07-15 16:49 +0100 |
| Message-ID | <20220715164900.00006bca@reddwarf.jmc.corp> |
| In reply to | #85242 |
On Fri, 15 Jul 2022 10:07:36 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/15/2022 9:32 AM, Mr Flibble wrote:
> > On Fri, 15 Jul 2022 09:19:59 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/15/2022 7:06 AM, Mr Flibble wrote:
> >>> On Fri, 15 Jul 2022 01:46:23 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 7/15/2022 1:23 AM, Mr Flibble wrote:
> >>>>> On Thu, 14 Jul 2022 17:41:06 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 7/14/2022 5:30 PM, Mr Flibble wrote:
> >>>>>>> On Thu, 14 Jul 2022 16:02:35 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 7/14/2022 3:22 PM, Mr Flibble wrote:
> >>>>>>>>> On Thu, 14 Jul 2022 15:02:21 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Thu, 14 Jul 2022 14:19:38 -0500
> >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> This is an explanation of a key new insight into the
> >>>>>>>>>>>> halting problem provided in the language of software
> >>>>>>>>>>>> engineering. Technical computer science terms are
> >>>>>>>>>>>> explained using software engineering terms. No knowledge
> >>>>>>>>>>>> of the halting problem is required.
> >>>>>>>>>>>>
> >>>>>>>>>>>> It is based on fully operational software executed in the
> >>>>>>>>>>>> x86utm operating system. The x86utm operating system
> >>>>>>>>>>>> (based on an excellent open source x86 emulator) was
> >>>>>>>>>>>> created to study the details of the halting problem proof
> >>>>>>>>>>>> counter-examples at the much higher level of abstraction
> >>>>>>>>>>>> of C/x86.
> >>>>>>>>>>>>
> >>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>
> >>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>> {
> >>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>> return;
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> int main()
> >>>>>>>>>>>> {
> >>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> When simulating halt decider H(P,P) simulates its input
> >>>>>>>>>>>> we can see that: (1) Function H() is called from P().
> >>>>>>>>>>>> (2) With the same arguments to H().
> >>>>>>>>>>>> (3) With no instructions in P preceding its invocation of
> >>>>>>>>>>>> H(P,P).
> >>>>>>>>>>>>
> >>>>>>>>>>>> The above shows that the simulated P cannot possibly
> >>>>>>>>>>>> terminate normally. Because H can see the same (1)(2)(3)
> >>>>>>>>>>>> that we see H aborts its simulation of P and rejects P as
> >>>>>>>>>>>> non-halting.
> >>>>>>>>>>>>
> >>>>>>>>>>>> In computability theory, the halting problem
> >>>>>>>>>>>> is the problem of determining, from a description of an
> >>>>>>>>>>>> arbitrary computer program and an input, whether the
> >>>>>>>>>>>> program will finish running, or continue to run forever.
> >>>>>>>>>>>> Alan Turing proved in 1936 that a general algorithm to
> >>>>>>>>>>>> solve the halting problem for all possible program- input
> >>>>>>>>>>>> pairs cannot exist.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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
> >>>>>>>>>>>>
> >>>>>>>>>>>> H and P implement the exact pathological relationship to
> >>>>>>>>>>>> each other as described above. Because H(P,P) does handle
> >>>>>>>>>>>> this case the above halting problem undecidable input
> >>>>>>>>>>>> template has been refuted.
> >>>>>>>>>>>>
> >>>>>>>>>>>> *When this halt deciding principle understood to be
> >>>>>>>>>>>> correct* A halt decider must compute the mapping from its
> >>>>>>>>>>>> inputs to an accept or reject state on the basis of the
> >>>>>>>>>>>> actual behavior that is actually specified by these
> >>>>>>>>>>>> inputs.
> >>>>>>>>>>>>
> >>>>>>>>>>>> *Then (by logical necessity) this implements that
> >>>>>>>>>>>> principle* Every simulating halt decider that correctly
> >>>>>>>>>>>> simulates its input until it correctly predicts that this
> >>>>>>>>>>>> simulated input would never terminate normally, correctly
> >>>>>>>>>>>> rejects this input as non-halting.
> >>>>>>>>>>>>
> >>>>>>>>>>>> *H is a Pure function*
> >>>>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
> >>>>>>>>>>>>
> >>>>>>>>>>>> thus implements a *Computable function*
> >>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thus H is Turing computable.
> >>>>>>>>>>>>
> >>>>>>>>>>>> *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
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> You forgot to mention infinite recursion which I suppose
> >>>>>>>>>>> is progress.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I have proved that H(P,P) == 0 is correct.
> >>>>>>>>>>
> >>>>>>>>>> I have shown that H/P does implement the HP's "impossible
> >>>>>>>>>> input" template.
> >>>>>>>>>>
> >>>>>>>>>> Therefore I have refuted all of the halting problem proofs
> >>>>>>>>>> that rely on this template.
> >>>>>>>>>
> >>>>>>>>> Equating pathological input with non-halting is erroneous:
> >>>>>>>>> you are only doing that because your broken solution treats
> >>>>>>>>> it as "infinite recursion". There is no recursion in
> >>>>>>>>> [Strachey 1965] and the HP proofs based on it.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> There is no recursion in any of the conventional proofs only
> >>>>>>>> because no one ever previously bothered to fully examine how
> >>>>>>>> a simulating halt decider would address these otherwise
> >>>>>>>> "impossible" inputs.
> >>>>>>>
> >>>>>>> I have shown that a simulating halt decider needn't be
> >>>>>>> recursive in nature:
> >>>>>>>
> >>>>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> You sure do make it easy to review your work.
> >>>>>>
> >>>>>> "When the simulator detects the call to H in P it forks
> >>>>>> the simulation into a non-halting branch"
> >>>>>>
> >>>>>> There is an infinite set of cases where this overly simplistic
> >>>>>> criteria gets the wrong answer.
> >>>>>
> >>>>> That is neither an honest review or any kind of rebuttal: I have
> >>>>> told you before: assertions made without evidence can be
> >>>>> dismissed without evidence.
> >>>>>
> >>>>> If you claim there are an infinite number of cases where it gets
> >>>>> the wrong answer then it shouldn't be too hard for to provide
> >>>>> ONE case backing up your claim.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>> Sure:
> >>>>
> >>>> void P(ptr x)
> >>>> {
> >>>> static int count = 3;
> >>>> count--;
> >>>> if (!count) goto exit;
> >>>> int Halt_Status = H(x, x);
> >>>> if (Halt_Status)
> >>>> HERE: goto HERE;
> >>>> exit:
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H(P, P));
> >>>> }
> >>>
> >>> Nope; you seem to have forgotten that my decider is not recursive
> >>> in nature: my decider will correctly determine that that input is
> >>> pathological so will signal an exception.
> >>>
> >>> /Flibble
> >>>
> >>>
> >>
> >> The above terminates normally so your decider gets the wrong
> >> answer.
> >
> > It is a pathological input so neither halts nor doesn't halt:
> > pathological input is INVALID so the correct "answer" is to signal
> > an exception.
> >
> > /Flibble
> >
>
> So you don't know how static variables work?
> I am not surprised.
>
>
> void P(ptr x)
> {
> static int count = 0;
> if (count++ >= 2) goto exit;
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> exit:
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P,P));
> }
>
> _Pm()
> [0000141e](01) 55 push ebp
> [0000141f](02) 8bec mov ebp,esp
> [00001421](03) 83ec08 sub esp,+08
> [00001424](05) a100000000 mov eax,[00000000]
> [00001429](03) 8945fc mov [ebp-04],eax
> [0000142c](06) 8b0d00000000 mov ecx,[00000000]
> [00001432](03) 83c101 add ecx,+01
> [00001435](06) 890d00000000 mov [00000000],ecx
> [0000143b](04) 837dfc02 cmp dword [ebp-04],+02
> [0000143f](02) 7c02 jl 00001443
> [00001441](02) eb1b jmp 0000145e
> [00001443](03) 8b5508 mov edx,[ebp+08]
> [00001446](01) 52 push edx
> [00001447](03) 8b4508 mov eax,[ebp+08]
> [0000144a](01) 50 push eax
> [0000144b](05) e8defcffff call 0000112e
> [00001450](03) 83c408 add esp,+08
> [00001453](03) 8945f8 mov [ebp-08],eax
> [00001456](04) 837df800 cmp dword [ebp-08],+00
> [0000145a](02) 7402 jz 0000145e
> [0000145c](02) ebfe jmp 0000145c
> [0000145e](02) 8be5 mov esp,ebp
> [00001460](01) 5d pop ebp
> [00001461](01) c3 ret
> Size in bytes:(0068) [00001461]
>
> _main()
> [0000146e](01) 55 push ebp
> [0000146f](02) 8bec mov ebp,esp
> [00001471](05) 681e140000 push 0000141e
> [00001476](05) 681e140000 push 0000141e
> [0000147b](05) e8aefcffff call 0000112e
> [00001480](03) 83c408 add esp,+08
> [00001483](01) 50 push eax
> [00001484](05) 685f050000 push 0000055f
> [00001489](05) e820f1ffff call 000005ae
> [0000148e](03) 83c408 add esp,+08
> [00001491](02) 33c0 xor eax,eax
> [00001493](01) 5d pop ebp
> [00001494](01) c3 ret
> Size in bytes:(0039) [00001494]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [0000146e][00102462][00000000] 55 push ebp
> [0000146f][00102462][00000000] 8bec mov ebp,esp
> [00001471][0010245e][0000141e] 681e140000 push 0000141e
> [00001476][0010245a][0000141e] 681e140000 push 0000141e
> [0000147b][00102456][00001480] e8aefcffff call 0000112e
>
> H: Begin Simulation Execution Trace Stored at:11250e
> Address_of_H:112e
> [0000141e][001124fa][001124fe] 55 push ebp
> [0000141f][001124fa][001124fe] 8bec mov ebp,esp
> [00001421][001124f2][90909090] 83ec08 sub esp,+08
> [00001424][001124f2][90909090] a100000000 mov eax,[00000000]
> [00001429][001124f2][90909090] 8945fc mov [ebp-04],eax
> [0000142c][001124f2][90909090] 8b0d00000000 mov ecx,[00000000]
> [00001432][001124f2][90909090] 83c101 add ecx,+01
> [00001435][001124f2][90909090] 890d00000000 mov [00000000],ecx
> [0000143b][001124f2][90909090] 837dfc02 cmp dword [ebp-04],+02
> [0000143f][001124f2][90909090] 7c02 jl 00001443
> [00001441][001124f2][90909090] eb1b jmp 0000145e
> [0000145e][001124fa][001124fe] 8be5 mov esp,ebp
> [00001460][001124fe][00001217] 5d pop ebp
> [00001461][00112502][0000141e] c3 ret
> H: End Simulation Input Terminated Normally
>
> [00001480][00102462][00000000] 83c408 add esp,+08
> [00001483][0010245e][00000001] 50 push eax
> [00001484][0010245a][0000055f] 685f050000 push 0000055f
> [00001489][0010245a][0000055f] e820f1ffff call 000005ae
> Input_Halts = 1
> [0000148e][00102462][00000000] 83c408 add esp,+08
> [00001491][00102462][00000000] 33c0 xor eax,eax
> [00001493][00102466][00000018] 5d pop ebp
> [00001494][0010246a][00000000] c3 ret
> Number of Instructions Executed(1317) == 20 Pages
For this particular stack trace I notice that the function symbol at
the top of it is Pm not P which suggests to me one of two things:
1) It is not the actual trace of the input you posted with it,
or
2) There is something wrong with the compiler/linker you are using and
it is not initializing static variables correctly resulting in an early
termination.
If (1) is correct then you are a dishonest trolling fucktard; if (2) is
correct then I suggest you resolve that issue rather than assuming
incompetence in your honest reviewers.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-15 10:58 -0500 |
| Message-ID | <N7ednc5HcpwLE0z_nZ2dnUU7_81j4p2d@giganews.com> |
| In reply to | #85247 |
On 7/15/2022 10:49 AM, Mr Flibble wrote:
> On Fri, 15 Jul 2022 10:07:36 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/15/2022 9:32 AM, Mr Flibble wrote:
>>> On Fri, 15 Jul 2022 09:19:59 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/15/2022 7:06 AM, Mr Flibble wrote:
>>>>> On Fri, 15 Jul 2022 01:46:23 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 7/15/2022 1:23 AM, Mr Flibble wrote:
>>>>>>> On Thu, 14 Jul 2022 17:41:06 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 7/14/2022 5:30 PM, Mr Flibble wrote:
>>>>>>>>> On Thu, 14 Jul 2022 16:02:35 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 7/14/2022 3:22 PM, Mr Flibble wrote:
>>>>>>>>>>> On Thu, 14 Jul 2022 15:02:21 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Thu, 14 Jul 2022 14:19:38 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is an explanation of a key new insight into the
>>>>>>>>>>>>>> halting problem provided in the language of software
>>>>>>>>>>>>>> engineering. Technical computer science terms are
>>>>>>>>>>>>>> explained using software engineering terms. No knowledge
>>>>>>>>>>>>>> of the halting problem is required.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is based on fully operational software executed in the
>>>>>>>>>>>>>> x86utm operating system. The x86utm operating system
>>>>>>>>>>>>>> (based on an excellent open source x86 emulator) was
>>>>>>>>>>>>>> created to study the details of the halting problem proof
>>>>>>>>>>>>>> counter-examples at the much higher level of abstraction
>>>>>>>>>>>>>> of C/x86.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When simulating halt decider H(P,P) simulates its input
>>>>>>>>>>>>>> we can see that: (1) Function H() is called from P().
>>>>>>>>>>>>>> (2) With the same arguments to H().
>>>>>>>>>>>>>> (3) With no instructions in P preceding its invocation of
>>>>>>>>>>>>>> H(P,P).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The above shows that the simulated P cannot possibly
>>>>>>>>>>>>>> terminate normally. Because H can see the same (1)(2)(3)
>>>>>>>>>>>>>> that we see H aborts its simulation of P and rejects P as
>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In computability theory, the halting problem
>>>>>>>>>>>>>> is the problem of determining, from a description of an
>>>>>>>>>>>>>> arbitrary computer program and an input, whether the
>>>>>>>>>>>>>> program will finish running, or continue to run forever.
>>>>>>>>>>>>>> Alan Turing proved in 1936 that a general algorithm to
>>>>>>>>>>>>>> solve the halting problem for all possible program- input
>>>>>>>>>>>>>> pairs cannot exist.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H and P implement the exact pathological relationship to
>>>>>>>>>>>>>> each other as described above. Because H(P,P) does handle
>>>>>>>>>>>>>> this case the above halting problem undecidable input
>>>>>>>>>>>>>> template has been refuted.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *When this halt deciding principle understood to be
>>>>>>>>>>>>>> correct* A halt decider must compute the mapping from its
>>>>>>>>>>>>>> inputs to an accept or reject state on the basis of the
>>>>>>>>>>>>>> actual behavior that is actually specified by these
>>>>>>>>>>>>>> inputs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Then (by logical necessity) this implements that
>>>>>>>>>>>>>> principle* Every simulating halt decider that correctly
>>>>>>>>>>>>>> simulates its input until it correctly predicts that this
>>>>>>>>>>>>>> simulated input would never terminate normally, correctly
>>>>>>>>>>>>>> rejects this input as non-halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *H is a Pure function*
>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thus implements a *Computable function*
>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thus H is Turing computable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You forgot to mention infinite recursion which I suppose
>>>>>>>>>>>>> is progress.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I have proved that H(P,P) == 0 is correct.
>>>>>>>>>>>>
>>>>>>>>>>>> I have shown that H/P does implement the HP's "impossible
>>>>>>>>>>>> input" template.
>>>>>>>>>>>>
>>>>>>>>>>>> Therefore I have refuted all of the halting problem proofs
>>>>>>>>>>>> that rely on this template.
>>>>>>>>>>>
>>>>>>>>>>> Equating pathological input with non-halting is erroneous:
>>>>>>>>>>> you are only doing that because your broken solution treats
>>>>>>>>>>> it as "infinite recursion". There is no recursion in
>>>>>>>>>>> [Strachey 1965] and the HP proofs based on it.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> There is no recursion in any of the conventional proofs only
>>>>>>>>>> because no one ever previously bothered to fully examine how
>>>>>>>>>> a simulating halt decider would address these otherwise
>>>>>>>>>> "impossible" inputs.
>>>>>>>>>
>>>>>>>>> I have shown that a simulating halt decider needn't be
>>>>>>>>> recursive in nature:
>>>>>>>>>
>>>>>>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> You sure do make it easy to review your work.
>>>>>>>>
>>>>>>>> "When the simulator detects the call to H in P it forks
>>>>>>>> the simulation into a non-halting branch"
>>>>>>>>
>>>>>>>> There is an infinite set of cases where this overly simplistic
>>>>>>>> criteria gets the wrong answer.
>>>>>>>
>>>>>>> That is neither an honest review or any kind of rebuttal: I have
>>>>>>> told you before: assertions made without evidence can be
>>>>>>> dismissed without evidence.
>>>>>>>
>>>>>>> If you claim there are an infinite number of cases where it gets
>>>>>>> the wrong answer then it shouldn't be too hard for to provide
>>>>>>> ONE case backing up your claim.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>> Sure:
>>>>>>
>>>>>> void P(ptr x)
>>>>>> {
>>>>>> static int count = 3;
>>>>>> count--;
>>>>>> if (!count) goto exit;
>>>>>> int Halt_Status = H(x, x);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> exit:
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>> }
>>>>>
>>>>> Nope; you seem to have forgotten that my decider is not recursive
>>>>> in nature: my decider will correctly determine that that input is
>>>>> pathological so will signal an exception.
>>>>>
>>>>> /Flibble
>>>>>
>>>>>
>>>>
>>>> The above terminates normally so your decider gets the wrong
>>>> answer.
>>>
>>> It is a pathological input so neither halts nor doesn't halt:
>>> pathological input is INVALID so the correct "answer" is to signal
>>> an exception.
>>>
>>> /Flibble
>>>
>>
>> So you don't know how static variables work?
>> I am not surprised.
>>
>>
>> void P(ptr x)
>> {
>> static int count = 0;
>> if (count++ >= 2) goto exit;
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> exit:
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(P,P));
>> }
>>
>> _Pm()
>> [0000141e](01) 55 push ebp
>> [0000141f](02) 8bec mov ebp,esp
>> [00001421](03) 83ec08 sub esp,+08
>> [00001424](05) a100000000 mov eax,[00000000]
>> [00001429](03) 8945fc mov [ebp-04],eax
>> [0000142c](06) 8b0d00000000 mov ecx,[00000000]
>> [00001432](03) 83c101 add ecx,+01
>> [00001435](06) 890d00000000 mov [00000000],ecx
>> [0000143b](04) 837dfc02 cmp dword [ebp-04],+02
>> [0000143f](02) 7c02 jl 00001443
>> [00001441](02) eb1b jmp 0000145e
>> [00001443](03) 8b5508 mov edx,[ebp+08]
>> [00001446](01) 52 push edx
>> [00001447](03) 8b4508 mov eax,[ebp+08]
>> [0000144a](01) 50 push eax
>> [0000144b](05) e8defcffff call 0000112e
>> [00001450](03) 83c408 add esp,+08
>> [00001453](03) 8945f8 mov [ebp-08],eax
>> [00001456](04) 837df800 cmp dword [ebp-08],+00
>> [0000145a](02) 7402 jz 0000145e
>> [0000145c](02) ebfe jmp 0000145c
>> [0000145e](02) 8be5 mov esp,ebp
>> [00001460](01) 5d pop ebp
>> [00001461](01) c3 ret
>> Size in bytes:(0068) [00001461]
>>
>> _main()
>> [0000146e](01) 55 push ebp
>> [0000146f](02) 8bec mov ebp,esp
>> [00001471](05) 681e140000 push 0000141e
>> [00001476](05) 681e140000 push 0000141e
>> [0000147b](05) e8aefcffff call 0000112e
>> [00001480](03) 83c408 add esp,+08
>> [00001483](01) 50 push eax
>> [00001484](05) 685f050000 push 0000055f
>> [00001489](05) e820f1ffff call 000005ae
>> [0000148e](03) 83c408 add esp,+08
>> [00001491](02) 33c0 xor eax,eax
>> [00001493](01) 5d pop ebp
>> [00001494](01) c3 ret
>> Size in bytes:(0039) [00001494]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [0000146e][00102462][00000000] 55 push ebp
>> [0000146f][00102462][00000000] 8bec mov ebp,esp
>> [00001471][0010245e][0000141e] 681e140000 push 0000141e
>> [00001476][0010245a][0000141e] 681e140000 push 0000141e
>> [0000147b][00102456][00001480] e8aefcffff call 0000112e
>>
>> H: Begin Simulation Execution Trace Stored at:11250e
>> Address_of_H:112e
>> [0000141e][001124fa][001124fe] 55 push ebp
>> [0000141f][001124fa][001124fe] 8bec mov ebp,esp
>> [00001421][001124f2][90909090] 83ec08 sub esp,+08
>> [00001424][001124f2][90909090] a100000000 mov eax,[00000000]
>> [00001429][001124f2][90909090] 8945fc mov [ebp-04],eax
>> [0000142c][001124f2][90909090] 8b0d00000000 mov ecx,[00000000]
>> [00001432][001124f2][90909090] 83c101 add ecx,+01
>> [00001435][001124f2][90909090] 890d00000000 mov [00000000],ecx
>> [0000143b][001124f2][90909090] 837dfc02 cmp dword [ebp-04],+02
>> [0000143f][001124f2][90909090] 7c02 jl 00001443
>> [00001441][001124f2][90909090] eb1b jmp 0000145e
>> [0000145e][001124fa][001124fe] 8be5 mov esp,ebp
>> [00001460][001124fe][00001217] 5d pop ebp
>> [00001461][00112502][0000141e] c3 ret
>> H: End Simulation Input Terminated Normally
>>
>> [00001480][00102462][00000000] 83c408 add esp,+08
>> [00001483][0010245e][00000001] 50 push eax
>> [00001484][0010245a][0000055f] 685f050000 push 0000055f
>> [00001489][0010245a][0000055f] e820f1ffff call 000005ae
>> Input_Halts = 1
>> [0000148e][00102462][00000000] 83c408 add esp,+08
>> [00001491][00102462][00000000] 33c0 xor eax,eax
>> [00001493][00102466][00000018] 5d pop ebp
>> [00001494][0010246a][00000000] c3 ret
>> Number of Instructions Executed(1317) == 20 Pages
>
> For this particular stack trace I notice that the function symbol at
> the top of it is Pm not P which suggests to me one of two things:
>
I already had a P so I renamed it to Pm so it would not disturb my
existing code. When I changed all the Pm references to your name I
forgot one.
> 1) It is not the actual trace of the input you posted with it,
> or
> 2) There is something wrong with the compiler/linker you are using and
> it is not initializing static variables correctly resulting in an early
> termination.
>
> If (1) is correct then you are a dishonest trolling fucktard; if (2) is
> correct then I suggest you resolve that issue rather than assuming
> incompetence in your honest reviewers.
>
> /Flibble
>
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-07-15 17:03 +0100 |
| Message-ID | <20220715170340.00001838@reddwarf.jmc.corp> |
| In reply to | #85248 |
On Fri, 15 Jul 2022 10:58:14 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/15/2022 10:49 AM, Mr Flibble wrote:
> > On Fri, 15 Jul 2022 10:07:36 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/15/2022 9:32 AM, Mr Flibble wrote:
> >>> On Fri, 15 Jul 2022 09:19:59 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 7/15/2022 7:06 AM, Mr Flibble wrote:
> >>>>> On Fri, 15 Jul 2022 01:46:23 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 7/15/2022 1:23 AM, Mr Flibble wrote:
> >>>>>>> On Thu, 14 Jul 2022 17:41:06 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 7/14/2022 5:30 PM, Mr Flibble wrote:
> >>>>>>>>> On Thu, 14 Jul 2022 16:02:35 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 7/14/2022 3:22 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Thu, 14 Jul 2022 15:02:21 -0500
> >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Thu, 14 Jul 2022 14:19:38 -0500
> >>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> This is an explanation of a key new insight into the
> >>>>>>>>>>>>>> halting problem provided in the language of software
> >>>>>>>>>>>>>> engineering. Technical computer science terms are
> >>>>>>>>>>>>>> explained using software engineering terms. No
> >>>>>>>>>>>>>> knowledge of the halting problem is required.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It is based on fully operational software executed in
> >>>>>>>>>>>>>> the x86utm operating system. The x86utm operating
> >>>>>>>>>>>>>> system (based on an excellent open source x86
> >>>>>>>>>>>>>> emulator) was created to study the details of the
> >>>>>>>>>>>>>> halting problem proof counter-examples at the much
> >>>>>>>>>>>>>> higher level of abstraction of C/x86.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> When simulating halt decider H(P,P) simulates its input
> >>>>>>>>>>>>>> we can see that: (1) Function H() is called from P().
> >>>>>>>>>>>>>> (2) With the same arguments to H().
> >>>>>>>>>>>>>> (3) With no instructions in P preceding its invocation
> >>>>>>>>>>>>>> of H(P,P).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The above shows that the simulated P cannot possibly
> >>>>>>>>>>>>>> terminate normally. Because H can see the same
> >>>>>>>>>>>>>> (1)(2)(3) that we see H aborts its simulation of P and
> >>>>>>>>>>>>>> rejects P as non-halting.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> In computability theory, the halting
> >>>>>>>>>>>>>> problem is the problem of determining, from a
> >>>>>>>>>>>>>> description of an arbitrary computer program and an
> >>>>>>>>>>>>>> input, whether the program will finish running, or
> >>>>>>>>>>>>>> continue to run forever. Alan Turing proved in 1936
> >>>>>>>>>>>>>> that a general algorithm to solve the halting problem
> >>>>>>>>>>>>>> for all possible program- input pairs cannot exist.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> H and P implement the exact pathological relationship
> >>>>>>>>>>>>>> to each other as described above. Because H(P,P) does
> >>>>>>>>>>>>>> handle this case the above halting problem undecidable
> >>>>>>>>>>>>>> input template has been refuted.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> *When this halt deciding principle understood to be
> >>>>>>>>>>>>>> correct* A halt decider must compute the mapping from
> >>>>>>>>>>>>>> its inputs to an accept or reject state on the basis
> >>>>>>>>>>>>>> of the actual behavior that is actually specified by
> >>>>>>>>>>>>>> these inputs.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> *Then (by logical necessity) this implements that
> >>>>>>>>>>>>>> principle* Every simulating halt decider that correctly
> >>>>>>>>>>>>>> simulates its input until it correctly predicts that
> >>>>>>>>>>>>>> this simulated input would never terminate normally,
> >>>>>>>>>>>>>> correctly rejects this input as non-halting.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> *H is a Pure function*
> >>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> thus implements a *Computable function*
> >>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thus H is Turing computable.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> *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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> You forgot to mention infinite recursion which I suppose
> >>>>>>>>>>>>> is progress.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I have proved that H(P,P) == 0 is correct.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I have shown that H/P does implement the HP's "impossible
> >>>>>>>>>>>> input" template.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Therefore I have refuted all of the halting problem
> >>>>>>>>>>>> proofs that rely on this template.
> >>>>>>>>>>>
> >>>>>>>>>>> Equating pathological input with non-halting is erroneous:
> >>>>>>>>>>> you are only doing that because your broken solution
> >>>>>>>>>>> treats it as "infinite recursion". There is no recursion
> >>>>>>>>>>> in [Strachey 1965] and the HP proofs based on it.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> There is no recursion in any of the conventional proofs
> >>>>>>>>>> only because no one ever previously bothered to fully
> >>>>>>>>>> examine how a simulating halt decider would address these
> >>>>>>>>>> otherwise "impossible" inputs.
> >>>>>>>>>
> >>>>>>>>> I have shown that a simulating halt decider needn't be
> >>>>>>>>> recursive in nature:
> >>>>>>>>>
> >>>>>>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> You sure do make it easy to review your work.
> >>>>>>>>
> >>>>>>>> "When the simulator detects the call to H in P it
> >>>>>>>> forks the simulation into a non-halting branch"
> >>>>>>>>
> >>>>>>>> There is an infinite set of cases where this overly
> >>>>>>>> simplistic criteria gets the wrong answer.
> >>>>>>>
> >>>>>>> That is neither an honest review or any kind of rebuttal: I
> >>>>>>> have told you before: assertions made without evidence can be
> >>>>>>> dismissed without evidence.
> >>>>>>>
> >>>>>>> If you claim there are an infinite number of cases where it
> >>>>>>> gets the wrong answer then it shouldn't be too hard for to
> >>>>>>> provide ONE case backing up your claim.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>> Sure:
> >>>>>>
> >>>>>> void P(ptr x)
> >>>>>> {
> >>>>>> static int count = 3;
> >>>>>> count--;
> >>>>>> if (!count) goto exit;
> >>>>>> int Halt_Status = H(x, x);
> >>>>>> if (Halt_Status)
> >>>>>> HERE: goto HERE;
> >>>>>> exit:
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>> }
> >>>>>
> >>>>> Nope; you seem to have forgotten that my decider is not
> >>>>> recursive in nature: my decider will correctly determine that
> >>>>> that input is pathological so will signal an exception.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>>
> >>>>
> >>>> The above terminates normally so your decider gets the wrong
> >>>> answer.
> >>>
> >>> It is a pathological input so neither halts nor doesn't halt:
> >>> pathological input is INVALID so the correct "answer" is to signal
> >>> an exception.
> >>>
> >>> /Flibble
> >>>
> >>
> >> So you don't know how static variables work?
> >> I am not surprised.
> >>
> >>
> >> void P(ptr x)
> >> {
> >> static int count = 0;
> >> if (count++ >= 2) goto exit;
> >> int Halt_Status = H(x, x);
> >> if (Halt_Status)
> >> HERE: goto HERE;
> >> exit:
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H(P,P));
> >> }
> >>
> >> _Pm()
> >> [0000141e](01) 55 push ebp
> >> [0000141f](02) 8bec mov ebp,esp
> >> [00001421](03) 83ec08 sub esp,+08
> >> [00001424](05) a100000000 mov eax,[00000000]
> >> [00001429](03) 8945fc mov [ebp-04],eax
> >> [0000142c](06) 8b0d00000000 mov ecx,[00000000]
> >> [00001432](03) 83c101 add ecx,+01
> >> [00001435](06) 890d00000000 mov [00000000],ecx
> >> [0000143b](04) 837dfc02 cmp dword [ebp-04],+02
> >> [0000143f](02) 7c02 jl 00001443
> >> [00001441](02) eb1b jmp 0000145e
> >> [00001443](03) 8b5508 mov edx,[ebp+08]
> >> [00001446](01) 52 push edx
> >> [00001447](03) 8b4508 mov eax,[ebp+08]
> >> [0000144a](01) 50 push eax
> >> [0000144b](05) e8defcffff call 0000112e
> >> [00001450](03) 83c408 add esp,+08
> >> [00001453](03) 8945f8 mov [ebp-08],eax
> >> [00001456](04) 837df800 cmp dword [ebp-08],+00
> >> [0000145a](02) 7402 jz 0000145e
> >> [0000145c](02) ebfe jmp 0000145c
> >> [0000145e](02) 8be5 mov esp,ebp
> >> [00001460](01) 5d pop ebp
> >> [00001461](01) c3 ret
> >> Size in bytes:(0068) [00001461]
> >>
> >> _main()
> >> [0000146e](01) 55 push ebp
> >> [0000146f](02) 8bec mov ebp,esp
> >> [00001471](05) 681e140000 push 0000141e
> >> [00001476](05) 681e140000 push 0000141e
> >> [0000147b](05) e8aefcffff call 0000112e
> >> [00001480](03) 83c408 add esp,+08
> >> [00001483](01) 50 push eax
> >> [00001484](05) 685f050000 push 0000055f
> >> [00001489](05) e820f1ffff call 000005ae
> >> [0000148e](03) 83c408 add esp,+08
> >> [00001491](02) 33c0 xor eax,eax
> >> [00001493](01) 5d pop ebp
> >> [00001494](01) c3 ret
> >> Size in bytes:(0039) [00001494]
> >>
> >> machine stack stack machine assembly
> >> address address data code language
> >> ======== ======== ======== ========= =============
> >> [0000146e][00102462][00000000] 55 push ebp
> >> [0000146f][00102462][00000000] 8bec mov ebp,esp
> >> [00001471][0010245e][0000141e] 681e140000 push 0000141e
> >> [00001476][0010245a][0000141e] 681e140000 push 0000141e
> >> [0000147b][00102456][00001480] e8aefcffff call 0000112e
> >>
> >> H: Begin Simulation Execution Trace Stored at:11250e
> >> Address_of_H:112e
> >> [0000141e][001124fa][001124fe] 55 push ebp
> >> [0000141f][001124fa][001124fe] 8bec mov ebp,esp
> >> [00001421][001124f2][90909090] 83ec08 sub esp,+08
> >> [00001424][001124f2][90909090] a100000000 mov eax,[00000000]
> >> [00001429][001124f2][90909090] 8945fc mov [ebp-04],eax
> >> [0000142c][001124f2][90909090] 8b0d00000000 mov ecx,[00000000]
> >> [00001432][001124f2][90909090] 83c101 add ecx,+01
> >> [00001435][001124f2][90909090] 890d00000000 mov [00000000],ecx
> >> [0000143b][001124f2][90909090] 837dfc02 cmp dword [ebp-04],+02
> >> [0000143f][001124f2][90909090] 7c02 jl 00001443
> >> [00001441][001124f2][90909090] eb1b jmp 0000145e
> >> [0000145e][001124fa][001124fe] 8be5 mov esp,ebp
> >> [00001460][001124fe][00001217] 5d pop ebp
> >> [00001461][00112502][0000141e] c3 ret
> >> H: End Simulation Input Terminated Normally
> >>
> >> [00001480][00102462][00000000] 83c408 add esp,+08
> >> [00001483][0010245e][00000001] 50 push eax
> >> [00001484][0010245a][0000055f] 685f050000 push 0000055f
> >> [00001489][0010245a][0000055f] e820f1ffff call 000005ae
> >> Input_Halts = 1
> >> [0000148e][00102462][00000000] 83c408 add esp,+08
> >> [00001491][00102462][00000000] 33c0 xor eax,eax
> >> [00001493][00102466][00000018] 5d pop ebp
> >> [00001494][0010246a][00000000] c3 ret
> >> Number of Instructions Executed(1317) == 20 Pages
> >
> > For this particular stack trace I notice that the function symbol at
> > the top of it is Pm not P which suggests to me one of two things:
> >
>
> I already had a P so I renamed it to Pm so it would not disturb my
> existing code. When I changed all the Pm references to your name I
> forgot one.
Then I suggest you check the output of compilation/linking is actually
initializing static variables correctly. Are you even using a linker
or are you just executing an object file? Static data normally goes
into a separate data segment during the linking process.
/Flibble
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c++
csiph-web