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 | 12 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 11 of 11 — ← Prev page 1 … 9 10 [11]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-23 00:19 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] |
| Message-ID | <GfWdnR1iS7lAai7_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52835 |
On 6/23/2022 12:13 AM, olcott wrote:
> On 6/22/2022 10:41 PM, Richard Damon wrote:
>> On 6/22/22 10:55 PM, olcott wrote:
>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
>>>> On 6/22/22 10:18 PM, olcott wrote:
>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
>>>>>> On 6/22/22 9:41 PM, olcott wrote:
>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> First you agree that my words are perfectly correct within
>>>>>>>>>>>>> their specified context
>>>>>>>>>>>>
>>>>>>>>>>>> Since you haven't actualy defined you context, and imply
>>>>>>>>>>>> that it is the halting problem, where they can not be
>>>>>>>>>>>> correct, that is not possible.
>>>>>>>>>>>>>
>>>>>>>>>>> First you agree that these words are 100% correct within the
>>>>>>>>>>> context of software engineering totally ignoring the context
>>>>>>>>>>> of the halting problem.
>>>>>>>>>>>
>>>>>>>>>>> #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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, if H actually is a program that does a COMPLETE and
>>>>>>>>>> correct x86 emulation of its input, then YES, as I have said
>>>>>>>>>> many time before, this combination is non-halting.
>>>>>>>>>>
>>>>>>>>>> The fact that you need to keep going back to this, and seem to
>>>>>>>>>> just be refusing to accept the conditions under which you have
>>>>>>>>>> proved it just shows the problems with your thought process.
>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> Except that NOW H isn't the H we were just talking about, so
>>>>>>>>>> you are just proving that you are either lying or an idiot.
>>>>>>>>>>
>>>>>>>>>> Remember, the first analysis had the CONDITION on it that H
>>>>>>>>>> did a COMPLETE and correct x86 emulation.
>>>>>>>>>>
>>>>>>>>>> Once you remove that property form H, that conclusion no long
>>>>>>>>>> holds and you are shown to be a lying idiot.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out before,
>>>>>>>>>> and you have ignored it.
>>>>>>>>>>
>>>>>>>>> That you don't understand what I mean does not mean that it is
>>>>>>>>> an incorrect rule.
>>>>>>>>>
>>>>>>>>> Here is an example where P does have instruction that could
>>>>>>>>> possibly escape this otherwise infinitely recursive emulation:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> void P(ptr x)
>>>>>>>>> {
>>>>>>>>> static count = 0;
>>>>>>>>> count++;
>>>>>>>>> if count > 3)
>>>>>>>>> return;
>>>>>>>>> if (H(x, x))
>>>>>>>>> HERE: goto HERE;
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>
>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
>>>>>>>> sometimes true, just it isn't an always true condition. You fail
>>>>>>>> at elementary logic.
>>>>>>>
>>>>>>> Try and find a valid counter-example. Every attempt at rebuttal
>>>>>>> that is not a valid counter-example is one form of deception or
>>>>>>> another.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> P(P)
>>>>>
>>>>> That is not any example of (b), thus another mere strawman deception.
>>>>>
>>>>
>>>> Why not?
>>>>
>>> It is not an example of the simulation of the input to H(P,P) at all.
>>>
>>>
>>
>> Why is P not P?
>>
>
> It is not a direct rebuttal of my original claim.
>
> This would be a direct rebuttal:
> You must adapt P so that when H(P,P) emulates its input it determines
> that P never reaches its "ret" instruction and the adapted emulated P
> still reaches its "ret" instruction.
>
Unless you find that at least one input where it gets the wrong answer
you have not refuted me.
--
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-23 07:20 -0400 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] |
| Message-ID | <_%XsK.3851$El2.3416@fx45.iad> |
| In reply to | #52836 |
On 6/23/22 1:19 AM, olcott wrote:
> On 6/23/2022 12:13 AM, olcott wrote:
>> On 6/22/2022 10:41 PM, Richard Damon wrote:
>>> On 6/22/22 10:55 PM, olcott wrote:
>>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
>>>>> On 6/22/22 10:18 PM, olcott wrote:
>>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
>>>>>>> On 6/22/22 9:41 PM, olcott wrote:
>>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> First you agree that my words are perfectly correct within
>>>>>>>>>>>>>> their specified context
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since you haven't actualy defined you context, and imply
>>>>>>>>>>>>> that it is the halting problem, where they can not be
>>>>>>>>>>>>> correct, that is not possible.
>>>>>>>>>>>>>>
>>>>>>>>>>>> First you agree that these words are 100% correct within the
>>>>>>>>>>>> context of software engineering totally ignoring the context
>>>>>>>>>>>> of the halting problem.
>>>>>>>>>>>>
>>>>>>>>>>>> #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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So, if H actually is a program that does a COMPLETE and
>>>>>>>>>>> correct x86 emulation of its input, then YES, as I have said
>>>>>>>>>>> many time before, this combination is non-halting.
>>>>>>>>>>>
>>>>>>>>>>> The fact that you need to keep going back to this, and seem
>>>>>>>>>>> to just be refusing to accept the conditions under which you
>>>>>>>>>>> have proved it just shows the problems with your thought
>>>>>>>>>>> process.
>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> Except that NOW H isn't the H we were just talking about, so
>>>>>>>>>>> you are just proving that you are either lying or an idiot.
>>>>>>>>>>>
>>>>>>>>>>> Remember, the first analysis had the CONDITION on it that H
>>>>>>>>>>> did a COMPLETE and correct x86 emulation.
>>>>>>>>>>>
>>>>>>>>>>> Once you remove that property form H, that conclusion no long
>>>>>>>>>>> holds and you are shown to be a lying idiot.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out before,
>>>>>>>>>>> and you have ignored it.
>>>>>>>>>>>
>>>>>>>>>> That you don't understand what I mean does not mean that it is
>>>>>>>>>> an incorrect rule.
>>>>>>>>>>
>>>>>>>>>> Here is an example where P does have instruction that could
>>>>>>>>>> possibly escape this otherwise infinitely recursive emulation:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>> static count = 0;
>>>>>>>>>> count++;
>>>>>>>>>> if count > 3)
>>>>>>>>>> return;
>>>>>>>>>> if (H(x, x))
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
>>>>>>>>> sometimes true, just it isn't an always true condition. You
>>>>>>>>> fail at elementary logic.
>>>>>>>>
>>>>>>>> Try and find a valid counter-example. Every attempt at rebuttal
>>>>>>>> that is not a valid counter-example is one form of deception or
>>>>>>>> another.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> P(P)
>>>>>>
>>>>>> That is not any example of (b), thus another mere strawman deception.
>>>>>>
>>>>>
>>>>> Why not?
>>>>>
>>>> It is not an example of the simulation of the input to H(P,P) at all.
>>>>
>>>>
>>>
>>> Why is P not P?
>>>
>>
>> It is not a direct rebuttal of my original claim.
>>
>> This would be a direct rebuttal:
>> You must adapt P so that when H(P,P) emulates its input it determines
>> that P never reaches its "ret" instruction and the adapted emulated P
>> still reaches its "ret" instruction.
>>
>
> Unless you find that at least one input where it gets the wrong answer
> you have not refuted me.
>
>
Your problem is I have, but you are just proving that you can't rebut an
idiot, because they won't understand the rebuttal.
One problem you have is your basic premise is incorrect because it is
inconsistent.
Your example shows a case where rule (b) causes you to NOT abort, and
thus not activate the flaw in your logic.
The first problem is that for ANY non-halting input by the classic
definition, like infinite-loop, you current definition, does the
complete and correct emulation by H reach a final state becomes broken,
as if H aborts its simulation, and thus NEVER DID a complete and correct
simulation.
That is like asking did you make a million dollars at your job when you
worked as a programmer in the 1700's?
The question is just based on a false premise. Since H doesn't actually
DO a complete and correct emulation of those inputs, you can't ask about
the results of that emulation. At BEST, you need to be asking about some
OTHER emulator that does, and when do do THAT, se we see that
Simulate(P,P) will halt if H(P,P) returns 0.
Thus, when we FIX that to use a REAL definition of Halting, since the
problem uses that word, we see that P(P) DOES Halt if H(P,P) returns 0,
so it becomes the counter example.
If you actually are trying to say that you get to define things as
impossible, then you have just actually PROVEN that you whole logic
system is just worthless and you haven't proven anything.
I could just as easily say, Lets define Halting as it stops in 3
instructions, after that, it is higher than some can count so that is
close enough to "infinity". By that definition, yes, P(P) is
non-halting, but who cares, that is a broken definition. JUST LIKE YOURS IS.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-23 20:41 +0100 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] |
| Message-ID | <20220623204153.00007a22@reddwarf.jmc> |
| In reply to | #52836 |
On Thu, 23 Jun 2022 00:19:23 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 6/23/2022 12:13 AM, olcott wrote:
> > On 6/22/2022 10:41 PM, Richard Damon wrote:
> >> On 6/22/22 10:55 PM, olcott wrote:
> >>> On 6/22/2022 9:34 PM, Richard Damon wrote:
> >>>> On 6/22/22 10:18 PM, olcott wrote:
> >>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
> >>>>>> On 6/22/22 9:41 PM, olcott wrote:
> >>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
> >>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
> >>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
> >>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
> >>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
> >>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>> First you agree that my words are perfectly correct
> >>>>>>>>>>>>> within their specified context
> >>>>>>>>>>>>
> >>>>>>>>>>>> Since you haven't actualy defined you context, and imply
> >>>>>>>>>>>> that it is the halting problem, where they can not be
> >>>>>>>>>>>> correct, that is not possible.
> >>>>>>>>>>>>>
> >>>>>>>>>>> First you agree that these words are 100% correct within
> >>>>>>>>>>> the context of software engineering totally ignoring the
> >>>>>>>>>>> context of the halting problem.
> >>>>>>>>>>>
> >>>>>>>>>>> #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.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> So, if H actually is a program that does a COMPLETE and
> >>>>>>>>>> correct x86 emulation of its input, then YES, as I have
> >>>>>>>>>> said many time before, this combination is non-halting.
> >>>>>>>>>>
> >>>>>>>>>> The fact that you need to keep going back to this, and
> >>>>>>>>>> seem to just be refusing to accept the conditions under
> >>>>>>>>>> which you have proved it just shows the problems with your
> >>>>>>>>>> thought process.
> >>>>>>>>>>> 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.
> >>>>>>>>>>
> >>>>>>>>>> Except that NOW H isn't the H we were just talking about,
> >>>>>>>>>> so you are just proving that you are either lying or an
> >>>>>>>>>> idiot.
> >>>>>>>>>>
> >>>>>>>>>> Remember, the first analysis had the CONDITION on it that
> >>>>>>>>>> H did a COMPLETE and correct x86 emulation.
> >>>>>>>>>>
> >>>>>>>>>> Once you remove that property form H, that conclusion no
> >>>>>>>>>> long holds and you are shown to be a lying idiot.
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> 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.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out
> >>>>>>>>>> before, and you have ignored it.
> >>>>>>>>>>
> >>>>>>>>> That you don't understand what I mean does not mean that it
> >>>>>>>>> is an incorrect rule.
> >>>>>>>>>
> >>>>>>>>> Here is an example where P does have instruction that could
> >>>>>>>>> possibly escape this otherwise infinitely recursive
> >>>>>>>>> emulation:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> void P(ptr x)
> >>>>>>>>> {
> >>>>>>>>> static count = 0;
> >>>>>>>>> count++;
> >>>>>>>>> if count > 3)
> >>>>>>>>> return;
> >>>>>>>>> if (H(x, x))
> >>>>>>>>> HERE: goto HERE;
> >>>>>>>>> return;
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> FALLACY of proof by example. I never said that (b) isn't
> >>>>>>>> sometimes true, just it isn't an always true condition. You
> >>>>>>>> fail at elementary logic.
> >>>>>>>
> >>>>>>> Try and find a valid counter-example. Every attempt at
> >>>>>>> rebuttal that is not a valid counter-example is one form of
> >>>>>>> deception or another.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> P(P)
> >>>>>
> >>>>> That is not any example of (b), thus another mere strawman
> >>>>> deception.
> >>>>
> >>>> Why not?
> >>>>
> >>> It is not an example of the simulation of the input to H(P,P) at
> >>> all.
> >>>
> >>>
> >>
> >> Why is P not P?
> >>
> >
> > It is not a direct rebuttal of my original claim.
> >
> > This would be a direct rebuttal:
> > You must adapt P so that when H(P,P) emulates its input it
> > determines that P never reaches its "ret" instruction and the
> > adapted emulated P still reaches its "ret" instruction.
> >
>
> Unless you find that at least one input where it gets the wrong
> answer you have not refuted me.
Here:
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-23 14:56 -0500 |
| Subject | Software engineers [ not Flibble ] can verify this halting problem proof refutation [ full closure ] |
| Message-ID | <Y-CdnQZk3dX2WCn_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52851 |
On 6/23/2022 2:41 PM, Mr Flibble wrote:
> On Thu, 23 Jun 2022 00:19:23 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/23/2022 12:13 AM, olcott wrote:
>>> On 6/22/2022 10:41 PM, Richard Damon wrote:
>>>> On 6/22/22 10:55 PM, olcott wrote:
>>>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
>>>>>> On 6/22/22 10:18 PM, olcott wrote:
>>>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
>>>>>>>> On 6/22/22 9:41 PM, olcott wrote:
>>>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> First you agree that my words are perfectly correct
>>>>>>>>>>>>>>> within their specified context
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Since you haven't actualy defined you context, and imply
>>>>>>>>>>>>>> that it is the halting problem, where they can not be
>>>>>>>>>>>>>> correct, that is not possible.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> First you agree that these words are 100% correct within
>>>>>>>>>>>>> the context of software engineering totally ignoring the
>>>>>>>>>>>>> context of the halting problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> #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.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So, if H actually is a program that does a COMPLETE and
>>>>>>>>>>>> correct x86 emulation of its input, then YES, as I have
>>>>>>>>>>>> said many time before, this combination is non-halting.
>>>>>>>>>>>>
>>>>>>>>>>>> The fact that you need to keep going back to this, and
>>>>>>>>>>>> seem to just be refusing to accept the conditions under
>>>>>>>>>>>> which you have proved it just shows the problems with your
>>>>>>>>>>>> thought process.
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> Except that NOW H isn't the H we were just talking about,
>>>>>>>>>>>> so you are just proving that you are either lying or an
>>>>>>>>>>>> idiot.
>>>>>>>>>>>>
>>>>>>>>>>>> Remember, the first analysis had the CONDITION on it that
>>>>>>>>>>>> H did a COMPLETE and correct x86 emulation.
>>>>>>>>>>>>
>>>>>>>>>>>> Once you remove that property form H, that conclusion no
>>>>>>>>>>>> long holds and you are shown to be a lying idiot.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out
>>>>>>>>>>>> before, and you have ignored it.
>>>>>>>>>>>>
>>>>>>>>>>> That you don't understand what I mean does not mean that it
>>>>>>>>>>> is an incorrect rule.
>>>>>>>>>>>
>>>>>>>>>>> Here is an example where P does have instruction that could
>>>>>>>>>>> possibly escape this otherwise infinitely recursive
>>>>>>>>>>> emulation:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>> static count = 0;
>>>>>>>>>>> count++;
>>>>>>>>>>> if count > 3)
>>>>>>>>>>> return;
>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>> return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
>>>>>>>>>> sometimes true, just it isn't an always true condition. You
>>>>>>>>>> fail at elementary logic.
>>>>>>>>>
>>>>>>>>> Try and find a valid counter-example. Every attempt at
>>>>>>>>> rebuttal that is not a valid counter-example is one form of
>>>>>>>>> deception or another.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> P(P)
>>>>>>>
>>>>>>> That is not any example of (b), thus another mere strawman
>>>>>>> deception.
>>>>>>
>>>>>> Why not?
>>>>>>
>>>>> It is not an example of the simulation of the input to H(P,P) at
>>>>> all.
>>>>>
>>>>>
>>>>
>>>> Why is P not P?
>>>>
>>>
>>> It is not a direct rebuttal of my original claim.
>>>
>>> This would be a direct rebuttal:
>>> You must adapt P so that when H(P,P) emulates its input it
>>> determines that P never reaches its "ret" instruction and the
>>> adapted emulated P still reaches its "ret" instruction.
>>>
>>
>> Unless you find that at least one input where it gets the wrong
>> answer you have not refuted me.
>
> Here:
>
> 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
>
>
To fully understand this code 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.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(Px,Px)
does correctly determine that its correct and complete x86 emulation of
its input would never reach the "ret" instruction of Px.
It is always the case that whenever anyone disagrees with verifiable
facts (as you have just done) that they are necessarily always incorrect.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-23 20:59 +0100 |
| Subject | Re: Software engineers [ not Flibble ] can verify this halting problem proof refutation [ full closure ] |
| Message-ID | <20220623205944.00003c38@reddwarf.jmc> |
| In reply to | #52852 |
On Thu, 23 Jun 2022 14:56:26 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 6/23/2022 2:41 PM, Mr Flibble wrote:
> > On Thu, 23 Jun 2022 00:19:23 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/23/2022 12:13 AM, olcott wrote:
> >>> On 6/22/2022 10:41 PM, Richard Damon wrote:
> >>>> On 6/22/22 10:55 PM, olcott wrote:
> >>>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
> >>>>>> On 6/22/22 10:18 PM, olcott wrote:
> >>>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
> >>>>>>>> On 6/22/22 9:41 PM, olcott wrote:
> >>>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
> >>>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
> >>>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
> >>>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
> >>>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
> >>>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> First you agree that my words are perfectly correct
> >>>>>>>>>>>>>>> within their specified context
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Since you haven't actualy defined you context, and
> >>>>>>>>>>>>>> imply that it is the halting problem, where they can
> >>>>>>>>>>>>>> not be correct, that is not possible.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> First you agree that these words are 100% correct within
> >>>>>>>>>>>>> the context of software engineering totally ignoring the
> >>>>>>>>>>>>> context of the halting problem.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> #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.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> So, if H actually is a program that does a COMPLETE and
> >>>>>>>>>>>> correct x86 emulation of its input, then YES, as I have
> >>>>>>>>>>>> said many time before, this combination is non-halting.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The fact that you need to keep going back to this, and
> >>>>>>>>>>>> seem to just be refusing to accept the conditions under
> >>>>>>>>>>>> which you have proved it just shows the problems with
> >>>>>>>>>>>> your thought process.
> >>>>>>>>>>>>> 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.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Except that NOW H isn't the H we were just talking about,
> >>>>>>>>>>>> so you are just proving that you are either lying or an
> >>>>>>>>>>>> idiot.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Remember, the first analysis had the CONDITION on it that
> >>>>>>>>>>>> H did a COMPLETE and correct x86 emulation.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Once you remove that property form H, that conclusion no
> >>>>>>>>>>>> long holds and you are shown to be a lying idiot.
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out
> >>>>>>>>>>>> before, and you have ignored it.
> >>>>>>>>>>>>
> >>>>>>>>>>> That you don't understand what I mean does not mean that
> >>>>>>>>>>> it is an incorrect rule.
> >>>>>>>>>>>
> >>>>>>>>>>> Here is an example where P does have instruction that
> >>>>>>>>>>> could possibly escape this otherwise infinitely recursive
> >>>>>>>>>>> emulation:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>> {
> >>>>>>>>>>> static count = 0;
> >>>>>>>>>>> count++;
> >>>>>>>>>>> if count > 3)
> >>>>>>>>>>> return;
> >>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>> return;
> >>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
> >>>>>>>>>> sometimes true, just it isn't an always true condition. You
> >>>>>>>>>> fail at elementary logic.
> >>>>>>>>>
> >>>>>>>>> Try and find a valid counter-example. Every attempt at
> >>>>>>>>> rebuttal that is not a valid counter-example is one form of
> >>>>>>>>> deception or another.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> P(P)
> >>>>>>>
> >>>>>>> That is not any example of (b), thus another mere strawman
> >>>>>>> deception.
> >>>>>>
> >>>>>> Why not?
> >>>>>>
> >>>>> It is not an example of the simulation of the input to H(P,P) at
> >>>>> all.
> >>>>>
> >>>>>
> >>>>
> >>>> Why is P not P?
> >>>>
> >>>
> >>> It is not a direct rebuttal of my original claim.
> >>>
> >>> This would be a direct rebuttal:
> >>> You must adapt P so that when H(P,P) emulates its input it
> >>> determines that P never reaches its "ret" instruction and the
> >>> adapted emulated P still reaches its "ret" instruction.
> >>>
> >>
> >> Unless you find that at least one input where it gets the wrong
> >> answer you have not refuted me.
> >
> > Here:
> >
> > 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
> >
> >
>
> To fully understand this code 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.
>
> The ordinary semantics of standard C and the conventional x86
> language are the entire semantics required to conclusively prove that
> H(Px,Px) does correctly determine that its correct and complete x86
> emulation of its input would never reach the "ret" instruction of Px.
>
> It is always the case that whenever anyone disagrees with verifiable
> facts (as you have just done) that they are necessarily always
> incorrect.
Nope. You are incorrect and your H is incorrect: Px should always halt
if H is a valid halt decider that returns to its invoker: Px (i.e. not
main).
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | "dklei...@gmail.com" <dkleinecke@gmail.com> |
|---|---|
| Date | 2022-06-23 16:55 -0700 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] |
| Message-ID | <f7da38b3-168a-4447-b3bf-5ebb1d57251dn@googlegroups.com> |
| In reply to | #52835 |
On Wednesday, June 22, 2022 at 10:13:27 PM UTC-7, olcott wrote:
> On 6/22/2022 10:41 PM, Richard Damon wrote:
> > On 6/22/22 10:55 PM, olcott wrote:
> >> On 6/22/2022 9:34 PM, Richard Damon wrote:
> >>> On 6/22/22 10:18 PM, olcott wrote:
> >>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
> >>>>> On 6/22/22 9:41 PM, olcott wrote:
> >>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
> >>>>>>> On 6/22/22 9:29 PM, olcott wrote:
> >>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
> >>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
> >>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
> >>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
> >>>>>>>>>>
> >>>>>>>>>>>> First you agree that my words are perfectly correct within
> >>>>>>>>>>>> their specified context
> >>>>>>>>>>>
> >>>>>>>>>>> Since you haven't actualy defined you context, and imply that
> >>>>>>>>>>> it is the halting problem, where they can not be correct,
> >>>>>>>>>>> that is not possible.
> >>>>>>>>>>>>
> >>>>>>>>>> First you agree that these words are 100% correct within the
> >>>>>>>>>> context of software engineering totally ignoring the context
> >>>>>>>>>> of the halting problem.
> >>>>>>>>>>
> >>>>>>>>>> #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.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> So, if H actually is a program that does a COMPLETE and correct
> >>>>>>>>> x86 emulation of its input, then YES, as I have said many time
> >>>>>>>>> before, this combination is non-halting.
> >>>>>>>>>
> >>>>>>>>> The fact that you need to keep going back to this, and seem to
> >>>>>>>>> just be refusing to accept the conditions under which you have
> >>>>>>>>> proved it just shows the problems with your thought process.
> >>>>>>>>>
> >>>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>> Except that NOW H isn't the H we were just talking about, so
> >>>>>>>>> you are just proving that you are either lying or an idiot.
> >>>>>>>>>
> >>>>>>>>> Remember, the first analysis had the CONDITION on it that H did
> >>>>>>>>> a COMPLETE and correct x86 emulation.
> >>>>>>>>>
> >>>>>>>>> Once you remove that property form H, that conclusion no long
> >>>>>>>>> holds and you are shown to be a lying idiot.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 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.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out before,
> >>>>>>>>> and you have ignored it.
> >>>>>>>>>
> >>>>>>>> That you don't understand what I mean does not mean that it is
> >>>>>>>> an incorrect rule.
> >>>>>>>>
> >>>>>>>> Here is an example where P does have instruction that could
> >>>>>>>> possibly escape this otherwise infinitely recursive emulation:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> void P(ptr x)
> >>>>>>>> {
> >>>>>>>> static count = 0;
> >>>>>>>> count++;
> >>>>>>>> if count > 3)
> >>>>>>>> return;
> >>>>>>>> if (H(x, x))
> >>>>>>>> HERE: goto HERE;
> >>>>>>>> return;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>
> >>>>>>> FALLACY of proof by example. I never said that (b) isn't
> >>>>>>> sometimes true, just it isn't an always true condition. You fail
> >>>>>>> at elementary logic.
> >>>>>>
> >>>>>> Try and find a valid counter-example. Every attempt at rebuttal
> >>>>>> that is not a valid counter-example is one form of deception or
> >>>>>> another.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> P(P)
> >>>>
> >>>> That is not any example of (b), thus another mere strawman deception.
> >>>>
> >>>
> >>> Why not?
> >>>
> >> It is not an example of the simulation of the input to H(P,P) at all.
> >>
> >>
> >
> > Why is P not P?
> >
> It is not a direct rebuttal of my original claim.
And what exactly was your original claim?
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-23 20:38 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] |
| Message-ID | <TdWdnWBGBqYViCj_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52861 |
On 6/23/2022 6:55 PM, dklei...@gmail.com wrote:
> On Wednesday, June 22, 2022 at 10:13:27 PM UTC-7, olcott wrote:
>> On 6/22/2022 10:41 PM, Richard Damon wrote:
>>> On 6/22/22 10:55 PM, olcott wrote:
>>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
>>>>> On 6/22/22 10:18 PM, olcott wrote:
>>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
>>>>>>> On 6/22/22 9:41 PM, olcott wrote:
>>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> First you agree that my words are perfectly correct within
>>>>>>>>>>>>>> their specified context
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since you haven't actualy defined you context, and imply that
>>>>>>>>>>>>> it is the halting problem, where they can not be correct,
>>>>>>>>>>>>> that is not possible.
>>>>>>>>>>>>>>
>>>>>>>>>>>> First you agree that these words are 100% correct within the
>>>>>>>>>>>> context of software engineering totally ignoring the context
>>>>>>>>>>>> of the halting problem.
>>>>>>>>>>>>
>>>>>>>>>>>> #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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So, if H actually is a program that does a COMPLETE and correct
>>>>>>>>>>> x86 emulation of its input, then YES, as I have said many time
>>>>>>>>>>> before, this combination is non-halting.
>>>>>>>>>>>
>>>>>>>>>>> The fact that you need to keep going back to this, and seem to
>>>>>>>>>>> just be refusing to accept the conditions under which you have
>>>>>>>>>>> proved it just shows the problems with your thought process.
>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> Except that NOW H isn't the H we were just talking about, so
>>>>>>>>>>> you are just proving that you are either lying or an idiot.
>>>>>>>>>>>
>>>>>>>>>>> Remember, the first analysis had the CONDITION on it that H did
>>>>>>>>>>> a COMPLETE and correct x86 emulation.
>>>>>>>>>>>
>>>>>>>>>>> Once you remove that property form H, that conclusion no long
>>>>>>>>>>> holds and you are shown to be a lying idiot.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out before,
>>>>>>>>>>> and you have ignored it.
>>>>>>>>>>>
>>>>>>>>>> That you don't understand what I mean does not mean that it is
>>>>>>>>>> an incorrect rule.
>>>>>>>>>>
>>>>>>>>>> Here is an example where P does have instruction that could
>>>>>>>>>> possibly escape this otherwise infinitely recursive emulation:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>> static count = 0;
>>>>>>>>>> count++;
>>>>>>>>>> if count > 3)
>>>>>>>>>> return;
>>>>>>>>>> if (H(x, x))
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
>>>>>>>>> sometimes true, just it isn't an always true condition. You fail
>>>>>>>>> at elementary logic.
>>>>>>>>
>>>>>>>> Try and find a valid counter-example. Every attempt at rebuttal
>>>>>>>> that is not a valid counter-example is one form of deception or
>>>>>>>> another.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> P(P)
>>>>>>
>>>>>> That is not any example of (b), thus another mere strawman deception.
>>>>>>
>>>>>
>>>>> Why not?
>>>>>
>>>> It is not an example of the simulation of the input to H(P,P) at all.
>>>>
>>>>
>>>
>>> Why is P not P?
>>>
>> It is not a direct rebuttal of my original claim.
>
> And what exactly was your original claim?
H is always correct when it determines that an emulated input specifies
infinitely nested emulation whenever H matches the (a)(b)(c) criteria to
the behavior of this input.
Obviously a rebuttal would be to find a case where H is incorrect under
these exact same conditions.
--
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-23 21:59 -0400 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] |
| Message-ID | <2U8tK.9437$Me2.4193@fx47.iad> |
| In reply to | #52865 |
On 6/23/22 9:38 PM, olcott wrote:
> On 6/23/2022 6:55 PM, dklei...@gmail.com wrote:
>> On Wednesday, June 22, 2022 at 10:13:27 PM UTC-7, olcott wrote:
>>> On 6/22/2022 10:41 PM, Richard Damon wrote:
>>>> On 6/22/22 10:55 PM, olcott wrote:
>>>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
>>>>>> On 6/22/22 10:18 PM, olcott wrote:
>>>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
>>>>>>>> On 6/22/22 9:41 PM, olcott wrote:
>>>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> First you agree that my words are perfectly correct within
>>>>>>>>>>>>>>> their specified context
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Since you haven't actualy defined you context, and imply that
>>>>>>>>>>>>>> it is the halting problem, where they can not be correct,
>>>>>>>>>>>>>> that is not possible.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> First you agree that these words are 100% correct within the
>>>>>>>>>>>>> context of software engineering totally ignoring the context
>>>>>>>>>>>>> of the halting problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> #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.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So, if H actually is a program that does a COMPLETE and correct
>>>>>>>>>>>> x86 emulation of its input, then YES, as I have said many time
>>>>>>>>>>>> before, this combination is non-halting.
>>>>>>>>>>>>
>>>>>>>>>>>> The fact that you need to keep going back to this, and seem to
>>>>>>>>>>>> just be refusing to accept the conditions under which you have
>>>>>>>>>>>> proved it just shows the problems with your thought process.
>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> Except that NOW H isn't the H we were just talking about, so
>>>>>>>>>>>> you are just proving that you are either lying or an idiot.
>>>>>>>>>>>>
>>>>>>>>>>>> Remember, the first analysis had the CONDITION on it that H did
>>>>>>>>>>>> a COMPLETE and correct x86 emulation.
>>>>>>>>>>>>
>>>>>>>>>>>> Once you remove that property form H, that conclusion no long
>>>>>>>>>>>> holds and you are shown to be a lying idiot.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out before,
>>>>>>>>>>>> and you have ignored it.
>>>>>>>>>>>>
>>>>>>>>>>> That you don't understand what I mean does not mean that it is
>>>>>>>>>>> an incorrect rule.
>>>>>>>>>>>
>>>>>>>>>>> Here is an example where P does have instruction that could
>>>>>>>>>>> possibly escape this otherwise infinitely recursive emulation:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>> static count = 0;
>>>>>>>>>>> count++;
>>>>>>>>>>> if count > 3)
>>>>>>>>>>> return;
>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>> return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
>>>>>>>>>> sometimes true, just it isn't an always true condition. You fail
>>>>>>>>>> at elementary logic.
>>>>>>>>>
>>>>>>>>> Try and find a valid counter-example. Every attempt at rebuttal
>>>>>>>>> that is not a valid counter-example is one form of deception or
>>>>>>>>> another.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> P(P)
>>>>>>>
>>>>>>> That is not any example of (b), thus another mere strawman
>>>>>>> deception.
>>>>>>>
>>>>>>
>>>>>> Why not?
>>>>>>
>>>>> It is not an example of the simulation of the input to H(P,P) at all.
>>>>>
>>>>>
>>>>
>>>> Why is P not P?
>>>>
>>> It is not a direct rebuttal of my original claim.
>> And what exactly was your original claim?
>
> H is always correct when it determines that an emulated input specifies
> infinitely nested emulation whenever H matches the (a)(b)(c) criteria to
> the behavior of this input.
>
> Obviously a rebuttal would be to find a case where H is incorrect under
> these exact same conditions.
>
No, it doesn't, because what it shows is that a mythological machine was
correct. The machine described is one that SIMULTANOUSLY does a complete
and correct emulation of its input, while ALSO stopping in finite time
to return the non-halting answer.
Since it claims the input is non-halting, that means it emulated that
full infinite behavior in only a finite number of steps.
That is just a Fairy Tale.
It is the same as showing that some cats bark because you have a cat
that is a dog that barks. Since there is no cat that is a dog, you don't
have an entity to be the "some".
Since there is no H that does both a complete and correct emulation and
also at the same time returns a correct non-halting answer, you don't
actually have an H.
Yor failure to understand this problem shouw your lack of understand of
the field.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-23 21:10 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] |
| Message-ID | <0J6dnT5xBam-gCj_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #52869 |
On 6/23/2022 8:59 PM, Richard Damon wrote:
>
> On 6/23/22 9:38 PM, olcott wrote:
>> On 6/23/2022 6:55 PM, dklei...@gmail.com wrote:
>>> On Wednesday, June 22, 2022 at 10:13:27 PM UTC-7, olcott wrote:
>>>> On 6/22/2022 10:41 PM, Richard Damon wrote:
>>>>> On 6/22/22 10:55 PM, olcott wrote:
>>>>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
>>>>>>> On 6/22/22 10:18 PM, olcott wrote:
>>>>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
>>>>>>>>> On 6/22/22 9:41 PM, olcott wrote:
>>>>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> First you agree that my words are perfectly correct within
>>>>>>>>>>>>>>>> their specified context
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Since you haven't actualy defined you context, and imply
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> it is the halting problem, where they can not be correct,
>>>>>>>>>>>>>>> that is not possible.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> First you agree that these words are 100% correct within the
>>>>>>>>>>>>>> context of software engineering totally ignoring the context
>>>>>>>>>>>>>> of the halting problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> #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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, if H actually is a program that does a COMPLETE and
>>>>>>>>>>>>> correct
>>>>>>>>>>>>> x86 emulation of its input, then YES, as I have said many time
>>>>>>>>>>>>> before, this combination is non-halting.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The fact that you need to keep going back to this, and seem to
>>>>>>>>>>>>> just be refusing to accept the conditions under which you have
>>>>>>>>>>>>> proved it just shows the problems with your thought process.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Except that NOW H isn't the H we were just talking about, so
>>>>>>>>>>>>> you are just proving that you are either lying or an idiot.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Remember, the first analysis had the CONDITION on it that H
>>>>>>>>>>>>> did
>>>>>>>>>>>>> a COMPLETE and correct x86 emulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Once you remove that property form H, that conclusion no long
>>>>>>>>>>>>> holds and you are shown to be a lying idiot.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out before,
>>>>>>>>>>>>> and you have ignored it.
>>>>>>>>>>>>>
>>>>>>>>>>>> That you don't understand what I mean does not mean that it is
>>>>>>>>>>>> an incorrect rule.
>>>>>>>>>>>>
>>>>>>>>>>>> Here is an example where P does have instruction that could
>>>>>>>>>>>> possibly escape this otherwise infinitely recursive emulation:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>> {
>>>>>>>>>>>> static count = 0;
>>>>>>>>>>>> count++;
>>>>>>>>>>>> if count > 3)
>>>>>>>>>>>> return;
>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
>>>>>>>>>>> sometimes true, just it isn't an always true condition. You fail
>>>>>>>>>>> at elementary logic.
>>>>>>>>>>
>>>>>>>>>> Try and find a valid counter-example. Every attempt at rebuttal
>>>>>>>>>> that is not a valid counter-example is one form of deception or
>>>>>>>>>> another.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> P(P)
>>>>>>>>
>>>>>>>> That is not any example of (b), thus another mere strawman
>>>>>>>> deception.
>>>>>>>>
>>>>>>>
>>>>>>> Why not?
>>>>>>>
>>>>>> It is not an example of the simulation of the input to H(P,P) at all.
>>>>>>
>>>>>>
>>>>>
>>>>> Why is P not P?
>>>>>
>>>> It is not a direct rebuttal of my original claim.
>>> And what exactly was your original claim?
>>
>> H is always correct when it determines that an emulated input
>> specifies infinitely nested emulation whenever H matches the (a)(b)(c)
>> criteria to the behavior of this input.
>>
>> Obviously a rebuttal would be to find a case where H is incorrect
>> under these exact same conditions.
>>
>
> No, it doesn't, because what it shows is that a mythological machine was
> correct. The machine described is one that SIMULTANOUSLY does a complete
> and correct emulation of its input, while ALSO stopping in finite time
> to return the non-halting answer.
Because of this reply after I have corrected you hundreds of times I
have blocked you and all of your messages have been erased.
--
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-23 22:29 -0400 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] |
| Message-ID | <mk9tK.2314$Eh2.457@fx41.iad> |
| In reply to | #52871 |
On 6/23/22 10:10 PM, olcott wrote:
> On 6/23/2022 8:59 PM, Richard Damon wrote:
>>
>> On 6/23/22 9:38 PM, olcott wrote:
>>> On 6/23/2022 6:55 PM, dklei...@gmail.com wrote:
>>>> On Wednesday, June 22, 2022 at 10:13:27 PM UTC-7, olcott wrote:
>>>>> On 6/22/2022 10:41 PM, Richard Damon wrote:
>>>>>> On 6/22/22 10:55 PM, olcott wrote:
>>>>>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
>>>>>>>> On 6/22/22 10:18 PM, olcott wrote:
>>>>>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
>>>>>>>>>> On 6/22/22 9:41 PM, olcott wrote:
>>>>>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> First you agree that my words are perfectly correct within
>>>>>>>>>>>>>>>>> their specified context
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Since you haven't actualy defined you context, and imply
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> it is the halting problem, where they can not be correct,
>>>>>>>>>>>>>>>> that is not possible.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> First you agree that these words are 100% correct within the
>>>>>>>>>>>>>>> context of software engineering totally ignoring the context
>>>>>>>>>>>>>>> of the halting problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> #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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, if H actually is a program that does a COMPLETE and
>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>> x86 emulation of its input, then YES, as I have said many
>>>>>>>>>>>>>> time
>>>>>>>>>>>>>> before, this combination is non-halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The fact that you need to keep going back to this, and
>>>>>>>>>>>>>> seem to
>>>>>>>>>>>>>> just be refusing to accept the conditions under which you
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>> proved it just shows the problems with your thought process.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Except that NOW H isn't the H we were just talking about, so
>>>>>>>>>>>>>> you are just proving that you are either lying or an idiot.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Remember, the first analysis had the CONDITION on it that
>>>>>>>>>>>>>> H did
>>>>>>>>>>>>>> a COMPLETE and correct x86 emulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Once you remove that property form H, that conclusion no long
>>>>>>>>>>>>>> holds and you are shown to be a lying idiot.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out before,
>>>>>>>>>>>>>> and you have ignored it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> That you don't understand what I mean does not mean that it is
>>>>>>>>>>>>> an incorrect rule.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here is an example where P does have instruction that could
>>>>>>>>>>>>> possibly escape this otherwise infinitely recursive emulation:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> static count = 0;
>>>>>>>>>>>>> count++;
>>>>>>>>>>>>> if count > 3)
>>>>>>>>>>>>> return;
>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>> return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
>>>>>>>>>>>> sometimes true, just it isn't an always true condition. You
>>>>>>>>>>>> fail
>>>>>>>>>>>> at elementary logic.
>>>>>>>>>>>
>>>>>>>>>>> Try and find a valid counter-example. Every attempt at rebuttal
>>>>>>>>>>> that is not a valid counter-example is one form of deception or
>>>>>>>>>>> another.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> P(P)
>>>>>>>>>
>>>>>>>>> That is not any example of (b), thus another mere strawman
>>>>>>>>> deception.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why not?
>>>>>>>>
>>>>>>> It is not an example of the simulation of the input to H(P,P) at
>>>>>>> all.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Why is P not P?
>>>>>>
>>>>> It is not a direct rebuttal of my original claim.
>>>> And what exactly was your original claim?
>>>
>>> H is always correct when it determines that an emulated input
>>> specifies infinitely nested emulation whenever H matches the
>>> (a)(b)(c) criteria to the behavior of this input.
>>>
>>> Obviously a rebuttal would be to find a case where H is incorrect
>>> under these exact same conditions.
>>>
>>
>> No, it doesn't, because what it shows is that a mythological machine
>> was correct. The machine described is one that SIMULTANOUSLY does a
>> complete and correct emulation of its input, while ALSO stopping in
>> finite time to return the non-halting answer.
>
> Because of this reply after I have corrected you hundreds of times I
> have blocked you and all of your messages have been erased.
>
>
Plugging your ears and saying "I can't hear you" doesn't make you correct.
It just makes it certain that if you ever get to trying to publish, you
are going to have a FATAL error in your paper and remove any chance of
paper getting accepted. They may not even answer enough to give you a
rejection.
Note, you may be able to make it so YOU don't see what I say, but
everyone else does, and the mere fact that you are ignoring a "voice of
reason" will taint others opinion of you.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 15:47 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ nitwit rebuttals ] |
| Message-ID | <d9OdnQGPWaRi4i7_nZ2dnUU7_83NnZ2d@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.
The proof of your technical incompetence that others can see is that you
only stater dogmatically that I am wrong without pointing out any actual
mistakes.
The proof of the technical incompetence of Richard and Ben is that they
intentionally paraphrase what I said incorrect so that they can use the
strawman deception to form a rebuttal on the basis of this intentionally
incorrect paraphrase.
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 proof of the technical incompetence of most everyone else is that
they simply provide ad hominem insults as the entire basis of their fake
"rebuttal". That zero rebuttals with any plausible basis have been
presented for many weeks is very encouraging.
--
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:13 +0100 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ nitwit rebuttals ] |
| Message-ID | <20220622221307.00002af9@reddwarf.jmc> |
| In reply to | #52775 |
On Wed, 22 Jun 2022 15:47:58 -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.
>
> The proof of your technical incompetence that others can see is that
> you only stater dogmatically that I am wrong without pointing out any
> actual mistakes.
>
> The proof of the technical incompetence of Richard and Ben is that
> they intentionally paraphrase what I said incorrect so that they can
> use the strawman deception to form a rebuttal on the basis of this
> intentionally incorrect paraphrase.
>
> 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 proof of the technical incompetence of most everyone else is that
> they simply provide ad hominem insults as the entire basis of their
> fake "rebuttal". That zero rebuttals with any plausible basis have
> been presented for many weeks is very encouraging.
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] | [standalone]
Page 11 of 11 — ← Prev page 1 … 9 10 [11]
Back to top | Article view | comp.theory
csiph-web