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 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-22 20:31 +0100 |
| Message-ID | <20220622203106.00003fa2@reddwarf.jmc> |
| In reply to | #52749 |
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
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 15:27 -0500 |
| Message-ID | <xqSdnb2KKdOL5i7_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #52771 |
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.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-22 22:20 +0100 |
| Message-ID | <20220622222043.00001cb9@reddwarf.jmc> |
| In reply to | #52774 |
On Wed, 22 Jun 2022 15:27:01 -0500
olcott <NoOne@NoWhere.com> 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.
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: the recursion simply isn't there for a "valid" halt
decider, that being a halt decider that can return an answer in finite
time to ALL invokers: H needs to return an answer to Px to be
considered a valid halt decider.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 16:41 -0500 |
| Message-ID | <_eidnf40g7wFES7_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52777 |
On 6/22/2022 4:20 PM, Mr Flibble wrote:
> On Wed, 22 Jun 2022 15:27:01 -0500
> olcott <NoOne@NoWhere.com> 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.
>
> 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.
Otherwise you are incompetent.
> the recursion simply isn't there for a "valid" halt
> decider, that being a halt decider that can return an answer in finite
> time to ALL invokers: H needs to return an answer to Px to be
> considered a valid halt decider.
>
> /Flibble
>
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-22 22:49 +0100 |
| Message-ID | <20220622224920.00002e56@reddwarf.jmc> |
| In reply to | #52778 |
On Wed, 22 Jun 2022 16:41:43 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 6/22/2022 4:20 PM, Mr Flibble wrote:
> > On Wed, 22 Jun 2022 15:27:01 -0500
> > olcott <NoOne@NoWhere.com> 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.
> >
> > 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.
>
> Otherwise you are incompetent.
>
> > the recursion simply isn't there for a "valid" halt
> > decider, that being a halt decider that can return an answer in
> > finite time to ALL invokers: H needs to return an answer to Px to be
> > considered a valid halt decider.
> >
> > /Flibble
Why did you ignore the second part? Again:
The problem is that you cannot recognize the fact that the infinite
recursion only manifests as part of your invalid simulation-based
omnishambles: the recursion simply isn't there for a "valid" halt
decider, that being a halt decider that can return an answer in finite
time to ALL invokers: H needs to return an answer to Px to be
considered a valid halt decider.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 16:58 -0500 |
| Message-ID | <u42dnbixJpIcDS7_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52779 |
On 6/22/2022 4:49 PM, Mr Flibble wrote:
> On Wed, 22 Jun 2022 16:41:43 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>> olcott <NoOne@NoWhere.com> 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.
>>>
>>> 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.
>>
>> Otherwise you are incompetent.
>>
>>> the recursion simply isn't there for a "valid" halt
>>> decider, that being a halt decider that can return an answer in
>>> finite time to ALL invokers: H needs to return an answer to Px to be
>>> considered a valid halt decider.
>>>
>>> /Flibble
>
> Why did you ignore the second part? Again:
>
> The problem is that you cannot recognize the fact that the infinite
> recursion only manifests as part of your invalid simulation-based
It is easily provably correct. That you lack the technical competence to
verify that the x86 emulated behavior of the x86 emulation of the input
to H(P,P) by H precisely matches the behavior specified by P is far less
than no rebuttal at all.
I am not going to keep responding to your nonsense I don't really give a
rat's ass for the woefully incorrect opinion of incompetent people.
> omnishambles: the recursion simply isn't there for a "valid" halt
> decider, that being a halt decider that can return an answer in finite
> time to ALL invokers: H needs to return an answer to Px to be
> considered a valid halt decider.
>
> /Flibble
>
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-23 00:01 +0100 |
| Message-ID | <20220623000116.000008c3@reddwarf.jmc> |
| In reply to | #52781 |
On Wed, 22 Jun 2022 16:58:24 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 6/22/2022 4:49 PM, Mr Flibble wrote:
> > On Wed, 22 Jun 2022 16:41:43 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/22/2022 4:20 PM, Mr Flibble wrote:
> >>> On Wed, 22 Jun 2022 15:27:01 -0500
> >>> olcott <NoOne@NoWhere.com> 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.
> >>>
> >>> 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.
> >>
> >> Otherwise you are incompetent.
> >>
> >>> the recursion simply isn't there for a "valid" halt
> >>> decider, that being a halt decider that can return an answer in
> >>> finite time to ALL invokers: H needs to return an answer to Px to
> >>> be considered a valid halt decider.
> >>>
> >>> /Flibble
> >
> > Why did you ignore the second part? Again:
> >
> > The problem is that you cannot recognize the fact that the infinite
> > recursion only manifests as part of your invalid simulation-based
>
> It is easily provably correct. That you lack the technical competence
> to verify that the x86 emulated behavior of the x86 emulation of the
> input to H(P,P) by H precisely matches the behavior specified by P is
> far less than no rebuttal at all.
Your H doesn't return a value to its invoker, Px in this case, so isn't
a valid halt decider. Valid halt deciders always return a value to
ALL their invokers in finite time with no infinite recursion.
That you repeatedly argue in the form of ad hominem attacks shows you
cannot recognise a logical fallacy or that you are in the wrong. You
completely refuse to tackle the argument as presented.
>
> I am not going to keep responding to your nonsense I don't really
> give a rat's ass for the woefully incorrect opinion of incompetent
> people.
You have yet to actually respond to the argument in a clear and honest
way.
>
> > omnishambles: the recursion simply isn't there for a "valid" halt
> > decider, that being a halt decider that can return an answer in
> > finite time to ALL invokers: H needs to return an answer to Px to be
> > considered a valid halt decider.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 18:29 -0500 |
| Message-ID | <ds-dnZEWV8JHOC7_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #52788 |
On 6/22/2022 6:01 PM, Mr Flibble wrote:
> On Wed, 22 Jun 2022 16:58:24 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/22/2022 4:49 PM, Mr Flibble wrote:
>>> On Wed, 22 Jun 2022 16:41:43 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>>>> olcott <NoOne@NoWhere.com> 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.
>>>>>
>>>>> 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.
>>>>
>>>> Otherwise you are incompetent.
>>>>
>>>>> the recursion simply isn't there for a "valid" halt
>>>>> decider, that being a halt decider that can return an answer in
>>>>> finite time to ALL invokers: H needs to return an answer to Px to
>>>>> be considered a valid halt decider.
>>>>>
>>>>> /Flibble
>>>
>>> Why did you ignore the second part? Again:
>>>
>>> The problem is that you cannot recognize the fact that the infinite
>>> recursion only manifests as part of your invalid simulation-based
>>
>> It is easily provably correct. That you lack the technical competence
>> to verify that the x86 emulated behavior of the x86 emulation of the
>> input to H(P,P) by H precisely matches the behavior specified by P is
>> far less than no rebuttal at all.
>
> Your H doesn't return a value to its invoker, Px in this case, so isn't
> a valid halt decider.
The provably correct execution trace of Px proves that H cannot possibly
return a value to Px because of the behavior of Px. That this is
over-your-head is no rebuttal what-so-ever.
--
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 | Dennis Bush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2022-06-22 14:53 -0700 |
| Message-ID | <de67d3d5-10f3-4e28-9b31-082e97c1145en@googlegroups.com> |
| In reply to | #52778 |
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.
> Otherwise you are incompetent.
> > the recursion simply isn't there for a "valid" halt
> > decider, that being a halt decider that can return an answer in finite
> > time to ALL invokers: H needs to return an answer to Px to be
> > considered a valid halt decider.
> >
> > /Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 17:22 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <MtadnVqn1dCkCy7_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52780 |
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.
When we assume this non-halting criteria and H does correctly apply this
criteria in a finite number of steps then H(Px,Px) does correctly
determine that its input never halts.
The above proves itself totally true entirely on the basis of the
meaning of its words: AKA it is self-evident truth.
In epistemology (theory of knowledge), a self-evident proposition is a
proposition that is known to be true by understanding its meaning
without proof, and/or by ordinary human reason.
https://en.wikipedia.org/wiki/Self-evidence
Of course because we know your modus operandi we already know that you
are going to intentionally incorrectly paraphrase what I said in an
attempt to get away with the strawman deception.
straw man
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man
The strawman deception is quite effective when gullible fools are the
target audience.
>> Otherwise you are incompetent.
>>> the recursion simply isn't there for a "valid" halt
>>> decider, that being a halt decider that can return an answer in finite
>>> time to ALL invokers: H needs to return an answer to Px to be
>>> considered a valid halt decider.
>>>
>>> /Flibble
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Dennis Bush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2022-06-22 15:48 -0700 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <5f26b879-5cd4-4f28-b7c4-c3e4ed0614c2n@googlegroups.com> |
| In reply to | #52783 |
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.
> When we assume this non-halting criteria and H does correctly apply this
> criteria in a finite number of steps then H(Px,Px) does correctly
> determine that its input never halts.
UTM(Px,Px) halting proves that H(Px,Px)==0 is wrong.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 18:11 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <9OydnaRCCvQ9PC7_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52786 |
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.
--
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 | Dennis Bush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2022-06-22 18:02 -0700 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <58dc4a7a-d635-44bb-bf2a-3a959d9d808an@googlegroups.com> |
| In reply to | #52790 |
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. A complete and correct emulation of the input to H(P,P), or more accurately Ha(Pa,Pa), is performed by UTM(Pa,Pa) which halts, therefore Ha(Pa,Pa)==0 is wrong.
Now explain why this is wrong. Failure to do so, which includes simply repeating your original point, will be taken as an inability to explain why it is wrong and therefore an admission that it is correct.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 20:16 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <SJ-dnXBdiJ6aIi7_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52804 |
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.
--
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 | Dennis Bush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2022-06-22 18:21 -0700 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <d59b136e-6411-462f-9b62-229c0ac00608n@googlegroups.com> |
| In reply to | #52809 |
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. So the input must be given to a UTM to determine the complete and correct simulation of the input. And since UTM(Pa,Pa) halts, Ha(Pa,Pa) ==0 is wrong.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 20:37 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <NZmdnRY_I-BpXi7_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52812 |
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.
--
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 | Dennis Bush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2022-06-22 18:44 -0700 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <5934b17d-9607-49d1-97db-813a232a6d94n@googlegroups.com> |
| In reply to | #52817 |
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. By that logic, since Ha3(_Infinite_Loop,"")==0 is correct, then Ha3(N,5)==0 must be correct.
Any further references to _Infinite_Loop will be taken as a distraction and an admission that you are unable to refute the point put to you.
H must by definition determine what the direct execution of its input would do, or equivalently the UTM simulation of its input.
H(_Infinite_Loop, "")==0 is correct because UTM(_Infinite_Loop, "") does not halt.
Similarly, H(P,P)==0 is not correct because UTM(P,P) halts.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 21:15 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <AfGdncZCoPo1US7_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52819 |
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.
--
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-22 22:22 -0400 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <J7QsK.4920$kY1.4571@fx06.iad> |
| In reply to | #52823 |
On 6/22/22 10:15 PM, 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.
>
No, that isn't what he said. Just shows you can't read.
He said that an H that aborts its simulation can't do a Complete and
Correct emulation of its input.
THis means that any proof based on it doing so is incorrect.
Remember, your logic is that SINCE (1) H does a complete and correct
emulation of its input, and (2) if H does a complete and correct
emulation of its input then P(P) will not halt, we can combine (1) and
(2) to say that P(P) will not Halt.
SInce (1) isn't true, the logic is unsound.
Spelled out fuller:
S1: H does a complete and correct emulation of its input.
S2: P(P) is non-halting.
given deduction: S1 -> S2
Arguement, since S1, and S1 -> S2, then S2
But since if H aborts its simulation to answer, S1 is not true, the
logic doesn't hold.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 21:42 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] |
| Message-ID | <rI2dnbKn8e-zTi7_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #52825 |
On 6/22/2022 9:22 PM, Richard Damon wrote:
> On 6/22/22 10:15 PM, 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.
>>
>
> No, that isn't what he said. Just shows you can't read.
>
> He said that an H that aborts its simulation can't do a Complete and
> Correct emulation of its input.
Implying that H cannot predict the behavior of the complete and correct
x86 emulation of its input without performing an actual complete emulation.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.theory
csiph-web