Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #52749 > unrolled thread
| Started by | olcott <NoOne@NoWhere.com> |
|---|---|
| First post | 2022-06-21 21:38 -0500 |
| Last post | 2022-06-22 22:13 +0100 |
| Articles | 20 on this page of 212 — 13 participants |
Back to article view | Back to comp.theory
Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-21 21:38 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-21 22:52 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-21 22:10 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-21 23:28 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Python <python@example.invalid> - 2022-06-22 05:52 +0200
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-22 00:55 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 07:16 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-22 05:45 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 07:53 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 09:55 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 19:05 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 18:39 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 20:22 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 19:30 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 20:56 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 20:03 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:19 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 20:33 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:49 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-22 16:50 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] olcott <NoOne@NoWhere.com> - 2022-06-22 12:58 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 19:11 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] olcott <NoOne@NoWhere.com> - 2022-06-22 19:00 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 20:25 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 19:34 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:05 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-23 01:19 -0700
Software engineers can verify this halting problem proof refutation [ H(P,P) versus P(P) ] olcott <NoOne@NoWhere.com> - 2022-06-23 13:14 -0500
Re: Software engineers can verify this halting problem proof refutation [ H(P,P) versus P(P) ] Daniel Pehoushek <pehoushek1@gmail.com> - 2022-06-23 11:26 -0700
Re: Software engineers can verify this halting problem proof refutation [ H(P,P) versus P(P) ] Richard Damon <Richard@Damon-Family.org> - 2022-06-23 19:00 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-23 23:44 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-23 20:38 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 00:53 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 08:07 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 09:18 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 06:34 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 09:32 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 12:07 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <polcott2@gmail.com> - 2022-06-24 10:50 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 09:09 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 11:32 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 12:46 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 11:52 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 15:55 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 10:29 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 12:42 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 12:34 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 15:20 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 16:00 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-24 20:42 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 13:25 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 15:35 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 16:59 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-24 23:16 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 17:25 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-06-24 16:58 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 19:12 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 21:56 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-06-24 21:50 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 23:59 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 21:01 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <polcott2@gmail.com> - 2022-06-24 23:33 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 22:09 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 00:24 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-25 00:32 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 09:28 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 10:03 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 16:09 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 10:19 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 16:21 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 10:54 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 16:59 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 11:06 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 17:25 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 11:32 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 20:12 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <NoOne@NoWhere.com> - 2022-06-25 14:20 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 20:33 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-25 13:03 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Python <python@example.invalid> - 2022-06-25 18:31 +0200
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 11:40 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-25 12:59 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-25 09:39 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-26 00:55 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 20:07 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 02:16 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 20:36 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-26 14:40 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 19:57 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-26 21:42 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 15:53 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 20:58 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 03:03 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 05:31 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 12:15 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 11:27 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 20:00 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 14:11 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 20:26 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 14:37 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 20:43 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 14:54 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 21:15 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 15:37 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 21:40 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 15:42 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-26 15:09 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-26 14:56 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 20:01 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-26 03:14 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 05:42 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-26 13:58 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 16:18 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Jeff Barnett <jbb@notatt.com> - 2022-06-22 11:11 -0600
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 13:10 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Jeff Barnett <jbb@notatt.com> - 2022-06-22 16:10 -0600
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 17:34 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 17:37 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Paul N <gw7rib@aol.com> - 2022-06-23 05:20 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-23 13:03 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-22 20:31 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 15:27 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-22 22:20 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 16:41 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-22 22:49 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 16:58 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-23 00:01 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 18:29 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 14:53 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 17:22 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 15:48 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 18:11 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 18:02 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 20:16 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 18:21 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 20:37 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 18:44 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 21:15 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 22:22 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 21:42 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 22:52 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 19:23 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 21:46 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 19:48 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-23 01:28 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 22:54 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-24 13:52 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Paul N <gw7rib@aol.com> - 2022-06-24 13:05 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-24 15:27 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Paul N <gw7rib@aol.com> - 2022-06-25 04:56 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-25 09:10 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 15:53 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Paul N <gw7rib@aol.com> - 2022-06-25 09:19 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-25 11:29 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Paul N <gw7rib@aol.com> - 2022-06-25 10:21 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <NoOne@NoWhere.com> - 2022-06-25 12:52 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Paul N <gw7rib@aol.com> - 2022-06-25 11:58 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <NoOne@NoWhere.com> - 2022-06-25 14:15 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 20:18 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Richard Damon <Richard@Damon-Family.org> - 2022-06-25 16:11 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 20:15 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-25 20:24 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Paul N <gw7rib@aol.com> - 2022-06-25 12:33 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-25 14:49 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-25 17:35 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-26 00:28 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-25 20:34 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <polcott2@gmail.com> - 2022-06-25 19:54 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <polcott2@gmail.com> - 2022-06-25 19:55 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <polcott2@gmail.com> - 2022-06-25 19:56 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <NoOne@NoWhere.com> - 2022-06-25 19:57 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Richard Damon <Richard@Damon-Family.org> - 2022-06-25 21:47 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-25 14:39 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-25 19:21 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 00:42 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-24 23:23 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <NoOne@NoWhere.com> - 2022-06-24 17:58 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Richard Damon <Richard@Damon-Family.org> - 2022-06-24 22:00 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:52 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 20:32 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 19:37 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 20:48 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 19:55 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 18:05 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 20:20 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:32 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Paul N <gw7rib@aol.com> - 2022-06-23 05:13 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-06-23 17:28 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 11:42 -0500
Software engineers can verify this halting problem proof refutation [ H(P,P) versus P(P) ] olcott <NoOne@NoWhere.com> - 2022-06-23 12:44 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:14 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 20:29 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:36 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 20:41 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:45 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 21:18 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 22:34 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 21:55 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 23:41 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 00:13 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 00:19 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-23 07:20 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-23 20:41 +0100
Software engineers [ not Flibble ] can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 14:56 -0500
Re: Software engineers [ not Flibble ] can verify this halting problem proof refutation [ full closure ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-23 20:59 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-06-23 16:55 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 20:38 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-23 21:59 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 21:10 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-23 22:29 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ nitwit rebuttals ] olcott <NoOne@NoWhere.com> - 2022-06-22 15:47 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ nitwit rebuttals ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-22 22:13 +0100
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-25 20:15 +0100 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] |
| Message-ID | <20220625201552.00001f2f@reddwarf.jmc> |
| In reply to | #52964 |
On Sat, 25 Jun 2022 11:58:20 -0700 (PDT)
Paul N <gw7rib@aol.com> wrote:
> On Saturday, June 25, 2022 at 6:52:33 PM UTC+1, olcott wrote:
> > On 6/25/2022 12:21 PM, Paul N wrote:
> > > On Saturday, June 25, 2022 at 5:29:33 PM UTC+1, olcott wrote:
> > >> On 6/25/2022 11:19 AM, Paul N wrote:
> > >>> On Saturday, June 25, 2022 at 3:10:50 PM UTC+1, olcott wrote:
> > >>>> On 6/25/2022 6:56 AM, Paul N wrote:
> > >>>>> On Friday, June 24, 2022 at 9:27:27 PM UTC+1, olcott wrote:
> > >>>>>> On 6/24/2022 3:05 PM, Paul N wrote:
> > >>>>>>> On Friday, June 24, 2022 at 7:52:22 PM UTC+1, olcott wrote:
> > >>>>>>>
> > >>>>>>>> On 6/22/2022 9:23 PM, Dennis Bush wrote:
> > >>>>>>>>> On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott
> > >>>>>>>>> wrote:
> > >>>>>>>>>> On 6/22/2022 8:44 PM, Dennis Bush wrote:
> > >>>>>>>>>>> On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>> On 6/22/2022 8:21 PM, Dennis Bush wrote:
> > >>>>>>>>>>>>> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4,
> > >>>>>>>>>>>>> olcott wrote:
> > >>>>>>>>>>>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
> > >>>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4,
> > >>>>>>>>>>>>>>> olcott wrote:
> > >>>>>>>>>>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
> > >>>>>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4,
> > >>>>>>>>>>>>>>>>> olcott wrote:
> > >>>>>>>>>>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
> > >>>>>>>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM
> > >>>>>>>>>>>>>>>>>>> UTC-4, olcott wrote:
> > >>>>>>>>>>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
> > >>>>>>>>>>>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
> > >>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
> > >>>>>>>>>>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
> > >>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> #include <stdint.h>
> > >>>>>>>>>>>>>>>>>>>>>>>> #define u32 uint32_t
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> #include <stdint.h>
> > >>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> > >>>>>>>>>>>>>>>>>>>>>>>> {
> > >>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
> > >>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> > >>>>>>>>>>>>>>>>>>>>>>>> return;
> > >>>>>>>>>>>>>>>>>>>>>>>> }
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> int main()
> > >>>>>>>>>>>>>>>>>>>>>>>> {
> > >>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> > >>>>>>>>>>>>>>>>>>>>>>>> }
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> _P()
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010d2](01) 55 push ebp
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010ec](01) c3 ret
> > >>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> Every sufficiently competent software
> > >>>>>>>>>>>>>>>>>>>>>>>> engineer can easily verify that the
> > >>>>>>>>>>>>>>>>>>>>>>>> complete and correct x86 emulation of the
> > >>>>>>>>>>>>>>>>>>>>>>>> input to H(P,P) by H would never reach the
> > >>>>>>>>>>>>>>>>>>>>>>>> "ret" instruction of P because both H and
> > >>>>>>>>>>>>>>>>>>>>>>>> P would remain stuck in infinitely
> > >>>>>>>>>>>>>>>>>>>>>>>> recursive emulation.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> If H does correctly determine that this is
> > >>>>>>>>>>>>>>>>>>>>>>>> the case in a finite number of steps then
> > >>>>>>>>>>>>>>>>>>>>>>>> H could reject its input on this basis.
> > >>>>>>>>>>>>>>>>>>>>>>>> Here are the details of exactly how H does
> > >>>>>>>>>>>>>>>>>>>>>>>> this in a finite number of steps.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> typedef struct Decoded
> > >>>>>>>>>>>>>>>>>>>>>>>> {
> > >>>>>>>>>>>>>>>>>>>>>>>> u32 Address;
> > >>>>>>>>>>>>>>>>>>>>>>>> u32 ESP; // Current value of ESP
> > >>>>>>>>>>>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
> > >>>>>>>>>>>>>>>>>>>>>>>> u32 NumBytes;
> > >>>>>>>>>>>>>>>>>>>>>>>> u32 Simplified_Opcode;
> > >>>>>>>>>>>>>>>>>>>>>>>> u32 Decode_Target;
> > >>>>>>>>>>>>>>>>>>>>>>>> } Decoded_Line_Of_Code;
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
> > >>>>>>>>>>>>>>>>>>>>>>>> address address data code language
> > >>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== =========
> > >>>>>>>>>>>>>>>>>>>>>>>> =============
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov
> > >>>>>>>>>>>>>>>>>>>>>>>> ebp,esp [000010d5][00211e8a][00211e8e]
> > >>>>>>>>>>>>>>>>>>>>>>>> 8b4508 mov eax,[ebp+08]
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax
> > >>>>>>>>>>>>>>>>>>>>>>>> // push P [000010d9][00211e86][000010d2]
> > >>>>>>>>>>>>>>>>>>>>>>>> 8b4d08 mov ecx,[ebp+08]
> > >>>>>>>>>>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx
> > >>>>>>>>>>>>>>>>>>>>>>>> // push P [000010dd][00211e7e][000010e2]
> > >>>>>>>>>>>>>>>>>>>>>>>> e820feffff call 00000f02 // call H
> > >>>>>>>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected
> > >>>>>>>>>>>>>>>>>>>>>>>> Simulation Stopped
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> // actual fully operational code in the
> > >>>>>>>>>>>>>>>>>>>>>>>> x86utm operating system u32 H(u32 P, u32
> > >>>>>>>>>>>>>>>>>>>>>>>> I) {
> > >>>>>>>>>>>>>>>>>>>>>>>> HERE:
> > >>>>>>>>>>>>>>>>>>>>>>>> u32 End_Of_Code;
> > >>>>>>>>>>>>>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
> > >>>>>>>>>>>>>>>>>>>>>>>> u32 code_end = get_code_end(P);
> > >>>>>>>>>>>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded =
> > >>>>>>>>>>>>>>>>>>>>>>>> (Decoded_Line_Of_Code*)
> > >>>>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
> > >>>>>>>>>>>>>>>>>>>>>>>> Registers* master_state = (Registers*)
> > >>>>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers)); Registers*
> > >>>>>>>>>>>>>>>>>>>>>>>> slave_state = (Registers*)
> > >>>>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers)); u32*
> > >>>>>>>>>>>>>>>>>>>>>>>> slave_stack = Allocate(0x10000); // 64k;
> > >>>>>>>>>>>>>>>>>>>>>>>> u32 execution_trace =
> > >>>>>>>>>>>>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
> > >>>>>>>>>>>>>>>>>>>>>>>> * 1000);
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
> > >>>>>>>>>>>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
> > >>>>>>>>>>>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
> > >>>>>>>>>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
> > >>>>>>>>>>>>>>>>>>>>>>>> __asm mov End_Of_Code, eax
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); //
> > >>>>>>>>>>>>>>>>>>>>>>>> 2022-06-11 Init_slave_state(P, I,
> > >>>>>>>>>>>>>>>>>>>>>>>> End_Of_Code, slave_state, slave_stack);
> > >>>>>>>>>>>>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace
> > >>>>>>>>>>>>>>>>>>>>>>>> Stored at:", execution_trace); if
> > >>>>>>>>>>>>>>>>>>>>>>>> (Decide_Halting(&execution_trace,
> > >>>>>>>>>>>>>>>>>>>>>>>> &decoded, code_end, &master_state,
> > >>>>>>>>>>>>>>>>>>>>>>>> &slave_state, &slave_stack, Address_of_H,
> > >>>>>>>>>>>>>>>>>>>>>>>> P, I)) goto END_OF_CODE; return 0; // Does
> > >>>>>>>>>>>>>>>>>>>>>>>> not halt END_OF_CODE: return 1; // Input
> > >>>>>>>>>>>>>>>>>>>>>>>> has normally terminated }
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> H knows its own machine address and on
> > >>>>>>>>>>>>>>>>>>>>>>>> this basis it can easily examine its
> > >>>>>>>>>>>>>>>>>>>>>>>> stored execution_trace of P and determine:
> > >>>>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments
> > >>>>>>>>>>>>>>>>>>>>>>>> that H was called with. (b) No
> > >>>>>>>>>>>>>>>>>>>>>>>> instructions in P could possibly escape
> > >>>>>>>>>>>>>>>>>>>>>>>> this otherwise infinitely recursive
> > >>>>>>>>>>>>>>>>>>>>>>>> emulation. (c) H aborts its emulation of P
> > >>>>>>>>>>>>>>>>>>>>>>>> before its call to H is invoked.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> Technically competent software engineers
> > >>>>>>>>>>>>>>>>>>>>>>>> may not know this computer science:
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> 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.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> computation that halts … the Turing
> > >>>>>>>>>>>>>>>>>>>>>>>> machine will halt whenever it enters a
> > >>>>>>>>>>>>>>>>>>>>>>>> final state. (Linz:1990:234)
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> The "ret" instruction of P is its final
> > >>>>>>>>>>>>>>>>>>>>>>>> state.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to
> > >>>>>>>>>>>>>>>>>>>>>>>> Formal Languages and Automata.
> > >>>>>>>>>>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and
> > >>>>>>>>>>>>>>>>>>>>>>>> Company. (317-320)
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> void Px(u32 x)
> > >>>>>>>>>>>>>>>>>>>>>>> {
> > >>>>>>>>>>>>>>>>>>>>>>> H(x, x);
> > >>>>>>>>>>>>>>>>>>>>>>> return;
> > >>>>>>>>>>>>>>>>>>>>>>> }
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> int main()
> > >>>>>>>>>>>>>>>>>>>>>>> {
> > >>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px,
> > >>>>>>>>>>>>>>>>>>>>>>> (u32)Px)); }
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408
> > >>>>>>>>>>>>>>>>>>>>>>> add esp,+08
> > >>>>>>>>>>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push
> > >>>>>>>>>>>>>>>>>>>>>>> eax ...[000013ec][0010234f][00000427]
> > >>>>>>>>>>>>>>>>>>>>>>> 6827040000 push 00000427
> > >>>>>>>>>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427]
> > >>>>>>>>>>>>>>>>>>>>>>> e880f0ffff call 00000476 Input_Halts = 0
> > >>>>>>>>>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408
> > >>>>>>>>>>>>>>>>>>>>>>> add esp,+08
> > >>>>>>>>>>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor
> > >>>>>>>>>>>>>>>>>>>>>>> eax,eax ...[000013fb][0010235b][00100000]
> > >>>>>>>>>>>>>>>>>>>>>>> 5d pop ebp
> > >>>>>>>>>>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
> > >>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120)
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> It gets the answer wrong, i.e. input has
> > >>>>>>>>>>>>>>>>>>>>>>> not been decided correctly. QED.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> /Flibble
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> You and Richard are insufficiently
> > >>>>>>>>>>>>>>>>>>>>>> technically competent at software
> > >>>>>>>>>>>>>>>>>>>>>> engineering not meeting these specs:
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> A software engineer must be an expert in:
> > >>>>>>>>>>>>>>>>>>>>>> the C programming language, the x86
> > >>>>>>>>>>>>>>>>>>>>>> programming language, exactly how C
> > >>>>>>>>>>>>>>>>>>>>>> translates into x86 and the ability to
> > >>>>>>>>>>>>>>>>>>>>>> recognize infinite recursion at the x86
> > >>>>>>>>>>>>>>>>>>>>>> assembly language level. No knowledge of the
> > >>>>>>>>>>>>>>>>>>>>>> halting problem is required.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> I cannot speak for Richard but I have 30+
> > >>>>>>>>>>>>>>>>>>>>> years C++ experience; I also have C and x86
> > >>>>>>>>>>>>>>>>>>>>> assembly experience (I once wrote a Zilog
> > >>>>>>>>>>>>>>>>>>>>> Z80A CPU emulator in 80286 assembly) and I
> > >>>>>>>>>>>>>>>>>>>>> can recognize an infinite recursion; the
> > >>>>>>>>>>>>>>>>>>>>> problem is that you cannot recognize the fact
> > >>>>>>>>>>>>>>>>>>>>> that the infinite recursion only manifests as
> > >>>>>>>>>>>>>>>>>>>>> part of your invalid simulation-based
> > >>>>>>>>>>>>>>>>>>>>> omnishambles:
> > >>>>>>>>>>>>>>>>>>>> If you are competent then you already know
> > >>>>>>>>>>>>>>>>>>>> this is true and lie about it: Every
> > >>>>>>>>>>>>>>>>>>>> sufficiently competent software engineer can
> > >>>>>>>>>>>>>>>>>>>> easily verify that the complete and correct
> > >>>>>>>>>>>>>>>>>>>> x86 emulation of the input to H(Px,Px) by H
> > >>>>>>>>>>>>>>>>>>>> would never reach the "ret" instruction of P
> > >>>>>>>>>>>>>>>>>>>> because both H and P would remain stuck in
> > >>>>>>>>>>>>>>>>>>>> infinitely recursive emulation.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> H (if it was constructed correctly) is a
> > >>>>>>>>>>>>>>>>>>> computation, and a computation *always* gives
> > >>>>>>>>>>>>>>>>>>> the same output for a given input. So it
> > >>>>>>>>>>>>>>>>>>> doesn't make sense to say what it "would" do.
> > >>>>>>>>>>>>>>>>>>> It either does or does not perform a complete
> > >>>>>>>>>>>>>>>>>>> and correct emulation. And because H contains
> > >>>>>>>>>>>>>>>>>>> code to abort, and does abort, it does not do a
> > >>>>>>>>>>>>>>>>>>> complete emulation.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> So the input must be given to a UTM, which by
> > >>>>>>>>>>>>>>>>>>> definition does a correct and complete
> > >>>>>>>>>>>>>>>>>>> simulation, to see what the actual behavior is.
> > >>>>>>>>>>>>>>>>>>> UTM(Px,Px) halts, therefore H(Px,Px)==0 is
> > >>>>>>>>>>>>>>>>>>> wrong.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Every sufficiently competent software engineer
> > >>>>>>>>>>>>>>>>>> can easily verify that the complete and correct
> > >>>>>>>>>>>>>>>>>> x86 emulation of the input to H(Px,Px) by H
> > >>>>>>>>>>>>>>>>>> would never reach the "ret" instruction of Px
> > >>>>>>>>>>>>>>>>>> because both H and Px would remain stuck in
> > >>>>>>>>>>>>>>>>>> infinitely recursive emulation.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> So you just repeated what you said instead of
> > >>>>>>>>>>>>>>>>> explaining why I'm wrong. In other words you
> > >>>>>>>>>>>>>>>>> provided no rebuttal, which can only be taken to
> > >>>>>>>>>>>>>>>>> mean that you have none.
> > >>>>>>>>>>>>>>>> Your entire basis and all of assumptions was
> > >>>>>>>>>>>>>>>> incorrect so when I provided an infallible one to
> > >>>>>>>>>>>>>>>> that cannot possibly be correctly refuted you
> > >>>>>>>>>>>>>>>> simply dodged it. That is a smart move for a
> > >>>>>>>>>>>>>>>> dishonest person that is only interested in
> > >>>>>>>>>>>>>>>> rebuttal.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> I dare you to go back to the prior post and find
> > >>>>>>>>>>>>>>>> any error in my airtight correct reasoning.
> > >>>>>>>>>>>>>>>> Another dodge will be construed as a tacit
> > >>>>>>>>>>>>>>>> admission of defeat.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> As stated before H (or more accurately Ha) does not
> > >>>>>>>>>>>>>>> perform a complete and correct emulation because it
> > >>>>>>>>>>>>>>> aborts. So by definition it cannot be complete.
> > >>>>>>>>>>>>>> I never claimed that H(P,P) performs a complete and
> > >>>>>>>>>>>>>> correct emulation of its input so your rebuttal is
> > >>>>>>>>>>>>>> the strawman deception.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I claimed that H(P,P) correctly predicts that its
> > >>>>>>>>>>>>>> complete and correct x86 emulation of its input
> > >>>>>>>>>>>>>> would never reach the "ret" instruction of P.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> But since H, or more accurately Ha, *can't* do a
> > >>>>>>>>>>>>> correct and complete emulation of its input, your
> > >>>>>>>>>>>>> point is moot.
> > >>>>>>>>>>>> _Infinite_Loop()
> > >>>>>>>>>>>> [00001082](01) 55 push ebp
> > >>>>>>>>>>>> [00001083](02) 8bec mov ebp,esp
> > >>>>>>>>>>>> [00001085](02) ebfe jmp 00001085
> > >>>>>>>>>>>> [00001087](01) 5d pop ebp
> > >>>>>>>>>>>> [00001088](01) c3 ret
> > >>>>>>>>>>>> Size in bytes:(0007) [00001088]
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Begin Local Halt Decider Simulation Execution Trace
> > >>>>>>>>>>>> Stored at:211e8f ...[00001082][00211e7f][00211e83] 55
> > >>>>>>>>>>>> push ebp ...[00001083][00211e7f][00211e83] 8bec mov
> > >>>>>>>>>>>> ebp,esp ...[00001085][00211e7f][00211e83] ebfe jmp
> > >>>>>>>>>>>> 00001085 ...[00001085][00211e7f][00211e83] ebfe jmp
> > >>>>>>>>>>>> 00001085 Infinite Loop Detected Simulation Stopped
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On the basis of this exact same utterly moronic
> > >>>>>>>>>>>> reasoning because H *can't* do a correct and complete
> > >>>>>>>>>>>> emulation of its input, H cannot possibly determine
> > >>>>>>>>>>>> that _Infinite_Loop() never halts.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Now who's using the strawman error? Just because H can
> > >>>>>>>>>>> determine that _Infinite_Loop does not halt doesn't
> > >>>>>>>>>>> mean that it gets other cases right. B
> > >>>>>>>>>> You just said that H(P,P) cannot correctly predict that
> > >>>>>>>>>> the correct and complete x86 emulation of its input
> > >>>>>>>>>> would never reach the "ret" instruction of P without a
> > >>>>>>>>>> compete x86 emulation of its input. I just proved that
> > >>>>>>>>>> is a very stupid thing to say.
> > >>>>>>>>>
> > >>>>>>>>> You said that H can predict what *its* correct and
> > >>>>>>>>> complete emulation would do, and I said that doesn't make
> > >>>>>>>>> sense because H does not do correct and complete
> > >>>>>>>>> emulation. What H *must* do is predict what *the* correct
> > >>>>>>>>> and complete emulation, i.e. UTM(P,P), would do. And it
> > >>>>>>>>> fails to do that.
> > >>>>>>>> From a purely software engineering perspective H(P,P) is
> > >>>>>>>> required to to correctly determine that its correct and
> > >>>>>>>> complete x86 emulation of its input would never reach the
> > >>>>>>>> "ret" instruction of this input and H must do this in a
> > >>>>>>>> finite number of steps.
> > >>>>>>>>
> > >>>>>>>> The ordinary semantics of standard C and the conventional
> > >>>>>>>> x86 language are the entire semantics required to
> > >>>>>>>> conclusively prove that H(P,P) does correctly determine
> > >>>>>>>> that its correct and complete x86 emulation of its input
> > >>>>>>>> would never reach the "ret" instruction.
> > >>>>>>>>
> > >>>>>>>> That you disagree with easily verified software
> > >>>>>>>> engineering when you already know that this software
> > >>>>>>>> engineering is correct speaks loads about your character.
> > >>>>>>>>
> > >>>>>>>> The only computer science that need be added to this is
> > >>>>>>>> that the "ret" instruction is the final state of P and
> > >>>>>>>> that a sequence of configurations that cannot possibly
> > >>>>>>>> reach its final state is a non-halting sequence.
> > >>>>>>>
> > >>>>>>> You say that "H(P,P) is required to to correctly determine
> > >>>>>>> that its correct and complete x86 emulation of its input
> > >>>>>>> would never reach the "ret" instruction of this input". You
> > >>>>>>> seem to be assuming that H does an emulation of P, that
> > >>>>>>> this emulation includes emulating the call to H, that this
> > >>>>>>> call to H would start emulating the call to P, etc, etc,
> > >>>>>>> and so the call to P does not terminate.
> > >>>>>> Thanks for continuing to review this.
> > >>>>>>
> > >>>>>> No assumptions two years of software development derived
> > >>>>>> fully operational software that conclusively proves this.
> > >>>>>
> > >>>>> It might help people's understanding if we had a few more
> > >>>>> examples. Suppose, in addition to the normal P and H, we have
> > >>>>> two more functions as follows:
> > >>>>>
> > >>>>> void Q(void)
> > >>>>> {
> > >>>>> if (H(P, P))
> > >>>>> H2: goto H2;
> > >>>>> return;
> > >>>>> }
> > >>>>>
> > >>>>> void R(void)
> > >>>>> {
> > >>>>> H(P, P);
> > >>>>> return;
> > >>>>> }
> > >>>>>
> > >>>>> Will Q return? Will R return?
> > >>>>>
> > >>>> Yes they both return.
> > >>>> void Q(void)
> > >>>> {
> > >>>> if (H(P, P))
> > >>>> H2: goto H2;
> > >>>> return;
> > >>>> }
> > >>>>
> > >>>> void R(void)
> > >>>> {
> > >>>> H(P, P);
> > >>>> return;
> > >>>> }
> > >>>> _P()
> > >>>> [000011f0](01) 55 push ebp
> > >>>> [000011f1](02) 8bec mov ebp,esp
> > >>>> [000011f3](03) 8b4508 mov eax,[ebp+08]
> > >>>> [000011f6](01) 50 push eax
> > >>>> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
> > >>>> [000011fa](01) 51 push ecx
> > >>>> [000011fb](05) e820feffff call 00001020
> > >>>> [00001200](03) 83c408 add esp,+08
> > >>>> [00001203](02) 85c0 test eax,eax
> > >>>> [00001205](02) 7402 jz 00001209
> > >>>> [00001207](02) ebfe jmp 00001207
> > >>>> [00001209](01) 5d pop ebp
> > >>>> [0000120a](01) c3 ret
> > >>>> Size in bytes:(0027) [0000120a]
> > >>>>
> > >>>> _Q()
> > >>>> [00001210](01) 55 push ebp
> > >>>> [00001211](02) 8bec mov ebp,esp
> > >>>> [00001213](05) 68f0110000 push 000011f0
> > >>>> [00001218](05) 68f0110000 push 000011f0
> > >>>> [0000121d](05) e8fefdffff call 00001020
> > >>>> [00001222](03) 83c408 add esp,+08
> > >>>> [00001225](02) 85c0 test eax,eax
> > >>>> [00001227](02) 7402 jz 0000122b
> > >>>> [00001229](02) ebfe jmp 00001229
> > >>>> [0000122b](01) 5d pop ebp
> > >>>> [0000122c](01) c3 ret
> > >>>> Size in bytes:(0029) [0000122c]
> > >>>>
> > >>>> _main()
> > >>>> [00001250](01) 55 push ebp
> > >>>> [00001251](02) 8bec mov ebp,esp
> > >>>> [00001253](05) e8b8ffffff call 00001210
> > >>>> [00001258](02) 33c0 xor eax,eax
> > >>>> [0000125a](01) 5d pop ebp
> > >>>> [0000125b](01) c3 ret
> > >>>> Size in bytes:(0012) [0000125b]
> > >>>> machine stack stack machine assembly
> > >>>> address address data code language
> > >>>> ======== ======== ======== ========= =============
> > >>>> ...[00001250][00102048][00000000] 55 push ebp
> > >>>> ...[00001251][00102048][00000000] 8bec mov ebp,esp
> > >>>> ...[00001253][00102044][00001258] e8b8ffffff call 00001210
> > >>>> ...[00001210][00102040][00102048] 55 push ebp
> > >>>> ...[00001211][00102040][00102048] 8bec mov ebp,esp
> > >>>> ...[00001213][0010203c][000011f0] 68f0110000 push 000011f0
> > >>>> ...[00001218][00102038][000011f0] 68f0110000 push 000011f0
> > >>>> ...[0000121d][00102034][00001222] e8fefdffff call 00001020
> > >>>>
> > >>>> Begin Simulation Execution Trace Stored at:2120fc
> > >>>> Address_of_H:1020
> > >>>> ...[000011f0][002120e8][002120ec] 55 push ebp
> > >>>> ...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
> > >>>> ...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
> > >>>> ...[000011f6][002120e4][000011f0] 50 push eax
> > >>>> ...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
> > >>>> ...[000011fa][002120e0][000011f0] 51 push ecx
> > >>>> ...[000011fb][002120dc][00001200] e820feffff call 00001020
> > >>>> Infinitely Recursive Simulation Detected Simulation Stopped
> > >>>> ...[00001222][00102040][00102048] 83c408 add esp,+08
> > >>>> ...[00001225][00102040][00102048] 85c0 test eax,eax
> > >>>> ...[00001227][00102040][00102048] 7402 jz 0000122b
> > >>>> ...[0000122b][00102044][00001258] 5d pop ebp
> > >>>> ...[0000122c][00102048][00000000] c3 ret
> > >>>> ...[00001258][00102048][00000000] 33c0 xor eax,eax
> > >>>> ...[0000125a][0010204c][00100000] 5d pop ebp
> > >>>> ...[0000125b][00102050][00000000] c3 ret
> > >>>> Number of Instructions Executed(874)
> > >>>>
> > >>>> Above is:
> > >>>> int main()
> > >>>> {
> > >>>> Q();
> > >>>> //R();
> > >>>> }
> > >>>>
> > >>>> ---
> > >>>> machine stack stack machine assembly
> > >>>> address address data code language
> > >>>> ======== ======== ======== ========= =============
> > >>>> ...[00001250][00102048][00000000] 55 push ebp
> > >>>> ...[00001251][00102048][00000000] 8bec mov ebp,esp
> > >>>> ...[00001253][00102044][00001258] e8d8ffffff call 00001230
> > >>>> ...[00001230][00102040][00102048] 55 push ebp
> > >>>> ...[00001231][00102040][00102048] 8bec mov ebp,esp
> > >>>> ...[00001233][0010203c][000011f0] 68f0110000 push 000011f0
> > >>>> ...[00001238][00102038][000011f0] 68f0110000 push 000011f0
> > >>>> ...[0000123d][00102034][00001242] e8defdffff call 00001020
> > >>>>
> > >>>> Begin Simulation Execution Trace Stored at:2120fc
> > >>>> Address_of_H:1020
> > >>>> ...[000011f0][002120e8][002120ec] 55 push ebp
> > >>>> ...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
> > >>>> ...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
> > >>>> ...[000011f6][002120e4][000011f0] 50 push eax
> > >>>> ...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
> > >>>> ...[000011fa][002120e0][000011f0] 51 push ecx
> > >>>> ...[000011fb][002120dc][00001200] e820feffff call 00001020
> > >>>> Infinitely Recursive Simulation Detected Simulation Stopped
> > >>>> ...[00001242][00102040][00102048] 83c408 add esp,+08
> > >>>> ...[00001245][00102044][00001258] 5d pop ebp
> > >>>> ...[00001246][00102048][00000000] c3 ret
> > >>>> ...[00001258][00102048][00000000] 33c0 xor eax,eax
> > >>>> ...[0000125a][0010204c][00100000] 5d pop ebp
> > >>>> ...[0000125b][00102050][00000000] c3 ret
> > >>>> Number of Instructions Executed(872)
> > >>>>
> > >>>> Above is:
> > >>>> int main()
> > >>>> {
> > >>>> //Q();
> > >>>> R();
> > >>>> }
> > >>>
> > >>> Right, so we're getting somewhere. Can you explain why Q()
> > >>> returns, and P(P) doesn't, when they both do the same thing in
> > >>> the same way?
> > >> int main()
> > >> {
> > >> P(P);
> > >> }
> > >>
> > >> does return.
> > >>
> > >> The correct and complete x86 emulation of its input by H(P,P)
> > >> would never reach the "ret" instruction of P because both H and
> > >> P would remain stuck in infinitely nested emulation.
> > >
> > > These last two statements of yours are a contradiction.
> > >
> > > If P(P) returns, then a CORRECT emulation of it will reach the
> > > ret instruction. An emulation that runs forever, when P(P) does
> > > not, is not a correct emulation.
> >
> > The ordinary semantics of standard C and the conventional x86
> > language are the entire semantics required to conclusively prove
> > that H(P,P) *does correctly predict*
> > that its correct and complete x86 emulation of its input would never
> > reach the "ret" instruction (final state) of this input thus never
> > halts. The correct and complete x86 emulation of its input by H
> > would never reach the "ret" instruction of P because both H and P
> > would remain stuck in infinitely nested emulation.
> >
> > I need reviewers like you so that I can *fine tune* my words.
>
> If you are saying that P(P) returns, but that a correct and complete
> x86 emulation of P(P) does not, then I think you are going to have to
> change either "correct" or "emulation" to some very different word.
>
> > A halt decider must compute the mapping from its inputs to an
> > accept or reject state on the basis of the actual behavior of these
> > actual inputs.
>
> Exactly. The actual behaviour. Not the behaviour it would have if
> things were different. In particular, you need to take into account
> H's ability to detect infinite loops.
Olcott has not shared his method for detecting infinite loops; it is
likely that he can only detect the trivial case of x86 opcodes EB FE
which isn't good enough as an "infinite loop", or more precisely
non-halting behaviour, can take many forms.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-06-25 20:24 +0100 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <871qvcwnq9.fsf@bsb.me.uk> |
| In reply to | #52960 |
Paul N <gw7rib@aol.com> writes: > If P(P) returns, then a CORRECT emulation of it will reach the ret > instruction. An emulation that runs forever, when P(P) does not, is > not a correct emulation. You have missed the magic words. We know a few things for certain about PO's ever-so-secret code. One is that whatever it is the latest mantra means "the correct simulation of the input to H(P,P)" is not the same as the correct simulation of P(P). Why? Well PO is explicitly not talking about an H that answers the halting problem, as translated into the language of C functions returning. He hasn't been talking about that for years, but in the past he was too clear. He used to say things like "P(P) only halts because..." as if the reason excused the wrong answer. He used to say that P(P) halts but it would not halt is H didn't stop it (famously "if line 15 were commented out"). All was too obvious. The latest wording is proving more effective at sucking people down the rabbit hole. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Paul N <gw7rib@aol.com> |
|---|---|
| Date | 2022-06-25 12:33 -0700 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <486e2f52-c19c-49ef-9db9-1e7a3c7391b9n@googlegroups.com> |
| In reply to | #52970 |
On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote: > Paul N <gw7...@aol.com> writes: > > > If P(P) returns, then a CORRECT emulation of it will reach the ret > > instruction. An emulation that runs forever, when P(P) does not, is > > not a correct emulation. > You have missed the magic words. We know a few things for certain about > PO's ever-so-secret code. One is that whatever it is the latest mantra > means "the correct simulation of the input to H(P,P)" is not the same as > the correct simulation of P(P). Why? Well PO is explicitly not talking > about an H that answers the halting problem, as translated into the > language of C functions returning. > > He hasn't been talking about that for years, but in the past he was too > clear. He used to say things like "P(P) only halts because..." as if > the reason excused the wrong answer. He used to say that P(P) halts but > it would not halt is H didn't stop it (famously "if line 15 were > commented out"). All was too obvious. > > The latest wording is proving more effective at sucking people down the > rabbit hole. Yes, perhaps I'm wasting my time here. I have got out of him now that: >> The correct and complete emulation of the input to H(P,P) has halting >> behavior that is provably different than the the direct execution of P(P). >> "Common sense" tells you that they must be the same empirical proof >> proves that they are not the same.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-25 14:49 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <kYSdneJoYN5H-yr_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52972 |
On 6/25/2022 2:33 PM, Paul N wrote:
> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
>> Paul N <gw7...@aol.com> writes:
>>
>>> If P(P) returns, then a CORRECT emulation of it will reach the ret
>>> instruction. An emulation that runs forever, when P(P) does not, is
>>> not a correct emulation.
>> You have missed the magic words. We know a few things for certain about
>> PO's ever-so-secret code. One is that whatever it is the latest mantra
>> means "the correct simulation of the input to H(P,P)" is not the same as
>> the correct simulation of P(P). Why? Well PO is explicitly not talking
>> about an H that answers the halting problem, as translated into the
>> language of C functions returning.
>>
>> He hasn't been talking about that for years, but in the past he was too
>> clear. He used to say things like "P(P) only halts because..." as if
>> the reason excused the wrong answer. He used to say that P(P) halts but
>> it would not halt is H didn't stop it (famously "if line 15 were
>> commented out"). All was too obvious.
>>
>> The latest wording is proving more effective at sucking people down the
>> rabbit hole.
>
> Yes, perhaps I'm wasting my time here. I have got out of him now that:
>
>>> The correct and complete emulation of the input to H(P,P) has halting
>>> behavior that is provably different than the the direct execution of P(P).
>
>>> "Common sense" tells you that they must be the same empirical proof
>>> proves that they are not the same.
>
Empirical proof is a term that is weaker than the actual proof:
Someone that very recently coached me on how to write formal
mathematical proofs of my claim indicated that I must specify the
precise semantics that I am referencing:
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly predict that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.
This same proof shows that P(P) halts.
When we specify the precise semantics the proof gains much more than
mere "empirical" mathematical rigor.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
P(P);
}
_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]
_main()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) e8d3ffffff call 000011f0
[0000121d](03) 83c404 add esp,+04
[00001220](02) 33c0 xor eax,eax
[00001222](01) 5d pop ebp
[00001223](01) c3 ret
Size in bytes:(0020) [00001223]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001210][00101fba][00000000] 55 push ebp
[00001211][00101fba][00000000] 8bec mov ebp,esp
[00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
[00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
[000011f0][00101fae][00101fba] 55 push ebp // enter executed P
[000011f1][00101fae][00101fba] 8bec mov ebp,esp
[000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
[000011f6][00101faa][000011f0] 50 push eax // push P
[000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00101fa6][000011f0] 51 push ecx // push P
[000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
Begin Simulation Execution Trace Stored at:21206e
Address_of_H:1020
[000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
[000011f1][0021205a][0021205e] 8bec mov ebp,esp
[000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
[000011f6][00212056][000011f0] 50 push eax // push P
[000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00212052][000011f0] 51 push ecx // push P
[000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
Infinitely Recursive Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.
[00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
executed P
[00001203][00101fae][00101fba] 85c0 test eax,eax
[00001205][00101fae][00101fba] 7402 jz 00001209
[00001209][00101fb2][0000121d] 5d pop ebp
[0000120a][00101fb6][000011f0] c3 ret // return from
executed P
[0000121d][00101fba][00000000] 83c404 add esp,+04
[00001220][00101fba][00000000] 33c0 xor eax,eax
[00001222][00101fbe][00100000] 5d pop ebp
[00001223][00101fc2][00000000] c3 ret // ret from main
Number of Instructions Executed(878) / 67 = 13 pages
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-25 17:35 -0400 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <RcLtK.141529$ssF.104375@fx14.iad> |
| In reply to | #52974 |
On 6/25/22 3:49 PM, olcott wrote:
> On 6/25/2022 2:33 PM, Paul N wrote:
>> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
>>> Paul N <gw7...@aol.com> writes:
>>>
>>>> If P(P) returns, then a CORRECT emulation of it will reach the ret
>>>> instruction. An emulation that runs forever, when P(P) does not, is
>>>> not a correct emulation.
>>> You have missed the magic words. We know a few things for certain about
>>> PO's ever-so-secret code. One is that whatever it is the latest mantra
>>> means "the correct simulation of the input to H(P,P)" is not the same as
>>> the correct simulation of P(P). Why? Well PO is explicitly not talking
>>> about an H that answers the halting problem, as translated into the
>>> language of C functions returning.
>>>
>>> He hasn't been talking about that for years, but in the past he was too
>>> clear. He used to say things like "P(P) only halts because..." as if
>>> the reason excused the wrong answer. He used to say that P(P) halts but
>>> it would not halt is H didn't stop it (famously "if line 15 were
>>> commented out"). All was too obvious.
>>>
>>> The latest wording is proving more effective at sucking people down the
>>> rabbit hole.
>>
>> Yes, perhaps I'm wasting my time here. I have got out of him now that:
>>
>>>> The correct and complete emulation of the input to H(P,P) has halting
>>>> behavior that is provably different than the the direct execution of
>>>> P(P).
>>
>>>> "Common sense" tells you that they must be the same empirical proof
>>>> proves that they are not the same.
>>
>
> Empirical proof is a term that is weaker than the actual proof:
>
> Someone that very recently coached me on how to write formal
> mathematical proofs of my claim indicated that I must specify the
> precise semantics that I am referencing:
>
> The ordinary semantics of standard C and the conventional x86 language
> are the entire semantics required to conclusively prove that H(P,P) does
> correctly predict that its correct and complete x86 emulation of its
> input would never reach the "ret" instruction (final state) of this
> input thus never halts.
>
But, but this definition, H needs to be a CORRECT emulation of its
input, which means that the emulation of H(P,P) needs to match the
bahavior of an actual call to H(P,P).
Since the conclusion of this argument is that H(P,P) is correctly
returning 0, then for the emulation to actaully be correct, it needs to
match that behavior.
This mean that it CAN NOT appear that H(P,P) never returns in the
correct emulation of the input, but MUST appear as a returning of 0.
> This same proof shows that P(P) halts.
>
> When we specify the precise semantics the proof gains much more than
> mere "empirical" mathematical rigor.
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> P(P);
> }
>
> _P()
> [000011f0](01) 55 push ebp
> [000011f1](02) 8bec mov ebp,esp
> [000011f3](03) 8b4508 mov eax,[ebp+08]
> [000011f6](01) 50 push eax
> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
> [000011fa](01) 51 push ecx
> [000011fb](05) e820feffff call 00001020
>
> [00001200](03) 83c408 add esp,+08
> [00001203](02) 85c0 test eax,eax
> [00001205](02) 7402 jz 00001209
> [00001207](02) ebfe jmp 00001207
> [00001209](01) 5d pop ebp
> [0000120a](01) c3 ret
> Size in bytes:(0027) [0000120a]
>
> _main()
> [00001210](01) 55 push ebp
> [00001211](02) 8bec mov ebp,esp
> [00001213](05) 68f0110000 push 000011f0
> [00001218](05) e8d3ffffff call 000011f0
> [0000121d](03) 83c404 add esp,+04
> [00001220](02) 33c0 xor eax,eax
> [00001222](01) 5d pop ebp
> [00001223](01) c3 ret
> Size in bytes:(0020) [00001223]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [00001210][00101fba][00000000] 55 push ebp
> [00001211][00101fba][00000000] 8bec mov ebp,esp
> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
> [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
> [000011f1][00101fae][00101fba] 8bec mov ebp,esp
> [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
> [000011f6][00101faa][000011f0] 50 push eax // push P
> [000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
> [000011fa][00101fa6][000011f0] 51 push ecx // push P
> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
>
> Begin Simulation Execution Trace Stored at:21206e
> Address_of_H:1020
> [000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
> [000011f1][0021205a][0021205e] 8bec mov ebp,esp
> [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
> [000011f6][00212056][000011f0] 50 push eax // push P
> [000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
> [000011fa][00212052][000011f0] 51 push ecx // push P
> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
> Infinitely Recursive Simulation Detected Simulation Stopped
>
> H knows its own machine address and on this basis it can easily
> examine its stored execution_trace of P (see above) to determine:
> (a) P is calling H with the same arguments that H was called with.
> (b) No instructions in P could possibly escape this otherwise infinitely
> recursive emulation.
and (b) is proved incorrect from the definition of correctly emulating
an actual call of H(P,P), which is known to return 0 for this case.
> (c) H aborts its emulation of P before its call to H is emulated.
but based on a FALSE assumption about what that emulation would do.
You (b) can ONLY be established based on an assumption that H actually
does a complete and correct emulation, which is broken by the actual
fact that it will abort it simulation.
>
> [00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
> executed P
> [00001203][00101fae][00101fba] 85c0 test eax,eax
> [00001205][00101fae][00101fba] 7402 jz 00001209
> [00001209][00101fb2][0000121d] 5d pop ebp
> [0000120a][00101fb6][000011f0] c3 ret // return from
> executed P
> [0000121d][00101fba][00000000] 83c404 add esp,+04
> [00001220][00101fba][00000000] 33c0 xor eax,eax
> [00001222][00101fbe][00100000] 5d pop ebp
> [00001223][00101fc2][00000000] c3 ret // ret from main
> Number of Instructions Executed(878) / 67 = 13 pages
>
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-06-26 00:28 +0100 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <87pmiwuxv0.fsf@bsb.me.uk> |
| In reply to | #52972 |
Paul N <gw7rib@aol.com> writes: > On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote: >> The latest wording is proving more effective at sucking people down the >> rabbit hole. > > Yes, perhaps I'm wasting my time here. I have got out of him now that: > >>> The correct and complete emulation of the input to H(P,P) has halting >>> behavior that is provably different than the the direct execution of >>> P(P). Not to diminish the achievement of getting any clear statements from PO, but that's not new. I made a note on June 13th that he'd come clean about this: "Before my research no one was aware of the possibility that the correctly simulated input to H(P,P) could possibly have behavior that is different than the directly executed P(P)." -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-25 20:34 -0400 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <JQNtK.27973$nZ1.21282@fx05.iad> |
| In reply to | #52982 |
On 6/25/22 7:28 PM, Ben Bacarisse wrote: > Paul N <gw7rib@aol.com> writes: > >> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote: > >>> The latest wording is proving more effective at sucking people down the >>> rabbit hole. >> >> Yes, perhaps I'm wasting my time here. I have got out of him now that: >> >>>> The correct and complete emulation of the input to H(P,P) has halting >>>> behavior that is provably different than the the direct execution of >>>> P(P). > > Not to diminish the achievement of getting any clear statements from PO, > but that's not new. I made a note on June 13th that he'd come clean > about this: > > "Before my research no one was aware of the possibility that the > correctly simulated input to H(P,P) could possibly have behavior that > is different than the directly executed P(P)." > Which, As I have started to point out, means that his P isn't defined correctly (and maybe H has limits so it can't be written correctly). The issue is the actual definition of what P (or H^) needs to b setup to do is ask H what it will do given its input. This is most often notated with simething like H(P,P) or H <H^> <H^> or the similar, but these are just mechanical notations based on how H is expected to interprete its input, but ultimately, P needs to ask H what P(P) will do. If it isn't H(P,P), then P needs to be changed to make that request. If H can't be asked that, then H has just proved it isn't the needed halt decider, as the needed Halt Decider needs to be able to answer for ALL Machines (not just all inputs that can be represented to it). Note also, the question in the requirements is self-referential, refering by name to the machine to be decided on and the halt decider it is to use, but in the actual implementation, because Turing machies don't really support that sort of self-reference, we are actually running a computation that just happens (by design) ask about the machine that is the "impossible" machine, built on the Halt Decider that we just happen to be using.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-06-25 19:54 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] |
| Message-ID | <t98aop$3l8je$1@dont-email.me> |
| In reply to | #52982 |
On 6/25/2022 6:28 PM, Ben Bacarisse wrote: > Paul N <gw7rib@aol.com> writes: > >> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote: > >>> The latest wording is proving more effective at sucking people down the >>> rabbit hole. >> >> Yes, perhaps I'm wasting my time here. I have got out of him now that: >> >>>> The correct and complete emulation of the input to H(P,P) has halting >>>> behavior that is provably different than the the direct execution of >>>> P(P). > > Not to diminish the achievement of getting any clear statements from PO, > but that's not new. I made a note on June 13th that he'd come clean > about this: > > "Before my research no one was aware of the possibility that the > correctly simulated input to H(P,P) could possibly have behavior that > is different than the directly executed P(P)." > I still stand by that as most probably true. (a) What I stand by as absolutely true is that the complete and correct x86 emulation of the input to H(P,P) by H never reaches the "ret" instruction of P. (b) The direct execution of P(P) does reach its "ret" instruction. The above two are proven to be verified facts entirely on the basis of the semantics of the x86 language. (c) 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. When we know that (a)(b) and (c) are true then it necessarily follows that anyone saying that H must decide on the basis of the behavior of P(P) is necessarily incorrect. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-06-25 19:55 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] |
| Message-ID | <t98apo$3l8o1$1@dont-email.me> |
| In reply to | #52982 |
On 6/25/2022 6:28 PM, Ben Bacarisse wrote: > Paul N <gw7rib@aol.com> writes: > >> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote: > >>> The latest wording is proving more effective at sucking people down the >>> rabbit hole. >> >> Yes, perhaps I'm wasting my time here. I have got out of him now that: >> >>>> The correct and complete emulation of the input to H(P,P) has halting >>>> behavior that is provably different than the the direct execution of >>>> P(P). > > Not to diminish the achievement of getting any clear statements from PO, > but that's not new. I made a note on June 13th that he'd come clean > about this: > > "Before my research no one was aware of the possibility that the > correctly simulated input to H(P,P) could possibly have behavior that > is different than the directly executed P(P)." > I still stand by that as most probably true. (a) What I stand by as absolutely true is that the complete and correct x86 emulation of the input to H(P,P) by H never reaches the "ret" instruction of P. (b) The direct execution of P(P) does reach its "ret" instruction. The above two are proven to be verified facts entirely on the basis of the semantics of the x86 language. (c) 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. When we know that (a)(b) and (c) are true then it necessarily follows that anyone saying that H must decide on the basis of the behavior of P(P) is necessarily incorrect. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-06-25 19:56 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <t98ar8$3l8qv$1@dont-email.me> |
| In reply to | #52982 |
On 6/25/2022 6:28 PM, Ben Bacarisse wrote: > Paul N <gw7rib@aol.com> writes: > >> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote: > >>> The latest wording is proving more effective at sucking people down the >>> rabbit hole. >> >> Yes, perhaps I'm wasting my time here. I have got out of him now that: >> >>>> The correct and complete emulation of the input to H(P,P) has halting >>>> behavior that is provably different than the the direct execution of >>>> P(P). > > Not to diminish the achievement of getting any clear statements from PO, > but that's not new. I made a note on June 13th that he'd come clean > about this: > > "Before my research no one was aware of the possibility that the > correctly simulated input to H(P,P) could possibly have behavior that > is different than the directly executed P(P)." > I still stand by that as most probably true. (a) What I stand by as absolutely true is that the complete and correct x86 emulation of the input to H(P,P) by H never reaches the "ret" instruction of P. (b) The direct execution of P(P) does reach its "ret" instruction. The above two are proven to be verified facts entirely on the basis of the semantics of the x86 language. (c) 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. When we know that (a)(b) and (c) are true then it necessarily follows that anyone saying that H must decide on the basis of the behavior of P(P) is necessarily incorrect. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-25 19:57 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] |
| Message-ID | <tbudnSWgvPlmMyr_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #52982 |
On 6/25/2022 6:28 PM, Ben Bacarisse wrote: > Paul N <gw7rib@aol.com> writes: > >> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote: > >>> The latest wording is proving more effective at sucking people down the >>> rabbit hole. >> >> Yes, perhaps I'm wasting my time here. I have got out of him now that: >> >>>> The correct and complete emulation of the input to H(P,P) has halting >>>> behavior that is provably different than the the direct execution of >>>> P(P). > > Not to diminish the achievement of getting any clear statements from PO, > but that's not new. I made a note on June 13th that he'd come clean > about this: > > "Before my research no one was aware of the possibility that the > correctly simulated input to H(P,P) could possibly have behavior that > is different than the directly executed P(P)." > I still stand by that as most probably true. (a) What I stand by as absolutely true is that the complete and correct x86 emulation of the input to H(P,P) by H never reaches the "ret" instruction of P. (b) The direct execution of P(P) does reach its "ret" instruction. The above two are proven to be verified facts entirely on the basis of the semantics of the x86 language. (c) 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. When we know that (a)(b) and (c) are true then it necessarily follows that anyone saying that H must decide on the basis of the behavior of P(P) is necessarily incorrect. -- 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-06-25 21:47 -0400 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] |
| Message-ID | <9VOtK.325093$5fVf.149518@fx09.iad> |
| In reply to | #52993 |
On 6/25/22 8:57 PM, olcott wrote: > On 6/25/2022 6:28 PM, Ben Bacarisse wrote: >> Paul N <gw7rib@aol.com> writes: >> >>> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote: >> >>>> The latest wording is proving more effective at sucking people down the >>>> rabbit hole. >>> >>> Yes, perhaps I'm wasting my time here. I have got out of him now that: >>> >>>>> The correct and complete emulation of the input to H(P,P) has halting >>>>> behavior that is provably different than the the direct execution of >>>>> P(P). >> >> Not to diminish the achievement of getting any clear statements from PO, >> but that's not new. I made a note on June 13th that he'd come clean >> about this: >> >> "Before my research no one was aware of the possibility that the >> correctly simulated input to H(P,P) could possibly have behavior that >> is different than the directly executed P(P)." >> > > I still stand by that as most probably true. but it means that P wasn't built right. Remember P with the special input given to it is supposed to ask H what P does when given that input. If H(P,P) doesn't ask what P(P) does, (by that being the behavior of the input to H(P,P)], then P calling H(P,P) says it was designed wrong, and you need to change that call in P. If you can't ask H that question, then H just plain fails, as H is supposed to be able to be asked about ANY computation (Machine/Input Combination), and not just what H allows its input to represent. > > (a) What I stand by as absolutely true is that the complete and correct > x86 emulation of the input to H(P,P) by H never reaches the "ret" > instruction of P. But only if H actaully DOES a complete and correct x86 emulation of that input. Which means it can't 'abort' its emulation, and thus can't answer in finite time until you can show how to do an infinite emulation in finite steos. When H aborts its emulation and returns 0, then an actual complete and correct emulation done by an independent emulator shows it will reach teh ret instruction, just like P(P) does. > > (b) The direct execution of P(P) does reach its "ret" instruction. > > The above two are proven to be verified facts entirely on the basis of > the semantics of the x86 language. > > (c) 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. > No, a Halt Decider must compute the Halting Mapping, from the computation represented by its input based on the behavior of that actual machine specified by its input. > When we know that (a)(b) and (c) are true then it necessarily follows > that anyone saying that H must decide on the basis of the behavior of > P(P) is necessarily incorrect. > WHY? You have (c) somewhat backwards. The decider determines the way to specify the input, but once you accept that the input actually specifies that machine in question, the behavior of the actual machine is controlling. Part of your problem is that you keep on trying to define an input that doesn't actually fully specify the machine. Remember the Computation is more than just the "C function", but includes all of the algorithms of everything it calls. Thus by your x86 representation, you need to include the x86 code of everything it calls.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-25 14:39 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <LvWdnZNE0pju-Sr_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52970 |
On 6/25/2022 2:24 PM, Ben Bacarisse wrote:
> Paul N <gw7rib@aol.com> writes:
>
>> If P(P) returns, then a CORRECT emulation of it will reach the ret
>> instruction. An emulation that runs forever, when P(P) does not, is
>> not a correct emulation.
>
> You have missed the magic words. We know a few things for certain about
> PO's ever-so-secret code. One is that whatever it is the latest mantra
> means "the correct simulation of the input to H(P,P)" is not the same as
> the correct simulation of P(P). Why? Well PO is explicitly not talking
> about an H that answers the halting problem, as translated into the
> language of C functions returning.
>
> He hasn't been talking about that for years, but in the past he was too
> clear. He used to say things like "P(P) only halts because..." as if
> the reason excused the wrong answer. He used to say that P(P) halts but
> it would not halt is H didn't stop it (famously "if line 15 were
> commented out"). All was too obvious.
>
> The latest wording is proving more effective at sucking people down the
> rabbit hole.
>
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.
It is provable that the behavior of the correct and complete x86
emulation of the input to H(P,P) never halts and the direct execution of
P(P) halts. H is required to decide on the basis of the former and not
allowed to decide on the basis of the latter unless it is the same as
the former.
These behaviors only diverge when H and P are defined to have this
pathological relationship to each other:
For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
None of the textbook authors were aware that these behaviors could
possibly diverge because they never fully considered the effect of a
simulating halt decider applied to the halting problem counter-examples.
--
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-06-25 19:21 -0400 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <iMMtK.157475$ntj.15039@fx15.iad> |
| In reply to | #52973 |
On 6/25/22 3:39 PM, olcott wrote: > On 6/25/2022 2:24 PM, Ben Bacarisse wrote: >> Paul N <gw7rib@aol.com> writes: >> >>> If P(P) returns, then a CORRECT emulation of it will reach the ret >>> instruction. An emulation that runs forever, when P(P) does not, is >>> not a correct emulation. >> >> You have missed the magic words. We know a few things for certain about >> PO's ever-so-secret code. One is that whatever it is the latest mantra >> means "the correct simulation of the input to H(P,P)" is not the same as >> the correct simulation of P(P). Why? Well PO is explicitly not talking >> about an H that answers the halting problem, as translated into the >> language of C functions returning. >> >> He hasn't been talking about that for years, but in the past he was too >> clear. He used to say things like "P(P) only halts because..." as if >> the reason excused the wrong answer. He used to say that P(P) halts but >> it would not halt is H didn't stop it (famously "if line 15 were >> commented out"). All was too obvious. >> >> The latest wording is proving more effective at sucking people down the >> rabbit hole. >> > > 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. > > It is provable that the behavior of the correct and complete x86 > emulation of the input to H(P,P) never halts and the direct execution of > P(P) halts. H is required to decide on the basis of the former and not > allowed to decide on the basis of the latter unless it is the same as > the former. Which means that P isn't the "impossible program" required by the proof. P needs to ask H about itself applied to its input. If H(P,P) isn't that for P(P), then either P isn't defined right to ask H the proper question, of H isn't interpreeting its input correctly. Either way, you LIE that you are doing things according to the proof. > > These behaviors only diverge when H and P are defined to have this > pathological relationship to each other: > > For any program H that might determine if programs halt, a > "pathological" > program P, called with some input, can pass its own source and its > input to > H and then specifically do the opposite of what H predicts P will > do. No H > can exist that handles this case. > https://en.wikipedia.org/wiki/Halting_problem > > None of the textbook authors were aware that these behaviors could > possibly diverge because they never fully considered the effect of a > simulating halt decider applied to the halting problem counter-examples. > Because they CAN'T and have H and P meet their actual requirements. DEFINITION. If H(P,P) doesn't look at the behavior of P(P), then P should call H with that sequence, but whatever it needs to do to represent that. If H can't have an input that represents P(P), then that shows that H can't correctly decide that problem, and thus fails to be the needed decider. Remember, the requriement is to find an H that can decide on all MACHINE / INPUT combinations, NOT all "inputs" that can be given to it.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-26 00:42 +0100 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <20220626004251.00003fa0@reddwarf.jmc> |
| In reply to | #52973 |
On Sat, 25 Jun 2022 14:39:29 -0500 olcott <NoOne@NoWhere.com> wrote: > On 6/25/2022 2:24 PM, Ben Bacarisse wrote: > > Paul N <gw7rib@aol.com> writes: > > > >> If P(P) returns, then a CORRECT emulation of it will reach the ret > >> instruction. An emulation that runs forever, when P(P) does not, is > >> not a correct emulation. > > > > You have missed the magic words. We know a few things for certain > > about PO's ever-so-secret code. One is that whatever it is the > > latest mantra means "the correct simulation of the input to H(P,P)" > > is not the same as the correct simulation of P(P). Why? Well PO > > is explicitly not talking about an H that answers the halting > > problem, as translated into the language of C functions returning. > > > > He hasn't been talking about that for years, but in the past he was > > too clear. He used to say things like "P(P) only halts because..." > > as if the reason excused the wrong answer. He used to say that > > P(P) halts but it would not halt is H didn't stop it (famously "if > > line 15 were commented out"). All was too obvious. > > > > The latest wording is proving more effective at sucking people down > > the rabbit hole. > > > > 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. > > It is provable that the behavior of the correct and complete x86 > emulation of the input to H(P,P) never halts and the direct execution > of P(P) halts. H is required to decide on the basis of the former and > not allowed to decide on the basis of the latter unless it is the > same as the former. Richard Damon says: Which means that P isn't the "impossible program" required by the proof. P needs to ask H about itself applied to its input. If H(P,P) isn't that for P(P), then either P isn't defined right to ask H the proper question, of H isn't interpreeting (sic) its input correctly. Either way, you LIE that you are doing things according to the proof. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-06-24 23:23 +0100 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <87a6a1wvjt.fsf@bsb.me.uk> |
| In reply to | #52901 |
Paul N <gw7rib@aol.com> writes: > You say that "H(P,P) is required to to correctly determine that its > correct and complete x86 emulation of its input would never reach the > "ret" instruction of this input". Can I just check that you know this is not what H is supposed to do? PO has been searching for some from of words that can stir up enough mud that the fact that H is wrong can be to some extent obscured. He seems to have hit pay dirt with this latest phrasing. Everyone seem happy to talk to PO on his own terms (and that's fine -- it's what he posts for), but in the C-function version of the problem, H(X,Y) != 0 if and only if X(Y) "halts". I lost interest when he stopped talking about this problem which he knows in not decidable. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-24 17:58 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] |
| Message-ID | <AMKdnVNiDukN3Cv_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52915 |
On 6/24/2022 5:23 PM, Ben Bacarisse wrote: > Paul N <gw7rib@aol.com> writes: > >> You say that "H(P,P) is required to to correctly determine that its >> correct and complete x86 emulation of its input would never reach the >> "ret" instruction of this input". > > Can I just check that you know this is not what H is supposed to do? PO > has been searching for some from of words that can stir up enough mud > that the fact that H is wrong can be to some extent obscured. He seems > to have hit pay dirt with this latest phrasing. > > Everyone seem happy to talk to PO on his own terms (and that's fine -- > it's what he posts for), but in the C-function version of the problem, > H(X,Y) != 0 if and only if X(Y) "halts". I lost interest when he > stopped talking about this problem which he knows in not decidable. > It is common knowledge (in computer science) that a halt decider must compute the mapping from actual its inputs to an accept or reject state on the basis of the actual behavior that is actually specified by its actual inputs. The ordinary semantics of standard C and the conventional x86 language are the entire semantics required to conclusively prove that H(P,P) does correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction (final state) of this input thus never halts. THERE IS NO ESCAPE FROM THIS BECAUSE IT IS A TAUTOLOGY. -- 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-06-24 22:00 -0400 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] |
| Message-ID | <T_ttK.317387$5fVf.41101@fx09.iad> |
| In reply to | #52917 |
On 6/24/22 6:58 PM, olcott wrote: > On 6/24/2022 5:23 PM, Ben Bacarisse wrote: >> Paul N <gw7rib@aol.com> writes: >> >>> You say that "H(P,P) is required to to correctly determine that its >>> correct and complete x86 emulation of its input would never reach the >>> "ret" instruction of this input". >> >> Can I just check that you know this is not what H is supposed to do? PO >> has been searching for some from of words that can stir up enough mud >> that the fact that H is wrong can be to some extent obscured. He seems >> to have hit pay dirt with this latest phrasing. >> >> Everyone seem happy to talk to PO on his own terms (and that's fine -- >> it's what he posts for), but in the C-function version of the problem, >> H(X,Y) != 0 if and only if X(Y) "halts". I lost interest when he >> stopped talking about this problem which he knows in not decidable. >> > > It is common knowledge (in computer science) that a halt decider must > compute the mapping from actual its inputs to an accept or reject state > on the basis of the actual behavior that is actually specified by its > actual inputs. > > The ordinary semantics of standard C and the conventional x86 language > are the entire semantics required to conclusively prove that H(P,P) does > correctly determine that its correct and complete x86 emulation of its > input would never reach the "ret" instruction (final state) of this > input thus never halts. > > THERE IS NO ESCAPE FROM THIS BECAUSE IT IS A TAUTOLOGY. > Wrong. If H(P,P) does the correct and complete x86 emulation of its input, i9t never gives an answer for H(P,P). Maybe in your mind it makes the dertemination but not return it, but that isn't the defintion of a decider determinng. If H(P,P) does make a determination about its simulation of H(P,P) being non-halting, it does so based on unsound logic, as your logic has it presume that H DOES a complete and correct emulation, but if it makes such a determination and returns the non-halting answer, it never did a complete and correct emulation, so the premise it based its logic on is refuted.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-22 21:52 -0400 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <pHPsK.102533$ssF.36709@fx14.iad> |
| In reply to | #52817 |
On 6/22/22 9:37 PM, olcott wrote:
> On 6/22/2022 8:21 PM, Dennis Bush wrote:
>> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
>>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>> #define u32 uint32_t
>>>>>>>>>>>>>
>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>
>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>> return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> _P()
>>>>>>>>>>>>> [000010d2](01) 55 push ebp
>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>> [000010d8](01) 50 push eax
>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>> [000010dc](01) 51 push ecx
>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
>>>>>>>>>>>>> [000010ec](01) c3 ret
>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every sufficiently competent software engineer can easily
>>>>>>>>>>>>> verify
>>>>>>>>>>>>> that the complete and correct x86 emulation of the input to
>>>>>>>>>>>>> H(P,P)
>>>>>>>>>>>>> by H would never reach the "ret" instruction of P because
>>>>>>>>>>>>> both H
>>>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If H does correctly determine that this is the case in a
>>>>>>>>>>>>> finite
>>>>>>>>>>>>> number of steps then H could reject its input on this
>>>>>>>>>>>>> basis. Here
>>>>>>>>>>>>> are the details of exactly how H does this in a finite
>>>>>>>>>>>>> number of
>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>
>>>>>>>>>>>>> typedef struct Decoded
>>>>>>>>>>>>> {
>>>>>>>>>>>>> u32 Address;
>>>>>>>>>>>>> u32 ESP; // Current value of ESP
>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
>>>>>>>>>>>>> u32 NumBytes;
>>>>>>>>>>>>> u32 Simplified_Opcode;
>>>>>>>>>>>>> u32 Decode_Target;
>>>>>>>>>>>>> } Decoded_Line_Of_Code;
>>>>>>>>>>>>>
>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 //
>>>>>>>>>>>>> call H
>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>
>>>>>>>>>>>>> // actual fully operational code in the x86utm operating
>>>>>>>>>>>>> system
>>>>>>>>>>>>> u32 H(u32 P, u32 I)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> HERE:
>>>>>>>>>>>>> u32 End_Of_Code;
>>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
>>>>>>>>>>>>> u32 code_end = get_code_end(P);
>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>>>>>>>> Registers* master_state = (Registers*)
>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>> Registers* slave_state = (Registers*)
>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
>>>>>>>>>>>>> u32 execution_trace =
>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>>>>>>>>>> * 1000);
>>>>>>>>>>>>>
>>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
>>>>>>>>>>>>> __asm mov End_Of_Code, eax
>>>>>>>>>>>>>
>>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
>>>>>>>>>>>>> execution_trace);
>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P,
>>>>>>>>>>>>> I))
>>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> H knows its own machine address and on this basis it can
>>>>>>>>>>>>> easily
>>>>>>>>>>>>> examine its stored execution_trace of P and determine:
>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was
>>>>>>>>>>>>> called with.
>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise
>>>>>>>>>>>>> infinitely recursive emulation.
>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is
>>>>>>>>>>>>> invoked.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Technically competent software engineers may not know this
>>>>>>>>>>>>> computer
>>>>>>>>>>>>> science:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> computation that halts … the Turing machine will halt
>>>>>>>>>>>>> whenever it
>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>
>>>>>>>>>>>>> The "ret" instruction of P is its final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>>>> Automata.
>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>> {
>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>>>>>>>>> Number of Instructions Executed(16120)
>>>>>>>>>>>>
>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been decided
>>>>>>>>>>>> correctly.
>>>>>>>>>>>> QED.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You and Richard are insufficiently technically competent at
>>>>>>>>>>> software
>>>>>>>>>>> engineering not meeting these specs:
>>>>>>>>>>>
>>>>>>>>>>> A software engineer must be an expert in: the C programming
>>>>>>>>>>> language,
>>>>>>>>>>> the x86 programming language, exactly how C translates into
>>>>>>>>>>> x86 and
>>>>>>>>>>> the ability to recognize infinite recursion at the x86 assembly
>>>>>>>>>>> language level. No knowledge of the halting problem is required.
>>>>>>>>>>
>>>>>>>>>> I cannot speak for Richard but I have 30+ years C++
>>>>>>>>>> experience; I also
>>>>>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
>>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite
>>>>>>>>>> recursion;
>>>>>>>>>> the problem is that you cannot recognize the fact that the
>>>>>>>>>> infinite
>>>>>>>>>> recursion only manifests as part of your invalid simulation-based
>>>>>>>>>> omnishambles:
>>>>>>>>> If you are competent then you already know this is true and lie
>>>>>>>>> about it:
>>>>>>>>> Every sufficiently competent software engineer can easily
>>>>>>>>> verify that
>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px)
>>>>>>>>> by H
>>>>>>>>> would never reach the "ret" instruction of P because both H and
>>>>>>>>> P would
>>>>>>>>> remain stuck in infinitely recursive emulation.
>>>>>>>>
>>>>>>>> H (if it was constructed correctly) is a computation, and a
>>>>>>>> computation *always* gives the same output for a given input. So
>>>>>>>> it doesn't make sense to say what it "would" do. It either does
>>>>>>>> or does not perform a complete and correct emulation. And
>>>>>>>> because H contains code to abort, and does abort, it does not do
>>>>>>>> a complete emulation.
>>>>>>>>
>>>>>>>> So the input must be given to a UTM, which by definition does a
>>>>>>>> correct and complete simulation, to see what the actual behavior
>>>>>>>> is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
>>>>>>>
>>>>>>> Every sufficiently competent software engineer can easily verify
>>>>>>> that
>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>>> would never reach the "ret" instruction of Px because both H and Px
>>>>>>> would remain stuck in infinitely recursive emulation.
>>>>>>
>>>>>> So you just repeated what you said instead of explaining why I'm
>>>>>> wrong. In other words you provided no rebuttal, which can only be
>>>>>> taken to mean that you have none.
>>>>> Your entire basis and all of assumptions was incorrect so when I
>>>>> provided an infallible one to that cannot possibly be correctly
>>>>> refuted
>>>>> you simply dodged it. That is a smart move for a dishonest person that
>>>>> is only interested in rebuttal.
>>>>>
>>>>> I dare you to go back to the prior post and find any error in my
>>>>> airtight correct reasoning. Another dodge will be construed as a tacit
>>>>> admission of defeat.
>>>>
>>>> As stated before H (or more accurately Ha) does not perform a
>>>> complete and correct emulation because it aborts. So by definition
>>>> it cannot be complete.
>>> I never claimed that H(P,P) performs a complete and correct emulation of
>>> its input so your rebuttal is the strawman deception.
>>>
>>> I claimed that H(P,P) correctly predicts that its complete and correct
>>> x86 emulation of its input would never reach the "ret" instruction of P.
>>
>> But since H, or more accurately Ha, *can't* do a correct and complete
>> emulation of its input, your point is moot.
>
> _Infinite_Loop()
> [00001082](01) 55 push ebp
> [00001083](02) 8bec mov ebp,esp
> [00001085](02) ebfe jmp 00001085
> [00001087](01) 5d pop ebp
> [00001088](01) c3 ret
> Size in bytes:(0007) [00001088]
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
> ...[00001082][00211e7f][00211e83] 55 push ebp
> ...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
> Infinite Loop Detected Simulation Stopped
>
> On the basis of this exact same utterly moronic reasoning because H
> *can't* do a correct and complete emulation of its input, H cannot
> possibly determine that _Infinite_Loop() never halts.
>
You like your herring red don't you.
You LOVE that Fallacy of proof by example.
It isn't said that H can NEVER prove that in input doesn't halt, just
that it can't use the rule you provided because it isn't true.
The above doesn't need to rely on the fact that H 'did' a correct and
complete emulation, so the fact that it didn't doesn't affect things.
You just don't understand the elementary rules of logic.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-22 20:32 -0400 |
| Message-ID | <TwOsK.191531$JVi.174704@fx17.iad> |
| In reply to | #52774 |
On 6/22/22 4:27 PM, olcott wrote:
> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>> On Tue, 21 Jun 2022 21:38:56 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> #include <stdint.h>
>>> typedef void (*ptr)();
>>>
>>> void P(ptr x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>> _P()
>>> [000010d2](01) 55 push ebp
>>> [000010d3](02) 8bec mov ebp,esp
>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>> [000010d8](01) 50 push eax
>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>> [000010dc](01) 51 push ecx
>>> [000010dd](05) e820feffff call 00000f02
>>> [000010e2](03) 83c408 add esp,+08
>>> [000010e5](02) 85c0 test eax,eax
>>> [000010e7](02) 7402 jz 000010eb
>>> [000010e9](02) ebfe jmp 000010e9
>>> [000010eb](01) 5d pop ebp
>>> [000010ec](01) c3 ret
>>> Size in bytes:(0027) [000010ec]
>>>
>>> Every sufficiently competent software engineer can easily verify that
>>> the complete and correct x86 emulation of the input to H(P,P) by H
>>> would never reach the "ret" instruction of P because both H and P
>>> would remain stuck in infinitely recursive emulation.
>>>
>>> If H does correctly determine that this is the case in a finite
>>> number of steps then H could reject its input on this basis. Here are
>>> the details of exactly how H does this in a finite number of steps.
>>>
>>> typedef struct Decoded
>>> {
>>> u32 Address;
>>> u32 ESP; // Current value of ESP
>>> u32 TOS; // Current value of Top of Stack
>>> u32 NumBytes;
>>> u32 Simplified_Opcode;
>>> u32 Decode_Target;
>>> } Decoded_Line_Of_Code;
>>>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> [000010d2][00211e8a][00211e8e] 55 push ebp
>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>>> [000010d8][00211e86][000010d2] 50 push eax // push P
>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>
>>> // actual fully operational code in the x86utm operating system
>>> u32 H(u32 P, u32 I)
>>> {
>>> HERE:
>>> u32 End_Of_Code;
>>> u32 Address_of_H; // 2022-06-17
>>> u32 code_end = get_code_end(P);
>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>> Registers* master_state = (Registers*)
>>> Allocate(sizeof(Registers));
>>> Registers* slave_state = (Registers*)
>>> Allocate(sizeof(Registers));
>>> u32* slave_stack = Allocate(0x10000); // 64k;
>>> u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>> * 1000);
>>>
>>> __asm lea eax, HERE // 2022-06-18
>>> __asm sub eax, 6 // 2022-06-18
>>> __asm mov Address_of_H, eax // 2022-06-18
>>> __asm mov eax, END_OF_CODE
>>> __asm mov End_Of_Code, eax
>>>
>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>> Output("\nBegin Simulation Execution Trace Stored at:",
>>> execution_trace);
>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>> goto END_OF_CODE;
>>> return 0; // Does not halt
>>> END_OF_CODE:
>>> return 1; // Input has normally terminated
>>> }
>>>
>>> H knows its own machine address and on this basis it can easily
>>> examine its stored execution_trace of P and determine:
>>> (a) P is calling H with the same arguments that H was called with.
>>> (b) No instructions in P could possibly escape this otherwise
>>> infinitely recursive emulation.
>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>
>>>
>>>
>>>
>>> Technically competent software engineers may not know this computer
>>> science:
>>>
>>> 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.
>>>
>>> computation that halts … the Turing machine will halt whenever it
>>> enters a final state. (Linz:1990:234)
>>>
>>> The "ret" instruction of P is its final state.
>>>
>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>
>>
>> void Px(u32 x)
>> {
>> H(x, x);
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>> }
>>
>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>> ...[000013eb][00102353][00000000] 50 push eax
>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>> Input_Halts = 0
>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>> ...[000013fb][0010235b][00100000] 5d pop ebp
>> ...[000013fc][0010235f][00000004] c3 ret
>> Number of Instructions Executed(16120)
>>
>> It gets the answer wrong, i.e. input has not been decided correctly.
>> QED.
>>
>> /Flibble
>>
>
> You and Richard are insufficiently technically competent at software
> engineering not meeting these specs:
>
> A software engineer must be an expert in: the C programming language,
> the x86 programming language, exactly how C translates into x86 and the
> ability to recognize infinite recursion at the x86 assembly language
> level. No knowledge of the halting problem is required.
>
>
Except that I am probably at least as much of an expert on those fields
as you are. My one problem is that I do have knowledge of the halting
problem, that seems to make me resistant to your lies.
You might have more experiance with x86, but only because I work on a
number of different architectures, but your argument really isn't x86
specific, that is just the case you are working in.
(I was producing 'production' assembly routines 50 years ago, so I have
seen a number of different types of machines)
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.theory
csiph-web