Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #52749 > unrolled thread
| Started by | olcott <NoOne@NoWhere.com> |
|---|---|
| First post | 2022-06-21 21:38 -0500 |
| Last post | 2022-06-22 22:13 +0100 |
| Articles | 20 on this page of 212 — 13 participants |
Back to article view | Back to comp.theory
Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-21 21:38 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-21 22:52 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-21 22:10 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-21 23:28 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Python <python@example.invalid> - 2022-06-22 05:52 +0200
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-22 00:55 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 07:16 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-22 05:45 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 07:53 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 09:55 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 19:05 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 18:39 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 20:22 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 19:30 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 20:56 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 20:03 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:19 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 20:33 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:49 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-22 16:50 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] olcott <NoOne@NoWhere.com> - 2022-06-22 12:58 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 19:11 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] olcott <NoOne@NoWhere.com> - 2022-06-22 19:00 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 20:25 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 19:34 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:05 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-23 01:19 -0700
Software engineers can verify this halting problem proof refutation [ H(P,P) versus P(P) ] olcott <NoOne@NoWhere.com> - 2022-06-23 13:14 -0500
Re: Software engineers can verify this halting problem proof refutation [ H(P,P) versus P(P) ] Daniel Pehoushek <pehoushek1@gmail.com> - 2022-06-23 11:26 -0700
Re: Software engineers can verify this halting problem proof refutation [ H(P,P) versus P(P) ] Richard Damon <Richard@Damon-Family.org> - 2022-06-23 19:00 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-23 23:44 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-23 20:38 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 00:53 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 08:07 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 09:18 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 06:34 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 09:32 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 12:07 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <polcott2@gmail.com> - 2022-06-24 10:50 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 09:09 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 11:32 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 12:46 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 11:52 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 15:55 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 10:29 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 12:42 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 12:34 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 15:20 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 16:00 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-24 20:42 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 13:25 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 15:35 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 16:59 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-24 23:16 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 17:25 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-06-24 16:58 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 19:12 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-24 21:56 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-06-24 21:50 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-24 23:59 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 21:01 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <polcott2@gmail.com> - 2022-06-24 23:33 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-24 22:09 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 00:24 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-25 00:32 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 09:28 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 10:03 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 16:09 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 10:19 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 16:21 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 10:54 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 16:59 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 11:06 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 17:25 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 11:32 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 20:12 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <NoOne@NoWhere.com> - 2022-06-25 14:20 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 20:33 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-25 13:03 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Python <python@example.invalid> - 2022-06-25 18:31 +0200
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 11:40 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-25 12:59 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-25 09:39 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-26 00:55 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 20:07 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 02:16 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 20:36 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-26 14:40 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 19:57 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-26 21:42 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 15:53 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-25 20:58 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 03:03 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 05:31 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 12:15 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 11:27 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 20:00 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 14:11 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 20:26 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 14:37 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 20:43 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 14:54 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 21:15 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 15:37 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 21:40 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 15:42 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-26 15:09 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-26 14:56 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 20:01 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-26 03:14 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 05:42 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-26 13:58 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-26 16:18 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Jeff Barnett <jbb@notatt.com> - 2022-06-22 11:11 -0600
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 13:10 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Jeff Barnett <jbb@notatt.com> - 2022-06-22 16:10 -0600
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 17:34 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 17:37 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Paul N <gw7rib@aol.com> - 2022-06-23 05:20 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-23 13:03 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-22 20:31 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 15:27 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-22 22:20 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 16:41 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-22 22:49 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 16:58 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Mr Flibble <flibble@reddwarf.jmc> - 2022-06-23 00:01 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation olcott <NoOne@NoWhere.com> - 2022-06-22 18:29 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 14:53 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 17:22 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 15:48 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 18:11 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 18:02 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 20:16 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 18:21 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 20:37 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 18:44 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 21:15 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 22:22 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 21:42 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 22:52 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 19:23 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-22 21:46 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 19:48 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-23 01:28 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 22:54 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-24 13:52 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Paul N <gw7rib@aol.com> - 2022-06-24 13:05 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-24 15:27 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Paul N <gw7rib@aol.com> - 2022-06-25 04:56 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-25 09:10 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 15:53 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Paul N <gw7rib@aol.com> - 2022-06-25 09:19 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-25 11:29 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Paul N <gw7rib@aol.com> - 2022-06-25 10:21 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <NoOne@NoWhere.com> - 2022-06-25 12:52 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Paul N <gw7rib@aol.com> - 2022-06-25 11:58 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <NoOne@NoWhere.com> - 2022-06-25 14:15 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 20:18 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Richard Damon <Richard@Damon-Family.org> - 2022-06-25 16:11 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-25 20:15 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-25 20:24 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Paul N <gw7rib@aol.com> - 2022-06-25 12:33 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-25 14:49 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-25 17:35 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-26 00:28 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-25 20:34 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <polcott2@gmail.com> - 2022-06-25 19:54 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <polcott2@gmail.com> - 2022-06-25 19:55 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <polcott2@gmail.com> - 2022-06-25 19:56 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <NoOne@NoWhere.com> - 2022-06-25 19:57 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Richard Damon <Richard@Damon-Family.org> - 2022-06-25 21:47 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] olcott <NoOne@NoWhere.com> - 2022-06-25 14:39 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-25 19:21 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-26 00:42 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-06-24 23:23 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] olcott <NoOne@NoWhere.com> - 2022-06-24 17:58 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] Richard Damon <Richard@Damon-Family.org> - 2022-06-24 22:00 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:52 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation Richard Damon <Richard@Damon-Family.org> - 2022-06-22 20:32 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 19:37 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 20:48 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 19:55 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Dennis Bush <dbush.mobile@gmail.com> - 2022-06-22 18:05 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 20:20 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:32 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Paul N <gw7rib@aol.com> - 2022-06-23 05:13 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-06-23 17:28 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 11:42 -0500
Software engineers can verify this halting problem proof refutation [ H(P,P) versus P(P) ] olcott <NoOne@NoWhere.com> - 2022-06-23 12:44 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:14 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 20:29 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:36 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 20:41 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 21:45 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 21:18 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 22:34 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-22 21:55 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-22 23:41 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 00:13 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 00:19 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-23 07:20 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-23 20:41 +0100
Software engineers [ not Flibble ] can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 14:56 -0500
Re: Software engineers [ not Flibble ] can verify this halting problem proof refutation [ full closure ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-23 20:59 +0100
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-06-23 16:55 -0700
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 20:38 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-23 21:59 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] olcott <NoOne@NoWhere.com> - 2022-06-23 21:10 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] Richard Damon <Richard@Damon-Family.org> - 2022-06-23 22:29 -0400
Re: Technically competent Software engineers can verify this halting problem proof refutation [ nitwit rebuttals ] olcott <NoOne@NoWhere.com> - 2022-06-22 15:47 -0500
Re: Technically competent Software engineers can verify this halting problem proof refutation [ nitwit rebuttals ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-22 22:13 +0100
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-06-24 21:01 -0700 |
| Message-ID | <b2699d2d-40be-4e9b-9612-efb7121d5a8bn@googlegroups.com> |
| In reply to | #52914 |
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > "Dry run" means that a human programmer looks at the code, and determines > > what it does, without actually executing it. > > Going back, now, to what you think needs to be resolved: > | He's dry-run P(P) and established that it doesn't halt. He's invoked H > | on it and H reports that it doesn't halt. He's run P(P) and it halts. > The obvious conclusion is that PO's dry run (if he has indeed done such > a thing) is incorrect. > Exactly. We do our little energy budget on tigers, and find that tigers spend more energy than they take in. Well potentially this is dynamite. One explanation is that the law of conservation of energy is wrong. Except, before we countenance that explanation, we need to rule out a much simpler explanation. Which is that our measurements are wrong. Similarly, PO has worked out what he thinks P(P) should be doing, by dry-running it, and then actually run P(P) and obtained a different result. He also found that H agreed with the dry run. It's hard to paraphrase his conclusion, but it is extensive and far-reaching in its implications. The behaviour of code when run is different from the correct behaviour of the code when simulated. If that's true, then it has similar implications for computer science that disproving the conservation law has for physics. But the obvious explanation is that the dry-run was incorrect. Lots of people have suggested why it is incorrect. But they can't actually see the code. PO needs to understand that no-one will accept the complicated, far-reaching explanation, until the simple explanation has been ruled out.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-06-24 23:33 -0500 |
| Message-ID | <t9637e$53p$1@dont-email.me> |
| In reply to | #52926 |
On 6/24/2022 11:01 PM, Malcolm McLean wrote: > On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >>> "Dry run" means that a human programmer looks at the code, and determines >>> what it does, without actually executing it. >> >> Going back, now, to what you think needs to be resolved: >> | He's dry-run P(P) and established that it doesn't halt. He's invoked H >> | on it and H reports that it doesn't halt. He's run P(P) and it halts. >> The obvious conclusion is that PO's dry run (if he has indeed done such >> a thing) is incorrect. >> > Exactly. > We do our little energy budget on tigers, and find that tigers spend more energy > than they take in. Well potentially this is dynamite. One explanation is that the > law of conservation of energy is wrong. > Except, before we countenance that explanation, we need to rule out a much > simpler explanation. Which is that our measurements are wrong. > > Similarly, PO has worked out what he thinks P(P) should be doing, by dry-running > it, and then actually run P(P) and obtained a different result. He also found that H > agreed with the dry run. It's hard to paraphrase his conclusion, but it is extensive > and far-reaching in its implications. The behaviour of code when run is different > from the correct behaviour of the code when simulated. If that's true, then it has > similar implications for computer science that disproving the conservation law > has for physics. > > But the obvious explanation is that the dry-run was incorrect. Lots of people have > suggested why it is incorrect. But they can't actually see the code. PO needs to > understand that no-one will accept the complicated, far-reaching explanation, > until the simple explanation has been ruled out. I already proved that the dry run is correct. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-06-24 22:09 -0700 |
| Message-ID | <20edb990-f33e-4f3b-bc59-6cebf9f9def8n@googlegroups.com> |
| In reply to | #52927 |
On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote: > On 6/24/2022 11:01 PM, Malcolm McLean wrote: > > On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote: > >> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >> > >>> "Dry run" means that a human programmer looks at the code, and determines > >>> what it does, without actually executing it. > >> > >> Going back, now, to what you think needs to be resolved: > >> | He's dry-run P(P) and established that it doesn't halt. He's invoked H > >> | on it and H reports that it doesn't halt. He's run P(P) and it halts. > >> The obvious conclusion is that PO's dry run (if he has indeed done such > >> a thing) is incorrect. > >> > > Exactly. > > We do our little energy budget on tigers, and find that tigers spend more energy > > than they take in. Well potentially this is dynamite. One explanation is that the > > law of conservation of energy is wrong. > > Except, before we countenance that explanation, we need to rule out a much > > simpler explanation. Which is that our measurements are wrong. > > > > Similarly, PO has worked out what he thinks P(P) should be doing, by dry-running > > it, and then actually run P(P) and obtained a different result. He also found that H > > agreed with the dry run. It's hard to paraphrase his conclusion, but it is extensive > > and far-reaching in its implications. The behaviour of code when run is different > > from the correct behaviour of the code when simulated. If that's true, then it has > > similar implications for computer science that disproving the conservation law > > has for physics. > > > > But the obvious explanation is that the dry-run was incorrect. Lots of people have > > suggested why it is incorrect. But they can't actually see the code. PO needs to > > understand that no-one will accept the complicated, far-reaching explanation, > > until the simple explanation has been ruled out. > > I already proved that the dry run is correct. > Someone reports that tigers use more energy than they take in, and concludes that the energy conservation law is incorrect. Naturally, everyone is going to say "There must be some mistake. How were your measurements taken? Show us your calculations, maybe you've got your sums wrong." Now if they are also uncooperative about sharing the details of the investigation, those reservations will be magnified. There can be legitimate reasons. Tigers are rare and need to be conserved, you can't let anyone who wants have access to the tigers to try to repeat the measurements. But there's also a common illegitimate reason put forwards by people who make extraordinary claims. If the claims were unexceptional, such as that tigers have a similar energy budget to lions, then no-one would be saying "Show me your notebooks. How do you know that calorimeter was calibrated accurately? What's the name of the person who took that measurement and can I interview them?" Extraordinary claims are put through the wringer in a way that ordinary ones are not. I've seen complaints about this from parapsychologists. But if you're going to claim to have discovered a new physical principle, you need to present rock solid evidence. In this case, we can't see H. We can only suggest explanations for its behaviour.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-25 00:24 -0500 |
| Message-ID | <wtidnY0ehdBiBiv_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52931 |
On 6/25/2022 12:09 AM, Malcolm McLean wrote: > On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote: >> On 6/24/2022 11:01 PM, Malcolm McLean wrote: >>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote: >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>> >>>>> "Dry run" means that a human programmer looks at the code, and determines >>>>> what it does, without actually executing it. >>>> >>>> Going back, now, to what you think needs to be resolved: >>>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H >>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts. >>>> The obvious conclusion is that PO's dry run (if he has indeed done such >>>> a thing) is incorrect. >>>> >>> Exactly. >>> We do our little energy budget on tigers, and find that tigers spend more energy >>> than they take in. Well potentially this is dynamite. One explanation is that the >>> law of conservation of energy is wrong. >>> Except, before we countenance that explanation, we need to rule out a much >>> simpler explanation. Which is that our measurements are wrong. >>> >>> Similarly, PO has worked out what he thinks P(P) should be doing, by dry-running >>> it, and then actually run P(P) and obtained a different result. He also found that H >>> agreed with the dry run. It's hard to paraphrase his conclusion, but it is extensive >>> and far-reaching in its implications. The behaviour of code when run is different >>> from the correct behaviour of the code when simulated. If that's true, then it has >>> similar implications for computer science that disproving the conservation law >>> has for physics. >>> >>> But the obvious explanation is that the dry-run was incorrect. Lots of people have >>> suggested why it is incorrect. But they can't actually see the code. PO needs to >>> understand that no-one will accept the complicated, far-reaching explanation, >>> until the simple explanation has been ruled out. >> >> I already proved that the dry run is correct. >> > Someone reports that tigers use more energy than they take in, and concludes that > the energy conservation law is incorrect. > Naturally, everyone is going to say "There must be some mistake. How were your > measurements taken? Show us your calculations, maybe you've got your sums wrong." > > Now if they are also uncooperative about sharing the details of the investigation, > those reservations will be magnified. There can be legitimate reasons. Tigers are > rare and need to be conserved, you can't let anyone who wants have access to the > tigers to try to repeat the measurements. But there's also a common illegitimate > reason put forwards by people who make extraordinary claims. If the claims were > unexceptional, such as that tigers have a similar energy budget to lions, then no-one > would be saying "Show me your notebooks. How do you know that calorimeter was > calibrated accurately? What's the name of the person who took that measurement > and can I interview them?" Extraordinary claims are put through the wringer in a way > that ordinary ones are not. I've seen complaints about this from parapsychologists. > But if you're going to claim to have discovered a new physical principle, you need > to present rock solid evidence. > > In this case, we can't see H. We can only suggest explanations for its behaviour. It seems that you simply lack the technical competence. Go back and look at my proof again. -- 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 | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-06-25 00:32 -0700 |
| Message-ID | <8328cb40-6b3c-4f89-a2ad-4054a6b466a6n@googlegroups.com> |
| In reply to | #52932 |
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote: > On 6/25/2022 12:09 AM, Malcolm McLean wrote: > > On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote: > >> On 6/24/2022 11:01 PM, Malcolm McLean wrote: > >>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote: > >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >>>> > >>>>> "Dry run" means that a human programmer looks at the code, and determines > >>>>> what it does, without actually executing it. > >>>> > >>>> Going back, now, to what you think needs to be resolved: > >>>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H > >>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts. > >>>> The obvious conclusion is that PO's dry run (if he has indeed done such > >>>> a thing) is incorrect. > >>>> > >>> Exactly. > >>> We do our little energy budget on tigers, and find that tigers spend more energy > >>> than they take in. Well potentially this is dynamite. One explanation is that the > >>> law of conservation of energy is wrong. > >>> Except, before we countenance that explanation, we need to rule out a much > >>> simpler explanation. Which is that our measurements are wrong. > >>> > >>> Similarly, PO has worked out what he thinks P(P) should be doing, by dry-running > >>> it, and then actually run P(P) and obtained a different result. He also found that H > >>> agreed with the dry run. It's hard to paraphrase his conclusion, but it is extensive > >>> and far-reaching in its implications. The behaviour of code when run is different > >>> from the correct behaviour of the code when simulated. If that's true, then it has > >>> similar implications for computer science that disproving the conservation law > >>> has for physics. > >>> > >>> But the obvious explanation is that the dry-run was incorrect. Lots of people have > >>> suggested why it is incorrect. But they can't actually see the code. PO needs to > >>> understand that no-one will accept the complicated, far-reaching explanation, > >>> until the simple explanation has been ruled out. > >> > >> I already proved that the dry run is correct. > >> > > Someone reports that tigers use more energy than they take in, and concludes that > > the energy conservation law is incorrect. > > Naturally, everyone is going to say "There must be some mistake. How were your > > measurements taken? Show us your calculations, maybe you've got your sums wrong." > > > > Now if they are also uncooperative about sharing the details of the investigation, > > those reservations will be magnified. There can be legitimate reasons. Tigers are > > rare and need to be conserved, you can't let anyone who wants have access to the > > tigers to try to repeat the measurements. But there's also a common illegitimate > > reason put forwards by people who make extraordinary claims. If the claims were > > unexceptional, such as that tigers have a similar energy budget to lions, then no-one > > would be saying "Show me your notebooks. How do you know that calorimeter was > > calibrated accurately? What's the name of the person who took that measurement > > and can I interview them?" Extraordinary claims are put through the wringer in a way > > that ordinary ones are not. I've seen complaints about this from parapsychologists. > > But if you're going to claim to have discovered a new physical principle, you need > > to present rock solid evidence. > > > > In this case, we can't see H. We can only suggest explanations for its behaviour. > It seems that you simply lack the technical competence. > Go back and look at my proof again. > Sorry no. I've been programming since I was a boy and I have a PhD in a computational- related subject. I'm confident of my technical abilities. What I can't do of course is tell you exactly what is going on in code I cannot see. I've got a pretty good idea, but I can only reconstruct on the basis of what you tell me. Ben thinks that I've got it wrong and in fact there are no nested emulations at all. I've no way of actually disproving that idea without seeing H.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-25 09:28 -0500 |
| Message-ID | <Jq2dnbDrVr_lhir_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52933 |
On 6/25/2022 2:32 AM, Malcolm McLean wrote:
> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> "Dry run" means that a human programmer looks at the code, and determines
>>>>>>> what it does, without actually executing it.
>>>>>>
>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H
>>>>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>>> The obvious conclusion is that PO's dry run (if he has indeed done such
>>>>>> a thing) is incorrect.
>>>>>>
>>>>> Exactly.
>>>>> We do our little energy budget on tigers, and find that tigers spend more energy
>>>>> than they take in. Well potentially this is dynamite. One explanation is that the
>>>>> law of conservation of energy is wrong.
>>>>> Except, before we countenance that explanation, we need to rule out a much
>>>>> simpler explanation. Which is that our measurements are wrong.
>>>>>
>>>>> Similarly, PO has worked out what he thinks P(P) should be doing, by dry-running
>>>>> it, and then actually run P(P) and obtained a different result. He also found that H
>>>>> agreed with the dry run. It's hard to paraphrase his conclusion, but it is extensive
>>>>> and far-reaching in its implications. The behaviour of code when run is different
>>>>> from the correct behaviour of the code when simulated. If that's true, then it has
>>>>> similar implications for computer science that disproving the conservation law
>>>>> has for physics.
>>>>>
>>>>> But the obvious explanation is that the dry-run was incorrect. Lots of people have
>>>>> suggested why it is incorrect. But they can't actually see the code. PO needs to
>>>>> understand that no-one will accept the complicated, far-reaching explanation,
>>>>> until the simple explanation has been ruled out.
>>>>
>>>> I already proved that the dry run is correct.
>>>>
>>> Someone reports that tigers use more energy than they take in, and concludes that
>>> the energy conservation law is incorrect.
>>> Naturally, everyone is going to say "There must be some mistake. How were your
>>> measurements taken? Show us your calculations, maybe you've got your sums wrong."
>>>
>>> Now if they are also uncooperative about sharing the details of the investigation,
>>> those reservations will be magnified. There can be legitimate reasons. Tigers are
>>> rare and need to be conserved, you can't let anyone who wants have access to the
>>> tigers to try to repeat the measurements. But there's also a common illegitimate
>>> reason put forwards by people who make extraordinary claims. If the claims were
>>> unexceptional, such as that tigers have a similar energy budget to lions, then no-one
>>> would be saying "Show me your notebooks. How do you know that calorimeter was
>>> calibrated accurately? What's the name of the person who took that measurement
>>> and can I interview them?" Extraordinary claims are put through the wringer in a way
>>> that ordinary ones are not. I've seen complaints about this from parapsychologists.
>>> But if you're going to claim to have discovered a new physical principle, you need
>>> to present rock solid evidence.
>>>
>>> In this case, we can't see H. We can only suggest explanations for its behaviour.
>> It seems that you simply lack the technical competence.
>> Go back and look at my proof again.
>>
> Sorry no. I've been programming since I was a boy and I have a PhD in a computational-
> related subject. I'm confident of my technical abilities. What I can't do of course
> is tell you exactly what is going on in code I cannot see. I've got a pretty good idea,
> but I can only reconstruct on the basis of what you tell me. Ben thinks that I've
> got it wrong and in fact there are no nested emulations at all. I've no way of actually
> disproving that idea without seeing H.
>
To fully understand this a software engineer must be an expert in:
(a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86 assembly
language level.
Anyone having the above credentials can validate my work, if you cannot
validate my work then you do not sufficiently have the above credentials.
Exactly how C translates into x86 is mandatory. If you don't know how
the C calling conventions are implemented in x86 you cannot validate my
work.
From a purely software engineering perspective H(P,P) is required to to
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of this input and H must
do this in a finite number of steps.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.
The correct and complete x86 emulation of its input by H(P,P) would
never reach the "ret" instruction of P because both H and P would remain
stuck in infinitely nested emulation.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001202](01) 55 push ebp
[00001203](02) 8bec mov ebp,esp
[00001205](03) 8b4508 mov eax,[ebp+08]
[00001208](01) 50 push eax
[00001209](03) 8b4d08 mov ecx,[ebp+08]
[0000120c](01) 51 push ecx
[0000120d](05) e820feffff call 00001032
[00001212](03) 83c408 add esp,+08
[00001215](02) 85c0 test eax,eax
[00001217](02) 7402 jz 0000121b
[00001219](02) ebfe jmp 00001219
[0000121b](01) 5d pop ebp
[0000121c](01) c3 ret
Size in bytes:(0027) [0000121c]
_main()
[00001222](01) 55 push ebp
[00001223](02) 8bec mov ebp,esp
[00001225](05) 6802120000 push 00001202
[0000122a](05) 6802120000 push 00001202
[0000122f](05) e8fefdffff call 00001032
[00001234](03) 83c408 add esp,+08
[00001237](01) 50 push eax
[00001238](05) 68b3030000 push 000003b3
[0000123d](05) e8c0f1ffff call 00000402
[00001242](03) 83c408 add esp,+08
[00001245](02) 33c0 xor eax,eax
[00001247](01) 5d pop ebp
[00001248](01) c3 ret
Size in bytes:(0039) [00001248]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001222][0010200f][00000000] 55 push ebp
[00001223][0010200f][00000000] 8bec mov ebp,esp
[00001225][0010200b][00001202] 6802120000 push 00001202 // push P
[0000122a][00102007][00001202] 6802120000 push 00001202 // push P
[0000122f][00102003][00001234] e8fefdffff call 00001032 // call executed H
Begin Simulation Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55 push ebp
[00001203][002120af][002120b3] 8bec mov ebp,esp
[00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
[00001208][002120ab][00001202] 50 push eax // push P
[00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08]
[0000120c][002120a7][00001202] 51 push ecx // push P
[0000120d][002120a3][00001212] e820feffff call 00001032 // call emulated H
Infinitely Recursive Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.
[00001234][0010200f][00000000] 83c408 add esp,+08
[00001237][0010200b][00000000] 50 push eax
[00001238][00102007][000003b3] 68b3030000 push 000003b3
[0000123d][00102007][000003b3] e8c0f1ffff call 00000402
Input_Halts = 0
[00001242][0010200f][00000000] 83c408 add esp,+08
[00001245][0010200f][00000000] 33c0 xor eax,eax
[00001247][00102013][00100000] 5d pop ebp
[00001248][00102017][00000004] c3 ret
Number of Instructions Executed(870) / 67 = 13 pages
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-25 10:03 -0500 |
| Message-ID | <Jo2dnaO4cb0rvir_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52940 |
On 6/25/2022 9:28 AM, olcott wrote:
> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> "Dry run" means that a human programmer looks at the code, and
>>>>>>>> determines
>>>>>>>> what it does, without actually executing it.
>>>>>>>
>>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
>>>>>>> invoked H
>>>>>>> | on it and H reports that it doesn't halt. He's run P(P) and it
>>>>>>> halts.
>>>>>>> The obvious conclusion is that PO's dry run (if he has indeed
>>>>>>> done such
>>>>>>> a thing) is incorrect.
>>>>>>>
>>>>>> Exactly.
>>>>>> We do our little energy budget on tigers, and find that tigers
>>>>>> spend more energy
>>>>>> than they take in. Well potentially this is dynamite. One
>>>>>> explanation is that the
>>>>>> law of conservation of energy is wrong.
>>>>>> Except, before we countenance that explanation, we need to rule
>>>>>> out a much
>>>>>> simpler explanation. Which is that our measurements are wrong.
>>>>>>
>>>>>> Similarly, PO has worked out what he thinks P(P) should be doing,
>>>>>> by dry-running
>>>>>> it, and then actually run P(P) and obtained a different result. He
>>>>>> also found that H
>>>>>> agreed with the dry run. It's hard to paraphrase his conclusion,
>>>>>> but it is extensive
>>>>>> and far-reaching in its implications. The behaviour of code when
>>>>>> run is different
>>>>>> from the correct behaviour of the code when simulated. If that's
>>>>>> true, then it has
>>>>>> similar implications for computer science that disproving the
>>>>>> conservation law
>>>>>> has for physics.
>>>>>>
>>>>>> But the obvious explanation is that the dry-run was incorrect.
>>>>>> Lots of people have
>>>>>> suggested why it is incorrect. But they can't actually see the
>>>>>> code. PO needs to
>>>>>> understand that no-one will accept the complicated, far-reaching
>>>>>> explanation,
>>>>>> until the simple explanation has been ruled out.
>>>>>
>>>>> I already proved that the dry run is correct.
>>>>>
>>>> Someone reports that tigers use more energy than they take in, and
>>>> concludes that
>>>> the energy conservation law is incorrect.
>>>> Naturally, everyone is going to say "There must be some mistake. How
>>>> were your
>>>> measurements taken? Show us your calculations, maybe you've got your
>>>> sums wrong."
>>>>
>>>> Now if they are also uncooperative about sharing the details of the
>>>> investigation,
>>>> those reservations will be magnified. There can be legitimate
>>>> reasons. Tigers are
>>>> rare and need to be conserved, you can't let anyone who wants have
>>>> access to the
>>>> tigers to try to repeat the measurements. But there's also a common
>>>> illegitimate
>>>> reason put forwards by people who make extraordinary claims. If the
>>>> claims were
>>>> unexceptional, such as that tigers have a similar energy budget to
>>>> lions, then no-one
>>>> would be saying "Show me your notebooks. How do you know that
>>>> calorimeter was
>>>> calibrated accurately? What's the name of the person who took that
>>>> measurement
>>>> and can I interview them?" Extraordinary claims are put through the
>>>> wringer in a way
>>>> that ordinary ones are not. I've seen complaints about this from
>>>> parapsychologists.
>>>> But if you're going to claim to have discovered a new physical
>>>> principle, you need
>>>> to present rock solid evidence.
>>>>
>>>> In this case, we can't see H. We can only suggest explanations for
>>>> its behaviour.
>>> It seems that you simply lack the technical competence.
>>> Go back and look at my proof again.
>>>
>> Sorry no. I've been programming since I was a boy and I have a PhD in
>> a computational-
>> related subject. I'm confident of my technical abilities. What I can't
>> do of course
>> is tell you exactly what is going on in code I cannot see. I've got a
>> pretty good idea,
>> but I can only reconstruct on the basis of what you tell me. Ben
>> thinks that I've
>> got it wrong and in fact there are no nested emulations at all. I've
>> no way of actually
>> disproving that idea without seeing H.
>>
>
> To fully understand this a software engineer must be an expert in:
> (a) The C programming language,
> (b) The x86 programming language,
> (c) Exactly how C translates into x86 and,
> (d) The ability to recognize infinite recursion at the x86 assembly
> language level.
>
> Anyone having the above credentials can validate my work, if you cannot
> validate my work then you do not sufficiently have the above credentials.
>
> Exactly how C translates into x86 is mandatory. If you don't know how
> the C calling conventions are implemented in x86 you cannot validate my
> work.
>
> From a purely software engineering perspective H(P,P) is required to to
> correctly determine that its correct and complete x86 emulation of its
> input would never reach the "ret" instruction of this input and H must
> do this in a finite number of steps.
>
> The ordinary semantics of standard C and the conventional x86 language
> are the entire semantics required to conclusively prove that H(P,P) does
> correctly determine that its correct and complete x86 emulation of its
> input would never reach the "ret" instruction (final state) of this
> input thus never halts.
>
> The correct and complete x86 emulation of its input by H(P,P) would
> never reach the "ret" instruction of P because both H and P would remain
> stuck in infinitely nested emulation.
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00001202](01) 55 push ebp
> [00001203](02) 8bec mov ebp,esp
> [00001205](03) 8b4508 mov eax,[ebp+08]
> [00001208](01) 50 push eax
> [00001209](03) 8b4d08 mov ecx,[ebp+08]
> [0000120c](01) 51 push ecx
> [0000120d](05) e820feffff call 00001032
> [00001212](03) 83c408 add esp,+08
> [00001215](02) 85c0 test eax,eax
> [00001217](02) 7402 jz 0000121b
> [00001219](02) ebfe jmp 00001219
> [0000121b](01) 5d pop ebp
> [0000121c](01) c3 ret
> Size in bytes:(0027) [0000121c]
>
> _main()
> [00001222](01) 55 push ebp
> [00001223](02) 8bec mov ebp,esp
> [00001225](05) 6802120000 push 00001202
> [0000122a](05) 6802120000 push 00001202
> [0000122f](05) e8fefdffff call 00001032
> [00001234](03) 83c408 add esp,+08
> [00001237](01) 50 push eax
> [00001238](05) 68b3030000 push 000003b3
> [0000123d](05) e8c0f1ffff call 00000402
> [00001242](03) 83c408 add esp,+08
> [00001245](02) 33c0 xor eax,eax
> [00001247](01) 5d pop ebp
> [00001248](01) c3 ret
> Size in bytes:(0039) [00001248]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [00001222][0010200f][00000000] 55 push ebp
> [00001223][0010200f][00000000] 8bec mov ebp,esp
> [00001225][0010200b][00001202] 6802120000 push 00001202 // push P
> [0000122a][00102007][00001202] 6802120000 push 00001202 // push P
> [0000122f][00102003][00001234] e8fefdffff call 00001032 // call executed H
>
> Begin Simulation Execution Trace Stored at:2120c3
> Address_of_H:1032
> [00001202][002120af][002120b3] 55 push ebp
> [00001203][002120af][002120b3] 8bec mov ebp,esp
> [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
> [00001208][002120ab][00001202] 50 push eax // push P
> [00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08]
> [0000120c][002120a7][00001202] 51 push ecx // push P
> [0000120d][002120a3][00001212] e820feffff call 00001032 // call emulated H
> Infinitely Recursive Simulation Detected Simulation Stopped
>
> H knows its own machine address and on this basis it can easily
> examine its stored execution_trace of P (see above) to determine:
> (a) P is calling H with the same arguments that H was called with.
> (b) No instructions in P could possibly escape this otherwise infinitely
> recursive emulation.
> (c) H aborts its emulation of P before its call to H is emulated.
>
When you know that H simply implements the above algorithm there is no
need to see its source code. I am reserving the publication of the 5
pages of the source code of the halt decider for journal publication.
Many journals will refuse to publish material that is already "out
there". I will publish the current 41 pages of source-code for the
x86utm operating system as open source.
It took many months to figure out how to avoid the need of static local
data to transform H into a pure function of its inputs. The algorithm
shown above has this transformation.
> [00001234][0010200f][00000000] 83c408 add esp,+08
> [00001237][0010200b][00000000] 50 push eax
> [00001238][00102007][000003b3] 68b3030000 push 000003b3
> [0000123d][00102007][000003b3] e8c0f1ffff call 00000402
> Input_Halts = 0
> [00001242][0010200f][00000000] 83c408 add esp,+08
> [00001245][0010200f][00000000] 33c0 xor eax,eax
> [00001247][00102013][00100000] 5d pop ebp
> [00001248][00102017][00000004] c3 ret
> Number of Instructions Executed(870) / 67 = 13 pages
>
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-25 16:09 +0100 |
| Message-ID | <20220625160945.00006e9b@reddwarf.jmc> |
| In reply to | #52943 |
On Sat, 25 Jun 2022 10:03:17 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 6/25/2022 9:28 AM, olcott wrote:
> > On 6/25/2022 2:32 AM, Malcolm McLean wrote:
> >> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
> >>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
> >>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
> >>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
> >>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
> >>>>>> wrote:
> >>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>
> >>>>>>>> "Dry run" means that a human programmer looks at the code,
> >>>>>>>> and determines
> >>>>>>>> what it does, without actually executing it.
> >>>>>>>
> >>>>>>> Going back, now, to what you think needs to be resolved:
> >>>>>>> | He's dry-run P(P) and established that it doesn't halt.
> >>>>>>> He's invoked H
> >>>>>>> | on it and H reports that it doesn't halt. He's run P(P) and
> >>>>>>> it halts.
> >>>>>>> The obvious conclusion is that PO's dry run (if he has indeed
> >>>>>>> done such
> >>>>>>> a thing) is incorrect.
> >>>>>>>
> >>>>>> Exactly.
> >>>>>> We do our little energy budget on tigers, and find that tigers
> >>>>>> spend more energy
> >>>>>> than they take in. Well potentially this is dynamite. One
> >>>>>> explanation is that the
> >>>>>> law of conservation of energy is wrong.
> >>>>>> Except, before we countenance that explanation, we need to
> >>>>>> rule out a much
> >>>>>> simpler explanation. Which is that our measurements are wrong.
> >>>>>>
> >>>>>> Similarly, PO has worked out what he thinks P(P) should be
> >>>>>> doing, by dry-running
> >>>>>> it, and then actually run P(P) and obtained a different
> >>>>>> result. He also found that H
> >>>>>> agreed with the dry run. It's hard to paraphrase his
> >>>>>> conclusion, but it is extensive
> >>>>>> and far-reaching in its implications. The behaviour of code
> >>>>>> when run is different
> >>>>>> from the correct behaviour of the code when simulated. If
> >>>>>> that's true, then it has
> >>>>>> similar implications for computer science that disproving the
> >>>>>> conservation law
> >>>>>> has for physics.
> >>>>>>
> >>>>>> But the obvious explanation is that the dry-run was incorrect.
> >>>>>> Lots of people have
> >>>>>> suggested why it is incorrect. But they can't actually see the
> >>>>>> code. PO needs to
> >>>>>> understand that no-one will accept the complicated,
> >>>>>> far-reaching explanation,
> >>>>>> until the simple explanation has been ruled out.
> >>>>>
> >>>>> I already proved that the dry run is correct.
> >>>>>
> >>>> Someone reports that tigers use more energy than they take in,
> >>>> and concludes that
> >>>> the energy conservation law is incorrect.
> >>>> Naturally, everyone is going to say "There must be some mistake.
> >>>> How were your
> >>>> measurements taken? Show us your calculations, maybe you've got
> >>>> your sums wrong."
> >>>>
> >>>> Now if they are also uncooperative about sharing the details of
> >>>> the investigation,
> >>>> those reservations will be magnified. There can be legitimate
> >>>> reasons. Tigers are
> >>>> rare and need to be conserved, you can't let anyone who wants
> >>>> have access to the
> >>>> tigers to try to repeat the measurements. But there's also a
> >>>> common illegitimate
> >>>> reason put forwards by people who make extraordinary claims. If
> >>>> the claims were
> >>>> unexceptional, such as that tigers have a similar energy budget
> >>>> to lions, then no-one
> >>>> would be saying "Show me your notebooks. How do you know that
> >>>> calorimeter was
> >>>> calibrated accurately? What's the name of the person who took
> >>>> that measurement
> >>>> and can I interview them?" Extraordinary claims are put through
> >>>> the wringer in a way
> >>>> that ordinary ones are not. I've seen complaints about this from
> >>>> parapsychologists.
> >>>> But if you're going to claim to have discovered a new physical
> >>>> principle, you need
> >>>> to present rock solid evidence.
> >>>>
> >>>> In this case, we can't see H. We can only suggest explanations
> >>>> for its behaviour.
> >>> It seems that you simply lack the technical competence.
> >>> Go back and look at my proof again.
> >>>
> >> Sorry no. I've been programming since I was a boy and I have a PhD
> >> in a computational-
> >> related subject. I'm confident of my technical abilities. What I
> >> can't do of course
> >> is tell you exactly what is going on in code I cannot see. I've
> >> got a pretty good idea,
> >> but I can only reconstruct on the basis of what you tell me. Ben
> >> thinks that I've
> >> got it wrong and in fact there are no nested emulations at all.
> >> I've no way of actually
> >> disproving that idea without seeing H.
> >>
> >
> > To fully understand this a software engineer must be an expert in:
> > (a) The C programming language,
> > (b) The x86 programming language,
> > (c) Exactly how C translates into x86 and,
> > (d) The ability to recognize infinite recursion at the x86 assembly
> > language level.
> >
> > Anyone having the above credentials can validate my work, if you
> > cannot validate my work then you do not sufficiently have the above
> > credentials.
> >
> > Exactly how C translates into x86 is mandatory. If you don't know
> > how the C calling conventions are implemented in x86 you cannot
> > validate my work.
> >
> > From a purely software engineering perspective H(P,P) is required
> > to to correctly determine that its correct and complete x86
> > emulation of its input would never reach the "ret" instruction of
> > this input and H must do this in a finite number of steps.
> >
> > The ordinary semantics of standard C and the conventional x86
> > language are the entire semantics required to conclusively prove
> > that H(P,P) does correctly determine that its correct and complete
> > x86 emulation of its input would never reach the "ret" instruction
> > (final state) of this input thus never halts.
> >
> > The correct and complete x86 emulation of its input by H(P,P) would
> > never reach the "ret" instruction of P because both H and P would
> > remain stuck in infinitely nested emulation.
> >
> > void P(u32 x)
> > {
> > if (H(x, x))
> > HERE: goto HERE;
> > return;
> > }
> >
> > int main()
> > {
> > Output("Input_Halts = ", H((u32)P, (u32)P));
> > }
> >
> > _P()
> > [00001202](01) 55 push ebp
> > [00001203](02) 8bec mov ebp,esp
> > [00001205](03) 8b4508 mov eax,[ebp+08]
> > [00001208](01) 50 push eax
> > [00001209](03) 8b4d08 mov ecx,[ebp+08]
> > [0000120c](01) 51 push ecx
> > [0000120d](05) e820feffff call 00001032
> > [00001212](03) 83c408 add esp,+08
> > [00001215](02) 85c0 test eax,eax
> > [00001217](02) 7402 jz 0000121b
> > [00001219](02) ebfe jmp 00001219
> > [0000121b](01) 5d pop ebp
> > [0000121c](01) c3 ret
> > Size in bytes:(0027) [0000121c]
> >
> > _main()
> > [00001222](01) 55 push ebp
> > [00001223](02) 8bec mov ebp,esp
> > [00001225](05) 6802120000 push 00001202
> > [0000122a](05) 6802120000 push 00001202
> > [0000122f](05) e8fefdffff call 00001032
> > [00001234](03) 83c408 add esp,+08
> > [00001237](01) 50 push eax
> > [00001238](05) 68b3030000 push 000003b3
> > [0000123d](05) e8c0f1ffff call 00000402
> > [00001242](03) 83c408 add esp,+08
> > [00001245](02) 33c0 xor eax,eax
> > [00001247](01) 5d pop ebp
> > [00001248](01) c3 ret
> > Size in bytes:(0039) [00001248]
> >
> > machine stack stack machine assembly
> > address address data code language
> > ======== ======== ======== ========= =============
> > [00001222][0010200f][00000000] 55 push ebp
> > [00001223][0010200f][00000000] 8bec mov ebp,esp
> > [00001225][0010200b][00001202] 6802120000 push 00001202 // push P
> > [0000122a][00102007][00001202] 6802120000 push 00001202 // push P
> > [0000122f][00102003][00001234] e8fefdffff call 00001032 // call
> > executed H
> >
> > Begin Simulation Execution Trace Stored at:2120c3
> > Address_of_H:1032
> > [00001202][002120af][002120b3] 55 push ebp
> > [00001203][002120af][002120b3] 8bec mov ebp,esp
> > [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
> > [00001208][002120ab][00001202] 50 push eax // push P
> > [00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08]
> > [0000120c][002120a7][00001202] 51 push ecx // push P
> > [0000120d][002120a3][00001212] e820feffff call 00001032 // call
> > emulated H Infinitely Recursive Simulation Detected Simulation
> > Stopped
> >
> > H knows its own machine address and on this basis it can easily
> > examine its stored execution_trace of P (see above) to determine:
> > (a) P is calling H with the same arguments that H was called with.
> > (b) No instructions in P could possibly escape this otherwise
> > infinitely recursive emulation.
> > (c) H aborts its emulation of P before its call to H is emulated.
> >
>
> When you know that H simply implements the above algorithm there is
> no need to see its source code. I am reserving the publication of the
> 5 pages of the source code of the halt decider for journal
> publication.
Your H is not a pure function as it behaves differently depending on
what is invoking it (it returns a decision answer to main() but not
to P()) and it has side effects (aborting a simulation).
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-25 10:19 -0500 |
| Message-ID | <2umdnWsMdJX6uir_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52944 |
On 6/25/2022 10:09 AM, Mr Flibble wrote:
> On Sat, 25 Jun 2022 10:03:17 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 9:28 AM, olcott wrote:
>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
>>>>>>>> wrote:
>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> "Dry run" means that a human programmer looks at the code,
>>>>>>>>>> and determines
>>>>>>>>>> what it does, without actually executing it.
>>>>>>>>>
>>>>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt.
>>>>>>>>> He's invoked H
>>>>>>>>> | on it and H reports that it doesn't halt. He's run P(P) and
>>>>>>>>> it halts.
>>>>>>>>> The obvious conclusion is that PO's dry run (if he has indeed
>>>>>>>>> done such
>>>>>>>>> a thing) is incorrect.
>>>>>>>>>
>>>>>>>> Exactly.
>>>>>>>> We do our little energy budget on tigers, and find that tigers
>>>>>>>> spend more energy
>>>>>>>> than they take in. Well potentially this is dynamite. One
>>>>>>>> explanation is that the
>>>>>>>> law of conservation of energy is wrong.
>>>>>>>> Except, before we countenance that explanation, we need to
>>>>>>>> rule out a much
>>>>>>>> simpler explanation. Which is that our measurements are wrong.
>>>>>>>>
>>>>>>>> Similarly, PO has worked out what he thinks P(P) should be
>>>>>>>> doing, by dry-running
>>>>>>>> it, and then actually run P(P) and obtained a different
>>>>>>>> result. He also found that H
>>>>>>>> agreed with the dry run. It's hard to paraphrase his
>>>>>>>> conclusion, but it is extensive
>>>>>>>> and far-reaching in its implications. The behaviour of code
>>>>>>>> when run is different
>>>>>>>> from the correct behaviour of the code when simulated. If
>>>>>>>> that's true, then it has
>>>>>>>> similar implications for computer science that disproving the
>>>>>>>> conservation law
>>>>>>>> has for physics.
>>>>>>>>
>>>>>>>> But the obvious explanation is that the dry-run was incorrect.
>>>>>>>> Lots of people have
>>>>>>>> suggested why it is incorrect. But they can't actually see the
>>>>>>>> code. PO needs to
>>>>>>>> understand that no-one will accept the complicated,
>>>>>>>> far-reaching explanation,
>>>>>>>> until the simple explanation has been ruled out.
>>>>>>>
>>>>>>> I already proved that the dry run is correct.
>>>>>>>
>>>>>> Someone reports that tigers use more energy than they take in,
>>>>>> and concludes that
>>>>>> the energy conservation law is incorrect.
>>>>>> Naturally, everyone is going to say "There must be some mistake.
>>>>>> How were your
>>>>>> measurements taken? Show us your calculations, maybe you've got
>>>>>> your sums wrong."
>>>>>>
>>>>>> Now if they are also uncooperative about sharing the details of
>>>>>> the investigation,
>>>>>> those reservations will be magnified. There can be legitimate
>>>>>> reasons. Tigers are
>>>>>> rare and need to be conserved, you can't let anyone who wants
>>>>>> have access to the
>>>>>> tigers to try to repeat the measurements. But there's also a
>>>>>> common illegitimate
>>>>>> reason put forwards by people who make extraordinary claims. If
>>>>>> the claims were
>>>>>> unexceptional, such as that tigers have a similar energy budget
>>>>>> to lions, then no-one
>>>>>> would be saying "Show me your notebooks. How do you know that
>>>>>> calorimeter was
>>>>>> calibrated accurately? What's the name of the person who took
>>>>>> that measurement
>>>>>> and can I interview them?" Extraordinary claims are put through
>>>>>> the wringer in a way
>>>>>> that ordinary ones are not. I've seen complaints about this from
>>>>>> parapsychologists.
>>>>>> But if you're going to claim to have discovered a new physical
>>>>>> principle, you need
>>>>>> to present rock solid evidence.
>>>>>>
>>>>>> In this case, we can't see H. We can only suggest explanations
>>>>>> for its behaviour.
>>>>> It seems that you simply lack the technical competence.
>>>>> Go back and look at my proof again.
>>>>>
>>>> Sorry no. I've been programming since I was a boy and I have a PhD
>>>> in a computational-
>>>> related subject. I'm confident of my technical abilities. What I
>>>> can't do of course
>>>> is tell you exactly what is going on in code I cannot see. I've
>>>> got a pretty good idea,
>>>> but I can only reconstruct on the basis of what you tell me. Ben
>>>> thinks that I've
>>>> got it wrong and in fact there are no nested emulations at all.
>>>> I've no way of actually
>>>> disproving that idea without seeing H.
>>>>
>>>
>>> To fully understand this a software engineer must be an expert in:
>>> (a) The C programming language,
>>> (b) The x86 programming language,
>>> (c) Exactly how C translates into x86 and,
>>> (d) The ability to recognize infinite recursion at the x86 assembly
>>> language level.
>>>
>>> Anyone having the above credentials can validate my work, if you
>>> cannot validate my work then you do not sufficiently have the above
>>> credentials.
>>>
>>> Exactly how C translates into x86 is mandatory. If you don't know
>>> how the C calling conventions are implemented in x86 you cannot
>>> validate my work.
>>>
>>> From a purely software engineering perspective H(P,P) is required
>>> to to correctly determine that its correct and complete x86
>>> emulation of its input would never reach the "ret" instruction of
>>> this input and H must do this in a finite number of steps.
>>>
>>> The ordinary semantics of standard C and the conventional x86
>>> language are the entire semantics required to conclusively prove
>>> that H(P,P) does correctly determine that its correct and complete
>>> x86 emulation of its input would never reach the "ret" instruction
>>> (final state) of this input thus never halts.
>>>
>>> The correct and complete x86 emulation of its input by H(P,P) would
>>> never reach the "ret" instruction of P because both H and P would
>>> remain stuck in infinitely nested emulation.
>>>
>>> void P(u32 x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>>
>>> _P()
>>> [00001202](01) 55 push ebp
>>> [00001203](02) 8bec mov ebp,esp
>>> [00001205](03) 8b4508 mov eax,[ebp+08]
>>> [00001208](01) 50 push eax
>>> [00001209](03) 8b4d08 mov ecx,[ebp+08]
>>> [0000120c](01) 51 push ecx
>>> [0000120d](05) e820feffff call 00001032
>>> [00001212](03) 83c408 add esp,+08
>>> [00001215](02) 85c0 test eax,eax
>>> [00001217](02) 7402 jz 0000121b
>>> [00001219](02) ebfe jmp 00001219
>>> [0000121b](01) 5d pop ebp
>>> [0000121c](01) c3 ret
>>> Size in bytes:(0027) [0000121c]
>>>
>>> _main()
>>> [00001222](01) 55 push ebp
>>> [00001223](02) 8bec mov ebp,esp
>>> [00001225](05) 6802120000 push 00001202
>>> [0000122a](05) 6802120000 push 00001202
>>> [0000122f](05) e8fefdffff call 00001032
>>> [00001234](03) 83c408 add esp,+08
>>> [00001237](01) 50 push eax
>>> [00001238](05) 68b3030000 push 000003b3
>>> [0000123d](05) e8c0f1ffff call 00000402
>>> [00001242](03) 83c408 add esp,+08
>>> [00001245](02) 33c0 xor eax,eax
>>> [00001247](01) 5d pop ebp
>>> [00001248](01) c3 ret
>>> Size in bytes:(0039) [00001248]
>>>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> [00001222][0010200f][00000000] 55 push ebp
>>> [00001223][0010200f][00000000] 8bec mov ebp,esp
>>> [00001225][0010200b][00001202] 6802120000 push 00001202 // push P
>>> [0000122a][00102007][00001202] 6802120000 push 00001202 // push P
>>> [0000122f][00102003][00001234] e8fefdffff call 00001032 // call
>>> executed H
>>>
>>> Begin Simulation Execution Trace Stored at:2120c3
>>> Address_of_H:1032
>>> [00001202][002120af][002120b3] 55 push ebp
>>> [00001203][002120af][002120b3] 8bec mov ebp,esp
>>> [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
>>> [00001208][002120ab][00001202] 50 push eax // push P
>>> [00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08]
>>> [0000120c][002120a7][00001202] 51 push ecx // push P
>>> [0000120d][002120a3][00001212] e820feffff call 00001032 // call
>>> emulated H Infinitely Recursive Simulation Detected Simulation
>>> Stopped
>>>
>>> H knows its own machine address and on this basis it can easily
>>> examine its stored execution_trace of P (see above) to determine:
>>> (a) P is calling H with the same arguments that H was called with.
>>> (b) No instructions in P could possibly escape this otherwise
>>> infinitely recursive emulation.
>>> (c) H aborts its emulation of P before its call to H is emulated.
>>>
>>
>> When you know that H simply implements the above algorithm there is
>> no need to see its source code. I am reserving the publication of the
>> 5 pages of the source code of the halt decider for journal
>> publication.
>
> Your H is not a pure function as it behaves differently depending on
> what is invoking it (it returns a decision answer to main() but not
> to P()) and it has side effects (aborting a simulation).
>
> /Flibble
>
Finally a critique that has a reasonable basis.
When I transformed H into a pure function of its inputs it always has
the same behavior no matter how it is invoked.
The x86 emulation of P is aborted before P invokes H.
--
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-25 16:21 +0100 |
| Message-ID | <20220625162150.00002837@reddwarf.jmc> |
| In reply to | #52946 |
On Sat, 25 Jun 2022 10:19:02 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 6/25/2022 10:09 AM, Mr Flibble wrote:
> > On Sat, 25 Jun 2022 10:03:17 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/25/2022 9:28 AM, olcott wrote:
> >>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
> >>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
> >>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
> >>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
> >>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
> >>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
> >>>>>>>> wrote:
> >>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>>>
> >>>>>>>>>> "Dry run" means that a human programmer looks at the code,
> >>>>>>>>>> and determines
> >>>>>>>>>> what it does, without actually executing it.
> >>>>>>>>>
> >>>>>>>>> Going back, now, to what you think needs to be resolved:
> >>>>>>>>> | He's dry-run P(P) and established that it doesn't halt.
> >>>>>>>>> He's invoked H
> >>>>>>>>> | on it and H reports that it doesn't halt. He's run P(P)
> >>>>>>>>> and it halts.
> >>>>>>>>> The obvious conclusion is that PO's dry run (if he has
> >>>>>>>>> indeed done such
> >>>>>>>>> a thing) is incorrect.
> >>>>>>>>>
> >>>>>>>> Exactly.
> >>>>>>>> We do our little energy budget on tigers, and find that
> >>>>>>>> tigers spend more energy
> >>>>>>>> than they take in. Well potentially this is dynamite. One
> >>>>>>>> explanation is that the
> >>>>>>>> law of conservation of energy is wrong.
> >>>>>>>> Except, before we countenance that explanation, we need to
> >>>>>>>> rule out a much
> >>>>>>>> simpler explanation. Which is that our measurements are
> >>>>>>>> wrong.
> >>>>>>>>
> >>>>>>>> Similarly, PO has worked out what he thinks P(P) should be
> >>>>>>>> doing, by dry-running
> >>>>>>>> it, and then actually run P(P) and obtained a different
> >>>>>>>> result. He also found that H
> >>>>>>>> agreed with the dry run. It's hard to paraphrase his
> >>>>>>>> conclusion, but it is extensive
> >>>>>>>> and far-reaching in its implications. The behaviour of code
> >>>>>>>> when run is different
> >>>>>>>> from the correct behaviour of the code when simulated. If
> >>>>>>>> that's true, then it has
> >>>>>>>> similar implications for computer science that disproving the
> >>>>>>>> conservation law
> >>>>>>>> has for physics.
> >>>>>>>>
> >>>>>>>> But the obvious explanation is that the dry-run was
> >>>>>>>> incorrect. Lots of people have
> >>>>>>>> suggested why it is incorrect. But they can't actually see
> >>>>>>>> the code. PO needs to
> >>>>>>>> understand that no-one will accept the complicated,
> >>>>>>>> far-reaching explanation,
> >>>>>>>> until the simple explanation has been ruled out.
> >>>>>>>
> >>>>>>> I already proved that the dry run is correct.
> >>>>>>>
> >>>>>> Someone reports that tigers use more energy than they take in,
> >>>>>> and concludes that
> >>>>>> the energy conservation law is incorrect.
> >>>>>> Naturally, everyone is going to say "There must be some
> >>>>>> mistake. How were your
> >>>>>> measurements taken? Show us your calculations, maybe you've got
> >>>>>> your sums wrong."
> >>>>>>
> >>>>>> Now if they are also uncooperative about sharing the details of
> >>>>>> the investigation,
> >>>>>> those reservations will be magnified. There can be legitimate
> >>>>>> reasons. Tigers are
> >>>>>> rare and need to be conserved, you can't let anyone who wants
> >>>>>> have access to the
> >>>>>> tigers to try to repeat the measurements. But there's also a
> >>>>>> common illegitimate
> >>>>>> reason put forwards by people who make extraordinary claims. If
> >>>>>> the claims were
> >>>>>> unexceptional, such as that tigers have a similar energy budget
> >>>>>> to lions, then no-one
> >>>>>> would be saying "Show me your notebooks. How do you know that
> >>>>>> calorimeter was
> >>>>>> calibrated accurately? What's the name of the person who took
> >>>>>> that measurement
> >>>>>> and can I interview them?" Extraordinary claims are put through
> >>>>>> the wringer in a way
> >>>>>> that ordinary ones are not. I've seen complaints about this
> >>>>>> from parapsychologists.
> >>>>>> But if you're going to claim to have discovered a new physical
> >>>>>> principle, you need
> >>>>>> to present rock solid evidence.
> >>>>>>
> >>>>>> In this case, we can't see H. We can only suggest explanations
> >>>>>> for its behaviour.
> >>>>> It seems that you simply lack the technical competence.
> >>>>> Go back and look at my proof again.
> >>>>>
> >>>> Sorry no. I've been programming since I was a boy and I have a
> >>>> PhD in a computational-
> >>>> related subject. I'm confident of my technical abilities. What I
> >>>> can't do of course
> >>>> is tell you exactly what is going on in code I cannot see. I've
> >>>> got a pretty good idea,
> >>>> but I can only reconstruct on the basis of what you tell me. Ben
> >>>> thinks that I've
> >>>> got it wrong and in fact there are no nested emulations at all.
> >>>> I've no way of actually
> >>>> disproving that idea without seeing H.
> >>>>
> >>>
> >>> To fully understand this a software engineer must be an expert in:
> >>> (a) The C programming language,
> >>> (b) The x86 programming language,
> >>> (c) Exactly how C translates into x86 and,
> >>> (d) The ability to recognize infinite recursion at the x86
> >>> assembly language level.
> >>>
> >>> Anyone having the above credentials can validate my work, if you
> >>> cannot validate my work then you do not sufficiently have the
> >>> above credentials.
> >>>
> >>> Exactly how C translates into x86 is mandatory. If you don't know
> >>> how the C calling conventions are implemented in x86 you cannot
> >>> validate my work.
> >>>
> >>> From a purely software engineering perspective H(P,P) is
> >>> required to to correctly determine that its correct and complete
> >>> x86 emulation of its input would never reach the "ret"
> >>> instruction of this input and H must do this in a finite number
> >>> of steps.
> >>>
> >>> The ordinary semantics of standard C and the conventional x86
> >>> language are the entire semantics required to conclusively prove
> >>> that H(P,P) does correctly determine that its correct and complete
> >>> x86 emulation of its input would never reach the "ret" instruction
> >>> (final state) of this input thus never halts.
> >>>
> >>> The correct and complete x86 emulation of its input by H(P,P)
> >>> would never reach the "ret" instruction of P because both H and P
> >>> would remain stuck in infinitely nested emulation.
> >>>
> >>> void P(u32 x)
> >>> {
> >>> if (H(x, x))
> >>> HERE: goto HERE;
> >>> return;
> >>> }
> >>>
> >>> int main()
> >>> {
> >>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>> }
> >>>
> >>> _P()
> >>> [00001202](01) 55 push ebp
> >>> [00001203](02) 8bec mov ebp,esp
> >>> [00001205](03) 8b4508 mov eax,[ebp+08]
> >>> [00001208](01) 50 push eax
> >>> [00001209](03) 8b4d08 mov ecx,[ebp+08]
> >>> [0000120c](01) 51 push ecx
> >>> [0000120d](05) e820feffff call 00001032
> >>> [00001212](03) 83c408 add esp,+08
> >>> [00001215](02) 85c0 test eax,eax
> >>> [00001217](02) 7402 jz 0000121b
> >>> [00001219](02) ebfe jmp 00001219
> >>> [0000121b](01) 5d pop ebp
> >>> [0000121c](01) c3 ret
> >>> Size in bytes:(0027) [0000121c]
> >>>
> >>> _main()
> >>> [00001222](01) 55 push ebp
> >>> [00001223](02) 8bec mov ebp,esp
> >>> [00001225](05) 6802120000 push 00001202
> >>> [0000122a](05) 6802120000 push 00001202
> >>> [0000122f](05) e8fefdffff call 00001032
> >>> [00001234](03) 83c408 add esp,+08
> >>> [00001237](01) 50 push eax
> >>> [00001238](05) 68b3030000 push 000003b3
> >>> [0000123d](05) e8c0f1ffff call 00000402
> >>> [00001242](03) 83c408 add esp,+08
> >>> [00001245](02) 33c0 xor eax,eax
> >>> [00001247](01) 5d pop ebp
> >>> [00001248](01) c3 ret
> >>> Size in bytes:(0039) [00001248]
> >>>
> >>> machine stack stack machine assembly
> >>> address address data code language
> >>> ======== ======== ======== ========= =============
> >>> [00001222][0010200f][00000000] 55 push ebp
> >>> [00001223][0010200f][00000000] 8bec mov ebp,esp
> >>> [00001225][0010200b][00001202] 6802120000 push 00001202 // push P
> >>> [0000122a][00102007][00001202] 6802120000 push 00001202 // push P
> >>> [0000122f][00102003][00001234] e8fefdffff call 00001032 // call
> >>> executed H
> >>>
> >>> Begin Simulation Execution Trace Stored at:2120c3
> >>> Address_of_H:1032
> >>> [00001202][002120af][002120b3] 55 push ebp
> >>> [00001203][002120af][002120b3] 8bec mov ebp,esp
> >>> [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
> >>> [00001208][002120ab][00001202] 50 push eax // push P
> >>> [00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08]
> >>> [0000120c][002120a7][00001202] 51 push ecx // push P
> >>> [0000120d][002120a3][00001212] e820feffff call 00001032 // call
> >>> emulated H Infinitely Recursive Simulation Detected Simulation
> >>> Stopped
> >>>
> >>> H knows its own machine address and on this basis it can easily
> >>> examine its stored execution_trace of P (see above) to determine:
> >>> (a) P is calling H with the same arguments that H was called with.
> >>> (b) No instructions in P could possibly escape this otherwise
> >>> infinitely recursive emulation.
> >>> (c) H aborts its emulation of P before its call to H is emulated.
> >>>
> >>
> >> When you know that H simply implements the above algorithm there is
> >> no need to see its source code. I am reserving the publication of
> >> the 5 pages of the source code of the halt decider for journal
> >> publication.
> >
> > Your H is not a pure function as it behaves differently depending on
> > what is invoking it (it returns a decision answer to main() but not
> > to P()) and it has side effects (aborting a simulation).
> >
> > /Flibble
> >
>
> Finally a critique that has a reasonable basis.
>
> When I transformed H into a pure function of its inputs it always has
> the same behavior no matter how it is invoked.
>
> The x86 emulation of P is aborted before P invokes H.
Nope. Preventing a call to H is equivalent to H behaving differently
for same inputs. Aborting a simulation is a side effect: pure functions
do not have side effects.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-25 10:54 -0500 |
| Message-ID | <676dnb21wJs7sir_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52947 |
On 6/25/2022 10:21 AM, Mr Flibble wrote:
> On Sat, 25 Jun 2022 10:19:02 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 10:09 AM, Mr Flibble wrote:
>>> On Sat, 25 Jun 2022 10:03:17 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/25/2022 9:28 AM, olcott wrote:
>>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
>>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
>>>>>>>>>> wrote:
>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> "Dry run" means that a human programmer looks at the code,
>>>>>>>>>>>> and determines
>>>>>>>>>>>> what it does, without actually executing it.
>>>>>>>>>>>
>>>>>>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt.
>>>>>>>>>>> He's invoked H
>>>>>>>>>>> | on it and H reports that it doesn't halt. He's run P(P)
>>>>>>>>>>> and it halts.
>>>>>>>>>>> The obvious conclusion is that PO's dry run (if he has
>>>>>>>>>>> indeed done such
>>>>>>>>>>> a thing) is incorrect.
>>>>>>>>>>>
>>>>>>>>>> Exactly.
>>>>>>>>>> We do our little energy budget on tigers, and find that
>>>>>>>>>> tigers spend more energy
>>>>>>>>>> than they take in. Well potentially this is dynamite. One
>>>>>>>>>> explanation is that the
>>>>>>>>>> law of conservation of energy is wrong.
>>>>>>>>>> Except, before we countenance that explanation, we need to
>>>>>>>>>> rule out a much
>>>>>>>>>> simpler explanation. Which is that our measurements are
>>>>>>>>>> wrong.
>>>>>>>>>>
>>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should be
>>>>>>>>>> doing, by dry-running
>>>>>>>>>> it, and then actually run P(P) and obtained a different
>>>>>>>>>> result. He also found that H
>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
>>>>>>>>>> conclusion, but it is extensive
>>>>>>>>>> and far-reaching in its implications. The behaviour of code
>>>>>>>>>> when run is different
>>>>>>>>>> from the correct behaviour of the code when simulated. If
>>>>>>>>>> that's true, then it has
>>>>>>>>>> similar implications for computer science that disproving the
>>>>>>>>>> conservation law
>>>>>>>>>> has for physics.
>>>>>>>>>>
>>>>>>>>>> But the obvious explanation is that the dry-run was
>>>>>>>>>> incorrect. Lots of people have
>>>>>>>>>> suggested why it is incorrect. But they can't actually see
>>>>>>>>>> the code. PO needs to
>>>>>>>>>> understand that no-one will accept the complicated,
>>>>>>>>>> far-reaching explanation,
>>>>>>>>>> until the simple explanation has been ruled out.
>>>>>>>>>
>>>>>>>>> I already proved that the dry run is correct.
>>>>>>>>>
>>>>>>>> Someone reports that tigers use more energy than they take in,
>>>>>>>> and concludes that
>>>>>>>> the energy conservation law is incorrect.
>>>>>>>> Naturally, everyone is going to say "There must be some
>>>>>>>> mistake. How were your
>>>>>>>> measurements taken? Show us your calculations, maybe you've got
>>>>>>>> your sums wrong."
>>>>>>>>
>>>>>>>> Now if they are also uncooperative about sharing the details of
>>>>>>>> the investigation,
>>>>>>>> those reservations will be magnified. There can be legitimate
>>>>>>>> reasons. Tigers are
>>>>>>>> rare and need to be conserved, you can't let anyone who wants
>>>>>>>> have access to the
>>>>>>>> tigers to try to repeat the measurements. But there's also a
>>>>>>>> common illegitimate
>>>>>>>> reason put forwards by people who make extraordinary claims. If
>>>>>>>> the claims were
>>>>>>>> unexceptional, such as that tigers have a similar energy budget
>>>>>>>> to lions, then no-one
>>>>>>>> would be saying "Show me your notebooks. How do you know that
>>>>>>>> calorimeter was
>>>>>>>> calibrated accurately? What's the name of the person who took
>>>>>>>> that measurement
>>>>>>>> and can I interview them?" Extraordinary claims are put through
>>>>>>>> the wringer in a way
>>>>>>>> that ordinary ones are not. I've seen complaints about this
>>>>>>>> from parapsychologists.
>>>>>>>> But if you're going to claim to have discovered a new physical
>>>>>>>> principle, you need
>>>>>>>> to present rock solid evidence.
>>>>>>>>
>>>>>>>> In this case, we can't see H. We can only suggest explanations
>>>>>>>> for its behaviour.
>>>>>>> It seems that you simply lack the technical competence.
>>>>>>> Go back and look at my proof again.
>>>>>>>
>>>>>> Sorry no. I've been programming since I was a boy and I have a
>>>>>> PhD in a computational-
>>>>>> related subject. I'm confident of my technical abilities. What I
>>>>>> can't do of course
>>>>>> is tell you exactly what is going on in code I cannot see. I've
>>>>>> got a pretty good idea,
>>>>>> but I can only reconstruct on the basis of what you tell me. Ben
>>>>>> thinks that I've
>>>>>> got it wrong and in fact there are no nested emulations at all.
>>>>>> I've no way of actually
>>>>>> disproving that idea without seeing H.
>>>>>>
>>>>>
>>>>> To fully understand this a software engineer must be an expert in:
>>>>> (a) The C programming language,
>>>>> (b) The x86 programming language,
>>>>> (c) Exactly how C translates into x86 and,
>>>>> (d) The ability to recognize infinite recursion at the x86
>>>>> assembly language level.
>>>>>
>>>>> Anyone having the above credentials can validate my work, if you
>>>>> cannot validate my work then you do not sufficiently have the
>>>>> above credentials.
>>>>>
>>>>> Exactly how C translates into x86 is mandatory. If you don't know
>>>>> how the C calling conventions are implemented in x86 you cannot
>>>>> validate my work.
>>>>>
>>>>> From a purely software engineering perspective H(P,P) is
>>>>> required to to correctly determine that its correct and complete
>>>>> x86 emulation of its input would never reach the "ret"
>>>>> instruction of this input and H must do this in a finite number
>>>>> of steps.
>>>>>
>>>>> The ordinary semantics of standard C and the conventional x86
>>>>> language are the entire semantics required to conclusively prove
>>>>> that H(P,P) does correctly determine that its correct and complete
>>>>> x86 emulation of its input would never reach the "ret" instruction
>>>>> (final state) of this input thus never halts.
>>>>>
>>>>> The correct and complete x86 emulation of its input by H(P,P)
>>>>> would never reach the "ret" instruction of P because both H and P
>>>>> would remain stuck in infinitely nested emulation.
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [00001202](01) 55 push ebp
>>>>> [00001203](02) 8bec mov ebp,esp
>>>>> [00001205](03) 8b4508 mov eax,[ebp+08]
>>>>> [00001208](01) 50 push eax
>>>>> [00001209](03) 8b4d08 mov ecx,[ebp+08]
>>>>> [0000120c](01) 51 push ecx
>>>>> [0000120d](05) e820feffff call 00001032
>>>>> [00001212](03) 83c408 add esp,+08
>>>>> [00001215](02) 85c0 test eax,eax
>>>>> [00001217](02) 7402 jz 0000121b
>>>>> [00001219](02) ebfe jmp 00001219
>>>>> [0000121b](01) 5d pop ebp
>>>>> [0000121c](01) c3 ret
>>>>> Size in bytes:(0027) [0000121c]
>>>>>
>>>>> _main()
>>>>> [00001222](01) 55 push ebp
>>>>> [00001223](02) 8bec mov ebp,esp
>>>>> [00001225](05) 6802120000 push 00001202
>>>>> [0000122a](05) 6802120000 push 00001202
>>>>> [0000122f](05) e8fefdffff call 00001032
>>>>> [00001234](03) 83c408 add esp,+08
>>>>> [00001237](01) 50 push eax
>>>>> [00001238](05) 68b3030000 push 000003b3
>>>>> [0000123d](05) e8c0f1ffff call 00000402
>>>>> [00001242](03) 83c408 add esp,+08
>>>>> [00001245](02) 33c0 xor eax,eax
>>>>> [00001247](01) 5d pop ebp
>>>>> [00001248](01) c3 ret
>>>>> Size in bytes:(0039) [00001248]
>>>>>
>>>>> machine stack stack machine assembly
>>>>> address address data code language
>>>>> ======== ======== ======== ========= =============
>>>>> [00001222][0010200f][00000000] 55 push ebp
>>>>> [00001223][0010200f][00000000] 8bec mov ebp,esp
>>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 // push P
>>>>> [0000122a][00102007][00001202] 6802120000 push 00001202 // push P
>>>>> [0000122f][00102003][00001234] e8fefdffff call 00001032 // call
>>>>> executed H
>>>>>
>>>>> Begin Simulation Execution Trace Stored at:2120c3
>>>>> Address_of_H:1032
>>>>> [00001202][002120af][002120b3] 55 push ebp
>>>>> [00001203][002120af][002120b3] 8bec mov ebp,esp
>>>>> [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
>>>>> [00001208][002120ab][00001202] 50 push eax // push P
>>>>> [00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08]
>>>>> [0000120c][002120a7][00001202] 51 push ecx // push P
>>>>> [0000120d][002120a3][00001212] e820feffff call 00001032 // call
>>>>> emulated H Infinitely Recursive Simulation Detected Simulation
>>>>> Stopped
>>>>>
>>>>> H knows its own machine address and on this basis it can easily
>>>>> examine its stored execution_trace of P (see above) to determine:
>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>> (b) No instructions in P could possibly escape this otherwise
>>>>> infinitely recursive emulation.
>>>>> (c) H aborts its emulation of P before its call to H is emulated.
>>>>>
>>>>
>>>> When you know that H simply implements the above algorithm there is
>>>> no need to see its source code. I am reserving the publication of
>>>> the 5 pages of the source code of the halt decider for journal
>>>> publication.
>>>
>>> Your H is not a pure function as it behaves differently depending on
>>> what is invoking it (it returns a decision answer to main() but not
>>> to P()) and it has side effects (aborting a simulation).
>>>
>>> /Flibble
>>>
>>
>> Finally a critique that has a reasonable basis.
>>
>> When I transformed H into a pure function of its inputs it always has
>> the same behavior no matter how it is invoked.
>>
>> The x86 emulation of P is aborted before P invokes H.
>
> Nope. Preventing a call to H is equivalent to H behaving differently
> for same inputs. Aborting a simulation is a side effect: pure functions
> do not have side effects.
>
> /Flibble
>
In other words you are saying that a halt decider is simply not allowed
to report when it correctly detects that it is being called in
infinitely recursive simulation.
We could also "prove" that a correct halt decider is impossible by
making another similar rule that halt deciders are simply not allowed to
report on infinite loops.
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior of these actual inputs.
When a simulating halt decider rejects all inputs as non-halting
whenever it correctly detects [in a finite number of steps] that its
correct and complete simulation of its input would never reach [a] final
state of this input then all [these] inputs (including pathological
inputs) are decided correctly.
--
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-25 16:59 +0100 |
| Message-ID | <20220625165919.0000287e@reddwarf.jmc> |
| In reply to | #52948 |
On Sat, 25 Jun 2022 10:54:13 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 6/25/2022 10:21 AM, Mr Flibble wrote:
> > On Sat, 25 Jun 2022 10:19:02 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/25/2022 10:09 AM, Mr Flibble wrote:
> >>> On Sat, 25 Jun 2022 10:03:17 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/25/2022 9:28 AM, olcott wrote:
> >>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
> >>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
> >>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
> >>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
> >>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
> >>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
> >>>>>>>>>> wrote:
> >>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>>>>>
> >>>>>>>>>>>> "Dry run" means that a human programmer looks at the
> >>>>>>>>>>>> code, and determines
> >>>>>>>>>>>> what it does, without actually executing it.
> >>>>>>>>>>>
> >>>>>>>>>>> Going back, now, to what you think needs to be resolved:
> >>>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt.
> >>>>>>>>>>> He's invoked H
> >>>>>>>>>>> | on it and H reports that it doesn't halt. He's run P(P)
> >>>>>>>>>>> and it halts.
> >>>>>>>>>>> The obvious conclusion is that PO's dry run (if he has
> >>>>>>>>>>> indeed done such
> >>>>>>>>>>> a thing) is incorrect.
> >>>>>>>>>>>
> >>>>>>>>>> Exactly.
> >>>>>>>>>> We do our little energy budget on tigers, and find that
> >>>>>>>>>> tigers spend more energy
> >>>>>>>>>> than they take in. Well potentially this is dynamite. One
> >>>>>>>>>> explanation is that the
> >>>>>>>>>> law of conservation of energy is wrong.
> >>>>>>>>>> Except, before we countenance that explanation, we need to
> >>>>>>>>>> rule out a much
> >>>>>>>>>> simpler explanation. Which is that our measurements are
> >>>>>>>>>> wrong.
> >>>>>>>>>>
> >>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should be
> >>>>>>>>>> doing, by dry-running
> >>>>>>>>>> it, and then actually run P(P) and obtained a different
> >>>>>>>>>> result. He also found that H
> >>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
> >>>>>>>>>> conclusion, but it is extensive
> >>>>>>>>>> and far-reaching in its implications. The behaviour of code
> >>>>>>>>>> when run is different
> >>>>>>>>>> from the correct behaviour of the code when simulated. If
> >>>>>>>>>> that's true, then it has
> >>>>>>>>>> similar implications for computer science that disproving
> >>>>>>>>>> the conservation law
> >>>>>>>>>> has for physics.
> >>>>>>>>>>
> >>>>>>>>>> But the obvious explanation is that the dry-run was
> >>>>>>>>>> incorrect. Lots of people have
> >>>>>>>>>> suggested why it is incorrect. But they can't actually see
> >>>>>>>>>> the code. PO needs to
> >>>>>>>>>> understand that no-one will accept the complicated,
> >>>>>>>>>> far-reaching explanation,
> >>>>>>>>>> until the simple explanation has been ruled out.
> >>>>>>>>>
> >>>>>>>>> I already proved that the dry run is correct.
> >>>>>>>>>
> >>>>>>>> Someone reports that tigers use more energy than they take
> >>>>>>>> in, and concludes that
> >>>>>>>> the energy conservation law is incorrect.
> >>>>>>>> Naturally, everyone is going to say "There must be some
> >>>>>>>> mistake. How were your
> >>>>>>>> measurements taken? Show us your calculations, maybe you've
> >>>>>>>> got your sums wrong."
> >>>>>>>>
> >>>>>>>> Now if they are also uncooperative about sharing the details
> >>>>>>>> of the investigation,
> >>>>>>>> those reservations will be magnified. There can be legitimate
> >>>>>>>> reasons. Tigers are
> >>>>>>>> rare and need to be conserved, you can't let anyone who wants
> >>>>>>>> have access to the
> >>>>>>>> tigers to try to repeat the measurements. But there's also a
> >>>>>>>> common illegitimate
> >>>>>>>> reason put forwards by people who make extraordinary claims.
> >>>>>>>> If the claims were
> >>>>>>>> unexceptional, such as that tigers have a similar energy
> >>>>>>>> budget to lions, then no-one
> >>>>>>>> would be saying "Show me your notebooks. How do you know that
> >>>>>>>> calorimeter was
> >>>>>>>> calibrated accurately? What's the name of the person who took
> >>>>>>>> that measurement
> >>>>>>>> and can I interview them?" Extraordinary claims are put
> >>>>>>>> through the wringer in a way
> >>>>>>>> that ordinary ones are not. I've seen complaints about this
> >>>>>>>> from parapsychologists.
> >>>>>>>> But if you're going to claim to have discovered a new
> >>>>>>>> physical principle, you need
> >>>>>>>> to present rock solid evidence.
> >>>>>>>>
> >>>>>>>> In this case, we can't see H. We can only suggest
> >>>>>>>> explanations for its behaviour.
> >>>>>>> It seems that you simply lack the technical competence.
> >>>>>>> Go back and look at my proof again.
> >>>>>>>
> >>>>>> Sorry no. I've been programming since I was a boy and I have a
> >>>>>> PhD in a computational-
> >>>>>> related subject. I'm confident of my technical abilities. What
> >>>>>> I can't do of course
> >>>>>> is tell you exactly what is going on in code I cannot see. I've
> >>>>>> got a pretty good idea,
> >>>>>> but I can only reconstruct on the basis of what you tell me.
> >>>>>> Ben thinks that I've
> >>>>>> got it wrong and in fact there are no nested emulations at all.
> >>>>>> I've no way of actually
> >>>>>> disproving that idea without seeing H.
> >>>>>>
> >>>>>
> >>>>> To fully understand this a software engineer must be an expert
> >>>>> in: (a) The C programming language,
> >>>>> (b) The x86 programming language,
> >>>>> (c) Exactly how C translates into x86 and,
> >>>>> (d) The ability to recognize infinite recursion at the x86
> >>>>> assembly language level.
> >>>>>
> >>>>> Anyone having the above credentials can validate my work, if you
> >>>>> cannot validate my work then you do not sufficiently have the
> >>>>> above credentials.
> >>>>>
> >>>>> Exactly how C translates into x86 is mandatory. If you don't
> >>>>> know how the C calling conventions are implemented in x86 you
> >>>>> cannot validate my work.
> >>>>>
> >>>>> From a purely software engineering perspective H(P,P) is
> >>>>> required to to correctly determine that its correct and complete
> >>>>> x86 emulation of its input would never reach the "ret"
> >>>>> instruction of this input and H must do this in a finite number
> >>>>> of steps.
> >>>>>
> >>>>> The ordinary semantics of standard C and the conventional x86
> >>>>> language are the entire semantics required to conclusively prove
> >>>>> that H(P,P) does correctly determine that its correct and
> >>>>> complete x86 emulation of its input would never reach the "ret"
> >>>>> instruction (final state) of this input thus never halts.
> >>>>>
> >>>>> The correct and complete x86 emulation of its input by H(P,P)
> >>>>> would never reach the "ret" instruction of P because both H and
> >>>>> P would remain stuck in infinitely nested emulation.
> >>>>>
> >>>>> void P(u32 x)
> >>>>> {
> >>>>> if (H(x, x))
> >>>>> HERE: goto HERE;
> >>>>> return;
> >>>>> }
> >>>>>
> >>>>> int main()
> >>>>> {
> >>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>> }
> >>>>>
> >>>>> _P()
> >>>>> [00001202](01) 55 push ebp
> >>>>> [00001203](02) 8bec mov ebp,esp
> >>>>> [00001205](03) 8b4508 mov eax,[ebp+08]
> >>>>> [00001208](01) 50 push eax
> >>>>> [00001209](03) 8b4d08 mov ecx,[ebp+08]
> >>>>> [0000120c](01) 51 push ecx
> >>>>> [0000120d](05) e820feffff call 00001032
> >>>>> [00001212](03) 83c408 add esp,+08
> >>>>> [00001215](02) 85c0 test eax,eax
> >>>>> [00001217](02) 7402 jz 0000121b
> >>>>> [00001219](02) ebfe jmp 00001219
> >>>>> [0000121b](01) 5d pop ebp
> >>>>> [0000121c](01) c3 ret
> >>>>> Size in bytes:(0027) [0000121c]
> >>>>>
> >>>>> _main()
> >>>>> [00001222](01) 55 push ebp
> >>>>> [00001223](02) 8bec mov ebp,esp
> >>>>> [00001225](05) 6802120000 push 00001202
> >>>>> [0000122a](05) 6802120000 push 00001202
> >>>>> [0000122f](05) e8fefdffff call 00001032
> >>>>> [00001234](03) 83c408 add esp,+08
> >>>>> [00001237](01) 50 push eax
> >>>>> [00001238](05) 68b3030000 push 000003b3
> >>>>> [0000123d](05) e8c0f1ffff call 00000402
> >>>>> [00001242](03) 83c408 add esp,+08
> >>>>> [00001245](02) 33c0 xor eax,eax
> >>>>> [00001247](01) 5d pop ebp
> >>>>> [00001248](01) c3 ret
> >>>>> Size in bytes:(0039) [00001248]
> >>>>>
> >>>>> machine stack stack machine assembly
> >>>>> address address data code language
> >>>>> ======== ======== ======== ========= =============
> >>>>> [00001222][0010200f][00000000] 55 push ebp
> >>>>> [00001223][0010200f][00000000] 8bec mov ebp,esp
> >>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 // push
> >>>>> P [0000122a][00102007][00001202] 6802120000 push 00001202 //
> >>>>> push P [0000122f][00102003][00001234] e8fefdffff call 00001032
> >>>>> // call executed H
> >>>>>
> >>>>> Begin Simulation Execution Trace Stored at:2120c3
> >>>>> Address_of_H:1032
> >>>>> [00001202][002120af][002120b3] 55 push ebp
> >>>>> [00001203][002120af][002120b3] 8bec mov ebp,esp
> >>>>> [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
> >>>>> [00001208][002120ab][00001202] 50 push eax // push
> >>>>> P [00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08]
> >>>>> [0000120c][002120a7][00001202] 51 push ecx // push
> >>>>> P [0000120d][002120a3][00001212] e820feffff call 00001032 //
> >>>>> call emulated H Infinitely Recursive Simulation Detected
> >>>>> Simulation Stopped
> >>>>>
> >>>>> H knows its own machine address and on this basis it can easily
> >>>>> examine its stored execution_trace of P (see above) to
> >>>>> determine: (a) P is calling H with the same arguments that H
> >>>>> was called with. (b) No instructions in P could possibly escape
> >>>>> this otherwise infinitely recursive emulation.
> >>>>> (c) H aborts its emulation of P before its call to H is
> >>>>> emulated.
> >>>>
> >>>> When you know that H simply implements the above algorithm there
> >>>> is no need to see its source code. I am reserving the
> >>>> publication of the 5 pages of the source code of the halt
> >>>> decider for journal publication.
> >>>
> >>> Your H is not a pure function as it behaves differently depending
> >>> on what is invoking it (it returns a decision answer to main()
> >>> but not to P()) and it has side effects (aborting a simulation).
> >>>
> >>> /Flibble
> >>>
> >>
> >> Finally a critique that has a reasonable basis.
> >>
> >> When I transformed H into a pure function of its inputs it always
> >> has the same behavior no matter how it is invoked.
> >>
> >> The x86 emulation of P is aborted before P invokes H.
> >
> > Nope. Preventing a call to H is equivalent to H behaving differently
> > for same inputs. Aborting a simulation is a side effect: pure
> > functions do not have side effects.
> >
> > /Flibble
> >
>
> In other words you are saying that a halt decider is simply not
> allowed to report when it correctly detects that it is being called
> in infinitely recursive simulation.
I keep telling you this: the infinite recursion is NOT present when
using a valid halt decider: your H is NOT a valid halt
decider.
Simulation is an erroneous approach as a simulating halt decider
can not answer in finite time for a non-halting input as there is no
proven general solution for detecting non-halting behaviour.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-25 11:06 -0500 |
| Message-ID | <_K6dnVgtXJforyr_nZ2dnUU7_8xh4p2d@giganews.com> |
| In reply to | #52949 |
On 6/25/2022 10:59 AM, Mr Flibble wrote:
> On Sat, 25 Jun 2022 10:54:13 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 10:21 AM, Mr Flibble wrote:
>>> On Sat, 25 Jun 2022 10:19:02 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/25/2022 10:09 AM, Mr Flibble wrote:
>>>>> On Sat, 25 Jun 2022 10:03:17 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/25/2022 9:28 AM, olcott wrote:
>>>>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
>>>>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>>>>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>>>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>>>>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> "Dry run" means that a human programmer looks at the
>>>>>>>>>>>>>> code, and determines
>>>>>>>>>>>>>> what it does, without actually executing it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt.
>>>>>>>>>>>>> He's invoked H
>>>>>>>>>>>>> | on it and H reports that it doesn't halt. He's run P(P)
>>>>>>>>>>>>> and it halts.
>>>>>>>>>>>>> The obvious conclusion is that PO's dry run (if he has
>>>>>>>>>>>>> indeed done such
>>>>>>>>>>>>> a thing) is incorrect.
>>>>>>>>>>>>>
>>>>>>>>>>>> Exactly.
>>>>>>>>>>>> We do our little energy budget on tigers, and find that
>>>>>>>>>>>> tigers spend more energy
>>>>>>>>>>>> than they take in. Well potentially this is dynamite. One
>>>>>>>>>>>> explanation is that the
>>>>>>>>>>>> law of conservation of energy is wrong.
>>>>>>>>>>>> Except, before we countenance that explanation, we need to
>>>>>>>>>>>> rule out a much
>>>>>>>>>>>> simpler explanation. Which is that our measurements are
>>>>>>>>>>>> wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should be
>>>>>>>>>>>> doing, by dry-running
>>>>>>>>>>>> it, and then actually run P(P) and obtained a different
>>>>>>>>>>>> result. He also found that H
>>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
>>>>>>>>>>>> conclusion, but it is extensive
>>>>>>>>>>>> and far-reaching in its implications. The behaviour of code
>>>>>>>>>>>> when run is different
>>>>>>>>>>>> from the correct behaviour of the code when simulated. If
>>>>>>>>>>>> that's true, then it has
>>>>>>>>>>>> similar implications for computer science that disproving
>>>>>>>>>>>> the conservation law
>>>>>>>>>>>> has for physics.
>>>>>>>>>>>>
>>>>>>>>>>>> But the obvious explanation is that the dry-run was
>>>>>>>>>>>> incorrect. Lots of people have
>>>>>>>>>>>> suggested why it is incorrect. But they can't actually see
>>>>>>>>>>>> the code. PO needs to
>>>>>>>>>>>> understand that no-one will accept the complicated,
>>>>>>>>>>>> far-reaching explanation,
>>>>>>>>>>>> until the simple explanation has been ruled out.
>>>>>>>>>>>
>>>>>>>>>>> I already proved that the dry run is correct.
>>>>>>>>>>>
>>>>>>>>>> Someone reports that tigers use more energy than they take
>>>>>>>>>> in, and concludes that
>>>>>>>>>> the energy conservation law is incorrect.
>>>>>>>>>> Naturally, everyone is going to say "There must be some
>>>>>>>>>> mistake. How were your
>>>>>>>>>> measurements taken? Show us your calculations, maybe you've
>>>>>>>>>> got your sums wrong."
>>>>>>>>>>
>>>>>>>>>> Now if they are also uncooperative about sharing the details
>>>>>>>>>> of the investigation,
>>>>>>>>>> those reservations will be magnified. There can be legitimate
>>>>>>>>>> reasons. Tigers are
>>>>>>>>>> rare and need to be conserved, you can't let anyone who wants
>>>>>>>>>> have access to the
>>>>>>>>>> tigers to try to repeat the measurements. But there's also a
>>>>>>>>>> common illegitimate
>>>>>>>>>> reason put forwards by people who make extraordinary claims.
>>>>>>>>>> If the claims were
>>>>>>>>>> unexceptional, such as that tigers have a similar energy
>>>>>>>>>> budget to lions, then no-one
>>>>>>>>>> would be saying "Show me your notebooks. How do you know that
>>>>>>>>>> calorimeter was
>>>>>>>>>> calibrated accurately? What's the name of the person who took
>>>>>>>>>> that measurement
>>>>>>>>>> and can I interview them?" Extraordinary claims are put
>>>>>>>>>> through the wringer in a way
>>>>>>>>>> that ordinary ones are not. I've seen complaints about this
>>>>>>>>>> from parapsychologists.
>>>>>>>>>> But if you're going to claim to have discovered a new
>>>>>>>>>> physical principle, you need
>>>>>>>>>> to present rock solid evidence.
>>>>>>>>>>
>>>>>>>>>> In this case, we can't see H. We can only suggest
>>>>>>>>>> explanations for its behaviour.
>>>>>>>>> It seems that you simply lack the technical competence.
>>>>>>>>> Go back and look at my proof again.
>>>>>>>>>
>>>>>>>> Sorry no. I've been programming since I was a boy and I have a
>>>>>>>> PhD in a computational-
>>>>>>>> related subject. I'm confident of my technical abilities. What
>>>>>>>> I can't do of course
>>>>>>>> is tell you exactly what is going on in code I cannot see. I've
>>>>>>>> got a pretty good idea,
>>>>>>>> but I can only reconstruct on the basis of what you tell me.
>>>>>>>> Ben thinks that I've
>>>>>>>> got it wrong and in fact there are no nested emulations at all.
>>>>>>>> I've no way of actually
>>>>>>>> disproving that idea without seeing H.
>>>>>>>>
>>>>>>>
>>>>>>> To fully understand this a software engineer must be an expert
>>>>>>> in: (a) The C programming language,
>>>>>>> (b) The x86 programming language,
>>>>>>> (c) Exactly how C translates into x86 and,
>>>>>>> (d) The ability to recognize infinite recursion at the x86
>>>>>>> assembly language level.
>>>>>>>
>>>>>>> Anyone having the above credentials can validate my work, if you
>>>>>>> cannot validate my work then you do not sufficiently have the
>>>>>>> above credentials.
>>>>>>>
>>>>>>> Exactly how C translates into x86 is mandatory. If you don't
>>>>>>> know how the C calling conventions are implemented in x86 you
>>>>>>> cannot validate my work.
>>>>>>>
>>>>>>> From a purely software engineering perspective H(P,P) is
>>>>>>> required to to correctly determine that its correct and complete
>>>>>>> x86 emulation of its input would never reach the "ret"
>>>>>>> instruction of this input and H must do this in a finite number
>>>>>>> of steps.
>>>>>>>
>>>>>>> The ordinary semantics of standard C and the conventional x86
>>>>>>> language are the entire semantics required to conclusively prove
>>>>>>> that H(P,P) does correctly determine that its correct and
>>>>>>> complete x86 emulation of its input would never reach the "ret"
>>>>>>> instruction (final state) of this input thus never halts.
>>>>>>>
>>>>>>> The correct and complete x86 emulation of its input by H(P,P)
>>>>>>> would never reach the "ret" instruction of P because both H and
>>>>>>> P would remain stuck in infinitely nested emulation.
>>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>> if (H(x, x))
>>>>>>> HERE: goto HERE;
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>> }
>>>>>>>
>>>>>>> _P()
>>>>>>> [00001202](01) 55 push ebp
>>>>>>> [00001203](02) 8bec mov ebp,esp
>>>>>>> [00001205](03) 8b4508 mov eax,[ebp+08]
>>>>>>> [00001208](01) 50 push eax
>>>>>>> [00001209](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>> [0000120c](01) 51 push ecx
>>>>>>> [0000120d](05) e820feffff call 00001032
>>>>>>> [00001212](03) 83c408 add esp,+08
>>>>>>> [00001215](02) 85c0 test eax,eax
>>>>>>> [00001217](02) 7402 jz 0000121b
>>>>>>> [00001219](02) ebfe jmp 00001219
>>>>>>> [0000121b](01) 5d pop ebp
>>>>>>> [0000121c](01) c3 ret
>>>>>>> Size in bytes:(0027) [0000121c]
>>>>>>>
>>>>>>> _main()
>>>>>>> [00001222](01) 55 push ebp
>>>>>>> [00001223](02) 8bec mov ebp,esp
>>>>>>> [00001225](05) 6802120000 push 00001202
>>>>>>> [0000122a](05) 6802120000 push 00001202
>>>>>>> [0000122f](05) e8fefdffff call 00001032
>>>>>>> [00001234](03) 83c408 add esp,+08
>>>>>>> [00001237](01) 50 push eax
>>>>>>> [00001238](05) 68b3030000 push 000003b3
>>>>>>> [0000123d](05) e8c0f1ffff call 00000402
>>>>>>> [00001242](03) 83c408 add esp,+08
>>>>>>> [00001245](02) 33c0 xor eax,eax
>>>>>>> [00001247](01) 5d pop ebp
>>>>>>> [00001248](01) c3 ret
>>>>>>> Size in bytes:(0039) [00001248]
>>>>>>>
>>>>>>> machine stack stack machine assembly
>>>>>>> address address data code language
>>>>>>> ======== ======== ======== ========= =============
>>>>>>> [00001222][0010200f][00000000] 55 push ebp
>>>>>>> [00001223][0010200f][00000000] 8bec mov ebp,esp
>>>>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 // push
>>>>>>> P [0000122a][00102007][00001202] 6802120000 push 00001202 //
>>>>>>> push P [0000122f][00102003][00001234] e8fefdffff call 00001032
>>>>>>> // call executed H
>>>>>>>
>>>>>>> Begin Simulation Execution Trace Stored at:2120c3
>>>>>>> Address_of_H:1032
>>>>>>> [00001202][002120af][002120b3] 55 push ebp
>>>>>>> [00001203][002120af][002120b3] 8bec mov ebp,esp
>>>>>>> [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
>>>>>>> [00001208][002120ab][00001202] 50 push eax // push
>>>>>>> P [00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08]
>>>>>>> [0000120c][002120a7][00001202] 51 push ecx // push
>>>>>>> P [0000120d][002120a3][00001212] e820feffff call 00001032 //
>>>>>>> call emulated H Infinitely Recursive Simulation Detected
>>>>>>> Simulation Stopped
>>>>>>>
>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>> examine its stored execution_trace of P (see above) to
>>>>>>> determine: (a) P is calling H with the same arguments that H
>>>>>>> was called with. (b) No instructions in P could possibly escape
>>>>>>> this otherwise infinitely recursive emulation.
>>>>>>> (c) H aborts its emulation of P before its call to H is
>>>>>>> emulated.
>>>>>>
>>>>>> When you know that H simply implements the above algorithm there
>>>>>> is no need to see its source code. I am reserving the
>>>>>> publication of the 5 pages of the source code of the halt
>>>>>> decider for journal publication.
>>>>>
>>>>> Your H is not a pure function as it behaves differently depending
>>>>> on what is invoking it (it returns a decision answer to main()
>>>>> but not to P()) and it has side effects (aborting a simulation).
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> Finally a critique that has a reasonable basis.
>>>>
>>>> When I transformed H into a pure function of its inputs it always
>>>> has the same behavior no matter how it is invoked.
>>>>
>>>> The x86 emulation of P is aborted before P invokes H.
>>>
>>> Nope. Preventing a call to H is equivalent to H behaving differently
>>> for same inputs. Aborting a simulation is a side effect: pure
>>> functions do not have side effects.
>>>
>>> /Flibble
>>>
>>
>> In other words you are saying that a halt decider is simply not
>> allowed to report when it correctly detects that it is being called
>> in infinitely recursive simulation.
>
> I keep telling you this: the infinite recursion is NOT present when
> using a valid halt decider: your H is NOT a valid halt
> decider.
>
> Simulation is an erroneous approach as a simulating halt decider
> can not answer in finite time for a non-halting input as there is no
> proven general solution for detecting non-halting behaviour.
>
> /Flibble
>
IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY YOU
DENY THIS VERIFIABLE FACT:
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and
P would remain stuck in infinitely nested emulation.
--
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-25 17:25 +0100 |
| Message-ID | <20220625172518.00002fb8@reddwarf.jmc> |
| In reply to | #52950 |
On Sat, 25 Jun 2022 11:06:12 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 6/25/2022 10:59 AM, Mr Flibble wrote:
> > On Sat, 25 Jun 2022 10:54:13 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/25/2022 10:21 AM, Mr Flibble wrote:
> >>> On Sat, 25 Jun 2022 10:19:02 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/25/2022 10:09 AM, Mr Flibble wrote:
> >>>>> On Sat, 25 Jun 2022 10:03:17 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 6/25/2022 9:28 AM, olcott wrote:
> >>>>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
> >>>>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
> >>>>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
> >>>>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
> >>>>>>>>>>
> >>>>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
> >>>>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> "Dry run" means that a human programmer looks at the
> >>>>>>>>>>>>>> code, and determines
> >>>>>>>>>>>>>> what it does, without actually executing it.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Going back, now, to what you think needs to be resolved:
> >>>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't
> >>>>>>>>>>>>> halt. He's invoked H
> >>>>>>>>>>>>> | on it and H reports that it doesn't halt. He's run
> >>>>>>>>>>>>> P(P) and it halts.
> >>>>>>>>>>>>> The obvious conclusion is that PO's dry run (if he has
> >>>>>>>>>>>>> indeed done such
> >>>>>>>>>>>>> a thing) is incorrect.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Exactly.
> >>>>>>>>>>>> We do our little energy budget on tigers, and find that
> >>>>>>>>>>>> tigers spend more energy
> >>>>>>>>>>>> than they take in. Well potentially this is dynamite. One
> >>>>>>>>>>>> explanation is that the
> >>>>>>>>>>>> law of conservation of energy is wrong.
> >>>>>>>>>>>> Except, before we countenance that explanation, we need
> >>>>>>>>>>>> to rule out a much
> >>>>>>>>>>>> simpler explanation. Which is that our measurements are
> >>>>>>>>>>>> wrong.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should
> >>>>>>>>>>>> be doing, by dry-running
> >>>>>>>>>>>> it, and then actually run P(P) and obtained a different
> >>>>>>>>>>>> result. He also found that H
> >>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
> >>>>>>>>>>>> conclusion, but it is extensive
> >>>>>>>>>>>> and far-reaching in its implications. The behaviour of
> >>>>>>>>>>>> code when run is different
> >>>>>>>>>>>> from the correct behaviour of the code when simulated. If
> >>>>>>>>>>>> that's true, then it has
> >>>>>>>>>>>> similar implications for computer science that disproving
> >>>>>>>>>>>> the conservation law
> >>>>>>>>>>>> has for physics.
> >>>>>>>>>>>>
> >>>>>>>>>>>> But the obvious explanation is that the dry-run was
> >>>>>>>>>>>> incorrect. Lots of people have
> >>>>>>>>>>>> suggested why it is incorrect. But they can't actually
> >>>>>>>>>>>> see the code. PO needs to
> >>>>>>>>>>>> understand that no-one will accept the complicated,
> >>>>>>>>>>>> far-reaching explanation,
> >>>>>>>>>>>> until the simple explanation has been ruled out.
> >>>>>>>>>>>
> >>>>>>>>>>> I already proved that the dry run is correct.
> >>>>>>>>>>>
> >>>>>>>>>> Someone reports that tigers use more energy than they take
> >>>>>>>>>> in, and concludes that
> >>>>>>>>>> the energy conservation law is incorrect.
> >>>>>>>>>> Naturally, everyone is going to say "There must be some
> >>>>>>>>>> mistake. How were your
> >>>>>>>>>> measurements taken? Show us your calculations, maybe you've
> >>>>>>>>>> got your sums wrong."
> >>>>>>>>>>
> >>>>>>>>>> Now if they are also uncooperative about sharing the
> >>>>>>>>>> details of the investigation,
> >>>>>>>>>> those reservations will be magnified. There can be
> >>>>>>>>>> legitimate reasons. Tigers are
> >>>>>>>>>> rare and need to be conserved, you can't let anyone who
> >>>>>>>>>> wants have access to the
> >>>>>>>>>> tigers to try to repeat the measurements. But there's also
> >>>>>>>>>> a common illegitimate
> >>>>>>>>>> reason put forwards by people who make extraordinary
> >>>>>>>>>> claims. If the claims were
> >>>>>>>>>> unexceptional, such as that tigers have a similar energy
> >>>>>>>>>> budget to lions, then no-one
> >>>>>>>>>> would be saying "Show me your notebooks. How do you know
> >>>>>>>>>> that calorimeter was
> >>>>>>>>>> calibrated accurately? What's the name of the person who
> >>>>>>>>>> took that measurement
> >>>>>>>>>> and can I interview them?" Extraordinary claims are put
> >>>>>>>>>> through the wringer in a way
> >>>>>>>>>> that ordinary ones are not. I've seen complaints about this
> >>>>>>>>>> from parapsychologists.
> >>>>>>>>>> But if you're going to claim to have discovered a new
> >>>>>>>>>> physical principle, you need
> >>>>>>>>>> to present rock solid evidence.
> >>>>>>>>>>
> >>>>>>>>>> In this case, we can't see H. We can only suggest
> >>>>>>>>>> explanations for its behaviour.
> >>>>>>>>> It seems that you simply lack the technical competence.
> >>>>>>>>> Go back and look at my proof again.
> >>>>>>>>>
> >>>>>>>> Sorry no. I've been programming since I was a boy and I have
> >>>>>>>> a PhD in a computational-
> >>>>>>>> related subject. I'm confident of my technical abilities.
> >>>>>>>> What I can't do of course
> >>>>>>>> is tell you exactly what is going on in code I cannot see.
> >>>>>>>> I've got a pretty good idea,
> >>>>>>>> but I can only reconstruct on the basis of what you tell me.
> >>>>>>>> Ben thinks that I've
> >>>>>>>> got it wrong and in fact there are no nested emulations at
> >>>>>>>> all. I've no way of actually
> >>>>>>>> disproving that idea without seeing H.
> >>>>>>>>
> >>>>>>>
> >>>>>>> To fully understand this a software engineer must be an expert
> >>>>>>> in: (a) The C programming language,
> >>>>>>> (b) The x86 programming language,
> >>>>>>> (c) Exactly how C translates into x86 and,
> >>>>>>> (d) The ability to recognize infinite recursion at the x86
> >>>>>>> assembly language level.
> >>>>>>>
> >>>>>>> Anyone having the above credentials can validate my work, if
> >>>>>>> you cannot validate my work then you do not sufficiently have
> >>>>>>> the above credentials.
> >>>>>>>
> >>>>>>> Exactly how C translates into x86 is mandatory. If you don't
> >>>>>>> know how the C calling conventions are implemented in x86 you
> >>>>>>> cannot validate my work.
> >>>>>>>
> >>>>>>> From a purely software engineering perspective H(P,P) is
> >>>>>>> required to to correctly determine that its correct and
> >>>>>>> complete x86 emulation of its input would never reach the
> >>>>>>> "ret" instruction of this input and H must do this in a
> >>>>>>> finite number of steps.
> >>>>>>>
> >>>>>>> The ordinary semantics of standard C and the conventional x86
> >>>>>>> language are the entire semantics required to conclusively
> >>>>>>> prove that H(P,P) does correctly determine that its correct
> >>>>>>> and complete x86 emulation of its input would never reach the
> >>>>>>> "ret" instruction (final state) of this input thus never
> >>>>>>> halts.
> >>>>>>>
> >>>>>>> The correct and complete x86 emulation of its input by H(P,P)
> >>>>>>> would never reach the "ret" instruction of P because both H
> >>>>>>> and P would remain stuck in infinitely nested emulation.
> >>>>>>>
> >>>>>>> void P(u32 x)
> >>>>>>> {
> >>>>>>> if (H(x, x))
> >>>>>>> HERE: goto HERE;
> >>>>>>> return;
> >>>>>>> }
> >>>>>>>
> >>>>>>> int main()
> >>>>>>> {
> >>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>> }
> >>>>>>>
> >>>>>>> _P()
> >>>>>>> [00001202](01) 55 push ebp
> >>>>>>> [00001203](02) 8bec mov ebp,esp
> >>>>>>> [00001205](03) 8b4508 mov eax,[ebp+08]
> >>>>>>> [00001208](01) 50 push eax
> >>>>>>> [00001209](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>> [0000120c](01) 51 push ecx
> >>>>>>> [0000120d](05) e820feffff call 00001032
> >>>>>>> [00001212](03) 83c408 add esp,+08
> >>>>>>> [00001215](02) 85c0 test eax,eax
> >>>>>>> [00001217](02) 7402 jz 0000121b
> >>>>>>> [00001219](02) ebfe jmp 00001219
> >>>>>>> [0000121b](01) 5d pop ebp
> >>>>>>> [0000121c](01) c3 ret
> >>>>>>> Size in bytes:(0027) [0000121c]
> >>>>>>>
> >>>>>>> _main()
> >>>>>>> [00001222](01) 55 push ebp
> >>>>>>> [00001223](02) 8bec mov ebp,esp
> >>>>>>> [00001225](05) 6802120000 push 00001202
> >>>>>>> [0000122a](05) 6802120000 push 00001202
> >>>>>>> [0000122f](05) e8fefdffff call 00001032
> >>>>>>> [00001234](03) 83c408 add esp,+08
> >>>>>>> [00001237](01) 50 push eax
> >>>>>>> [00001238](05) 68b3030000 push 000003b3
> >>>>>>> [0000123d](05) e8c0f1ffff call 00000402
> >>>>>>> [00001242](03) 83c408 add esp,+08
> >>>>>>> [00001245](02) 33c0 xor eax,eax
> >>>>>>> [00001247](01) 5d pop ebp
> >>>>>>> [00001248](01) c3 ret
> >>>>>>> Size in bytes:(0039) [00001248]
> >>>>>>>
> >>>>>>> machine stack stack machine assembly
> >>>>>>> address address data code language
> >>>>>>> ======== ======== ======== ========= =============
> >>>>>>> [00001222][0010200f][00000000] 55 push ebp
> >>>>>>> [00001223][0010200f][00000000] 8bec mov ebp,esp
> >>>>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 //
> >>>>>>> push P [0000122a][00102007][00001202] 6802120000 push
> >>>>>>> 00001202 // push P [0000122f][00102003][00001234] e8fefdffff
> >>>>>>> call 00001032 // call executed H
> >>>>>>>
> >>>>>>> Begin Simulation Execution Trace Stored at:2120c3
> >>>>>>> Address_of_H:1032
> >>>>>>> [00001202][002120af][002120b3] 55 push ebp
> >>>>>>> [00001203][002120af][002120b3] 8bec mov ebp,esp
> >>>>>>> [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
> >>>>>>> [00001208][002120ab][00001202] 50 push eax //
> >>>>>>> push P [00001209][002120ab][00001202] 8b4d08 mov
> >>>>>>> ecx,[ebp+08] [0000120c][002120a7][00001202] 51 push
> >>>>>>> ecx // push P [0000120d][002120a3][00001212] e820feffff
> >>>>>>> call 00001032 // call emulated H Infinitely Recursive
> >>>>>>> Simulation Detected Simulation Stopped
> >>>>>>>
> >>>>>>> H knows its own machine address and on this basis it can
> >>>>>>> easily examine its stored execution_trace of P (see above) to
> >>>>>>> determine: (a) P is calling H with the same arguments that H
> >>>>>>> was called with. (b) No instructions in P could possibly
> >>>>>>> escape this otherwise infinitely recursive emulation.
> >>>>>>> (c) H aborts its emulation of P before its call to H is
> >>>>>>> emulated.
> >>>>>>
> >>>>>> When you know that H simply implements the above algorithm
> >>>>>> there is no need to see its source code. I am reserving the
> >>>>>> publication of the 5 pages of the source code of the halt
> >>>>>> decider for journal publication.
> >>>>>
> >>>>> Your H is not a pure function as it behaves differently
> >>>>> depending on what is invoking it (it returns a decision answer
> >>>>> to main() but not to P()) and it has side effects (aborting a
> >>>>> simulation).
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> Finally a critique that has a reasonable basis.
> >>>>
> >>>> When I transformed H into a pure function of its inputs it always
> >>>> has the same behavior no matter how it is invoked.
> >>>>
> >>>> The x86 emulation of P is aborted before P invokes H.
> >>>
> >>> Nope. Preventing a call to H is equivalent to H behaving
> >>> differently for same inputs. Aborting a simulation is a side
> >>> effect: pure functions do not have side effects.
> >>>
> >>> /Flibble
> >>>
> >>
> >> In other words you are saying that a halt decider is simply not
> >> allowed to report when it correctly detects that it is being called
> >> in infinitely recursive simulation.
> >
> > I keep telling you this: the infinite recursion is NOT present when
> > using a valid halt decider: your H is NOT a valid halt
> > decider.
> >
> > Simulation is an erroneous approach as a simulating halt decider
> > can not answer in finite time for a non-halting input as there is no
> > proven general solution for detecting non-halting behaviour.
> >
> > /Flibble
> >
>
> IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY
> YOU DENY THIS VERIFIABLE FACT:
>
> The correct and complete x86 emulation of its input by H(P,P)
> would never reach the "ret" instruction of P because both H and
> P would remain stuck in infinitely nested emulation.
For [Strachey 1965] (and the proofs based on it) H is NOT a simulating
halt decider so there is no infinite recursion as there is no emulation.
Valid halt deciders ANALYSE P, they do not EMULATE P.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-25 11:32 -0500 |
| Message-ID | <S8udnWfpo60QpSr_nZ2dnUU7_8xh4p2d@giganews.com> |
| In reply to | #52952 |
On 6/25/2022 11:25 AM, Mr Flibble wrote:
> On Sat, 25 Jun 2022 11:06:12 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 10:59 AM, Mr Flibble wrote:
>>> On Sat, 25 Jun 2022 10:54:13 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/25/2022 10:21 AM, Mr Flibble wrote:
>>>>> On Sat, 25 Jun 2022 10:19:02 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/25/2022 10:09 AM, Mr Flibble wrote:
>>>>>>> On Sat, 25 Jun 2022 10:03:17 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 6/25/2022 9:28 AM, olcott wrote:
>>>>>>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
>>>>>>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>>>>>>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>>>>>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>>>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "Dry run" means that a human programmer looks at the
>>>>>>>>>>>>>>>> code, and determines
>>>>>>>>>>>>>>>> what it does, without actually executing it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't
>>>>>>>>>>>>>>> halt. He's invoked H
>>>>>>>>>>>>>>> | on it and H reports that it doesn't halt. He's run
>>>>>>>>>>>>>>> P(P) and it halts.
>>>>>>>>>>>>>>> The obvious conclusion is that PO's dry run (if he has
>>>>>>>>>>>>>>> indeed done such
>>>>>>>>>>>>>>> a thing) is incorrect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Exactly.
>>>>>>>>>>>>>> We do our little energy budget on tigers, and find that
>>>>>>>>>>>>>> tigers spend more energy
>>>>>>>>>>>>>> than they take in. Well potentially this is dynamite. One
>>>>>>>>>>>>>> explanation is that the
>>>>>>>>>>>>>> law of conservation of energy is wrong.
>>>>>>>>>>>>>> Except, before we countenance that explanation, we need
>>>>>>>>>>>>>> to rule out a much
>>>>>>>>>>>>>> simpler explanation. Which is that our measurements are
>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should
>>>>>>>>>>>>>> be doing, by dry-running
>>>>>>>>>>>>>> it, and then actually run P(P) and obtained a different
>>>>>>>>>>>>>> result. He also found that H
>>>>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
>>>>>>>>>>>>>> conclusion, but it is extensive
>>>>>>>>>>>>>> and far-reaching in its implications. The behaviour of
>>>>>>>>>>>>>> code when run is different
>>>>>>>>>>>>>> from the correct behaviour of the code when simulated. If
>>>>>>>>>>>>>> that's true, then it has
>>>>>>>>>>>>>> similar implications for computer science that disproving
>>>>>>>>>>>>>> the conservation law
>>>>>>>>>>>>>> has for physics.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But the obvious explanation is that the dry-run was
>>>>>>>>>>>>>> incorrect. Lots of people have
>>>>>>>>>>>>>> suggested why it is incorrect. But they can't actually
>>>>>>>>>>>>>> see the code. PO needs to
>>>>>>>>>>>>>> understand that no-one will accept the complicated,
>>>>>>>>>>>>>> far-reaching explanation,
>>>>>>>>>>>>>> until the simple explanation has been ruled out.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I already proved that the dry run is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>> Someone reports that tigers use more energy than they take
>>>>>>>>>>>> in, and concludes that
>>>>>>>>>>>> the energy conservation law is incorrect.
>>>>>>>>>>>> Naturally, everyone is going to say "There must be some
>>>>>>>>>>>> mistake. How were your
>>>>>>>>>>>> measurements taken? Show us your calculations, maybe you've
>>>>>>>>>>>> got your sums wrong."
>>>>>>>>>>>>
>>>>>>>>>>>> Now if they are also uncooperative about sharing the
>>>>>>>>>>>> details of the investigation,
>>>>>>>>>>>> those reservations will be magnified. There can be
>>>>>>>>>>>> legitimate reasons. Tigers are
>>>>>>>>>>>> rare and need to be conserved, you can't let anyone who
>>>>>>>>>>>> wants have access to the
>>>>>>>>>>>> tigers to try to repeat the measurements. But there's also
>>>>>>>>>>>> a common illegitimate
>>>>>>>>>>>> reason put forwards by people who make extraordinary
>>>>>>>>>>>> claims. If the claims were
>>>>>>>>>>>> unexceptional, such as that tigers have a similar energy
>>>>>>>>>>>> budget to lions, then no-one
>>>>>>>>>>>> would be saying "Show me your notebooks. How do you know
>>>>>>>>>>>> that calorimeter was
>>>>>>>>>>>> calibrated accurately? What's the name of the person who
>>>>>>>>>>>> took that measurement
>>>>>>>>>>>> and can I interview them?" Extraordinary claims are put
>>>>>>>>>>>> through the wringer in a way
>>>>>>>>>>>> that ordinary ones are not. I've seen complaints about this
>>>>>>>>>>>> from parapsychologists.
>>>>>>>>>>>> But if you're going to claim to have discovered a new
>>>>>>>>>>>> physical principle, you need
>>>>>>>>>>>> to present rock solid evidence.
>>>>>>>>>>>>
>>>>>>>>>>>> In this case, we can't see H. We can only suggest
>>>>>>>>>>>> explanations for its behaviour.
>>>>>>>>>>> It seems that you simply lack the technical competence.
>>>>>>>>>>> Go back and look at my proof again.
>>>>>>>>>>>
>>>>>>>>>> Sorry no. I've been programming since I was a boy and I have
>>>>>>>>>> a PhD in a computational-
>>>>>>>>>> related subject. I'm confident of my technical abilities.
>>>>>>>>>> What I can't do of course
>>>>>>>>>> is tell you exactly what is going on in code I cannot see.
>>>>>>>>>> I've got a pretty good idea,
>>>>>>>>>> but I can only reconstruct on the basis of what you tell me.
>>>>>>>>>> Ben thinks that I've
>>>>>>>>>> got it wrong and in fact there are no nested emulations at
>>>>>>>>>> all. I've no way of actually
>>>>>>>>>> disproving that idea without seeing H.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> To fully understand this a software engineer must be an expert
>>>>>>>>> in: (a) The C programming language,
>>>>>>>>> (b) The x86 programming language,
>>>>>>>>> (c) Exactly how C translates into x86 and,
>>>>>>>>> (d) The ability to recognize infinite recursion at the x86
>>>>>>>>> assembly language level.
>>>>>>>>>
>>>>>>>>> Anyone having the above credentials can validate my work, if
>>>>>>>>> you cannot validate my work then you do not sufficiently have
>>>>>>>>> the above credentials.
>>>>>>>>>
>>>>>>>>> Exactly how C translates into x86 is mandatory. If you don't
>>>>>>>>> know how the C calling conventions are implemented in x86 you
>>>>>>>>> cannot validate my work.
>>>>>>>>>
>>>>>>>>> From a purely software engineering perspective H(P,P) is
>>>>>>>>> required to to correctly determine that its correct and
>>>>>>>>> complete x86 emulation of its input would never reach the
>>>>>>>>> "ret" instruction of this input and H must do this in a
>>>>>>>>> finite number of steps.
>>>>>>>>>
>>>>>>>>> The ordinary semantics of standard C and the conventional x86
>>>>>>>>> language are the entire semantics required to conclusively
>>>>>>>>> prove that H(P,P) does correctly determine that its correct
>>>>>>>>> and complete x86 emulation of its input would never reach the
>>>>>>>>> "ret" instruction (final state) of this input thus never
>>>>>>>>> halts.
>>>>>>>>>
>>>>>>>>> The correct and complete x86 emulation of its input by H(P,P)
>>>>>>>>> would never reach the "ret" instruction of P because both H
>>>>>>>>> and P would remain stuck in infinitely nested emulation.
>>>>>>>>>
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>> if (H(x, x))
>>>>>>>>> HERE: goto HERE;
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _P()
>>>>>>>>> [00001202](01) 55 push ebp
>>>>>>>>> [00001203](02) 8bec mov ebp,esp
>>>>>>>>> [00001205](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>> [00001208](01) 50 push eax
>>>>>>>>> [00001209](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>> [0000120c](01) 51 push ecx
>>>>>>>>> [0000120d](05) e820feffff call 00001032
>>>>>>>>> [00001212](03) 83c408 add esp,+08
>>>>>>>>> [00001215](02) 85c0 test eax,eax
>>>>>>>>> [00001217](02) 7402 jz 0000121b
>>>>>>>>> [00001219](02) ebfe jmp 00001219
>>>>>>>>> [0000121b](01) 5d pop ebp
>>>>>>>>> [0000121c](01) c3 ret
>>>>>>>>> Size in bytes:(0027) [0000121c]
>>>>>>>>>
>>>>>>>>> _main()
>>>>>>>>> [00001222](01) 55 push ebp
>>>>>>>>> [00001223](02) 8bec mov ebp,esp
>>>>>>>>> [00001225](05) 6802120000 push 00001202
>>>>>>>>> [0000122a](05) 6802120000 push 00001202
>>>>>>>>> [0000122f](05) e8fefdffff call 00001032
>>>>>>>>> [00001234](03) 83c408 add esp,+08
>>>>>>>>> [00001237](01) 50 push eax
>>>>>>>>> [00001238](05) 68b3030000 push 000003b3
>>>>>>>>> [0000123d](05) e8c0f1ffff call 00000402
>>>>>>>>> [00001242](03) 83c408 add esp,+08
>>>>>>>>> [00001245](02) 33c0 xor eax,eax
>>>>>>>>> [00001247](01) 5d pop ebp
>>>>>>>>> [00001248](01) c3 ret
>>>>>>>>> Size in bytes:(0039) [00001248]
>>>>>>>>>
>>>>>>>>> machine stack stack machine assembly
>>>>>>>>> address address data code language
>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>> [00001222][0010200f][00000000] 55 push ebp
>>>>>>>>> [00001223][0010200f][00000000] 8bec mov ebp,esp
>>>>>>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 //
>>>>>>>>> push P [0000122a][00102007][00001202] 6802120000 push
>>>>>>>>> 00001202 // push P [0000122f][00102003][00001234] e8fefdffff
>>>>>>>>> call 00001032 // call executed H
>>>>>>>>>
>>>>>>>>> Begin Simulation Execution Trace Stored at:2120c3
>>>>>>>>> Address_of_H:1032
>>>>>>>>> [00001202][002120af][002120b3] 55 push ebp
>>>>>>>>> [00001203][002120af][002120b3] 8bec mov ebp,esp
>>>>>>>>> [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
>>>>>>>>> [00001208][002120ab][00001202] 50 push eax //
>>>>>>>>> push P [00001209][002120ab][00001202] 8b4d08 mov
>>>>>>>>> ecx,[ebp+08] [0000120c][002120a7][00001202] 51 push
>>>>>>>>> ecx // push P [0000120d][002120a3][00001212] e820feffff
>>>>>>>>> call 00001032 // call emulated H Infinitely Recursive
>>>>>>>>> Simulation Detected Simulation Stopped
>>>>>>>>>
>>>>>>>>> H knows its own machine address and on this basis it can
>>>>>>>>> easily examine its stored execution_trace of P (see above) to
>>>>>>>>> determine: (a) P is calling H with the same arguments that H
>>>>>>>>> was called with. (b) No instructions in P could possibly
>>>>>>>>> escape this otherwise infinitely recursive emulation.
>>>>>>>>> (c) H aborts its emulation of P before its call to H is
>>>>>>>>> emulated.
>>>>>>>>
>>>>>>>> When you know that H simply implements the above algorithm
>>>>>>>> there is no need to see its source code. I am reserving the
>>>>>>>> publication of the 5 pages of the source code of the halt
>>>>>>>> decider for journal publication.
>>>>>>>
>>>>>>> Your H is not a pure function as it behaves differently
>>>>>>> depending on what is invoking it (it returns a decision answer
>>>>>>> to main() but not to P()) and it has side effects (aborting a
>>>>>>> simulation).
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Finally a critique that has a reasonable basis.
>>>>>>
>>>>>> When I transformed H into a pure function of its inputs it always
>>>>>> has the same behavior no matter how it is invoked.
>>>>>>
>>>>>> The x86 emulation of P is aborted before P invokes H.
>>>>>
>>>>> Nope. Preventing a call to H is equivalent to H behaving
>>>>> differently for same inputs. Aborting a simulation is a side
>>>>> effect: pure functions do not have side effects.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> In other words you are saying that a halt decider is simply not
>>>> allowed to report when it correctly detects that it is being called
>>>> in infinitely recursive simulation.
>>>
>>> I keep telling you this: the infinite recursion is NOT present when
>>> using a valid halt decider: your H is NOT a valid halt
>>> decider.
>>>
>>> Simulation is an erroneous approach as a simulating halt decider
>>> can not answer in finite time for a non-halting input as there is no
>>> proven general solution for detecting non-halting behaviour.
>>>
>>> /Flibble
>>>
>>
>> IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY
>> YOU DENY THIS VERIFIABLE FACT:
>>
>> The correct and complete x86 emulation of its input by H(P,P)
>> would never reach the "ret" instruction of P because both H and
>> P would remain stuck in infinitely nested emulation.
>
> For [Strachey 1965] (and the proofs based on it) H is NOT a simulating
> halt decider so there is no infinite recursion as there is no emulation.
>
> Valid halt deciders ANALYSE P, they do not EMULATE P.
>
> /Flibble
>
I provide a halt decider H that gets the right answer and your rebuttal
is that H does not get the right answer because there is another
different halt decider named H1 that gets the wrong answer.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-25 20:12 +0100 |
| Message-ID | <20220625201230.00000c34@reddwarf.jmc> |
| In reply to | #52955 |
On Sat, 25 Jun 2022 11:32:12 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 6/25/2022 11:25 AM, Mr Flibble wrote:
> > On Sat, 25 Jun 2022 11:06:12 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/25/2022 10:59 AM, Mr Flibble wrote:
> >>> On Sat, 25 Jun 2022 10:54:13 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/25/2022 10:21 AM, Mr Flibble wrote:
> >>>>> On Sat, 25 Jun 2022 10:19:02 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 6/25/2022 10:09 AM, Mr Flibble wrote:
> >>>>>>> On Sat, 25 Jun 2022 10:03:17 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 6/25/2022 9:28 AM, olcott wrote:
> >>>>>>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
> >>>>>>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
> >>>>>>>>>>
> >>>>>>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
> >>>>>>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
> >>>>>>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben
> >>>>>>>>>>>>>> Bacarisse wrote:
> >>>>>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> "Dry run" means that a human programmer looks at the
> >>>>>>>>>>>>>>>> code, and determines
> >>>>>>>>>>>>>>>> what it does, without actually executing it.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Going back, now, to what you think needs to be
> >>>>>>>>>>>>>>> resolved: | He's dry-run P(P) and established that it
> >>>>>>>>>>>>>>> doesn't halt. He's invoked H
> >>>>>>>>>>>>>>> | on it and H reports that it doesn't halt. He's run
> >>>>>>>>>>>>>>> P(P) and it halts.
> >>>>>>>>>>>>>>> The obvious conclusion is that PO's dry run (if he has
> >>>>>>>>>>>>>>> indeed done such
> >>>>>>>>>>>>>>> a thing) is incorrect.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Exactly.
> >>>>>>>>>>>>>> We do our little energy budget on tigers, and find that
> >>>>>>>>>>>>>> tigers spend more energy
> >>>>>>>>>>>>>> than they take in. Well potentially this is dynamite.
> >>>>>>>>>>>>>> One explanation is that the
> >>>>>>>>>>>>>> law of conservation of energy is wrong.
> >>>>>>>>>>>>>> Except, before we countenance that explanation, we need
> >>>>>>>>>>>>>> to rule out a much
> >>>>>>>>>>>>>> simpler explanation. Which is that our measurements are
> >>>>>>>>>>>>>> wrong.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should
> >>>>>>>>>>>>>> be doing, by dry-running
> >>>>>>>>>>>>>> it, and then actually run P(P) and obtained a different
> >>>>>>>>>>>>>> result. He also found that H
> >>>>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
> >>>>>>>>>>>>>> conclusion, but it is extensive
> >>>>>>>>>>>>>> and far-reaching in its implications. The behaviour of
> >>>>>>>>>>>>>> code when run is different
> >>>>>>>>>>>>>> from the correct behaviour of the code when simulated.
> >>>>>>>>>>>>>> If that's true, then it has
> >>>>>>>>>>>>>> similar implications for computer science that
> >>>>>>>>>>>>>> disproving the conservation law
> >>>>>>>>>>>>>> has for physics.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> But the obvious explanation is that the dry-run was
> >>>>>>>>>>>>>> incorrect. Lots of people have
> >>>>>>>>>>>>>> suggested why it is incorrect. But they can't actually
> >>>>>>>>>>>>>> see the code. PO needs to
> >>>>>>>>>>>>>> understand that no-one will accept the complicated,
> >>>>>>>>>>>>>> far-reaching explanation,
> >>>>>>>>>>>>>> until the simple explanation has been ruled out.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I already proved that the dry run is correct.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Someone reports that tigers use more energy than they
> >>>>>>>>>>>> take in, and concludes that
> >>>>>>>>>>>> the energy conservation law is incorrect.
> >>>>>>>>>>>> Naturally, everyone is going to say "There must be some
> >>>>>>>>>>>> mistake. How were your
> >>>>>>>>>>>> measurements taken? Show us your calculations, maybe
> >>>>>>>>>>>> you've got your sums wrong."
> >>>>>>>>>>>>
> >>>>>>>>>>>> Now if they are also uncooperative about sharing the
> >>>>>>>>>>>> details of the investigation,
> >>>>>>>>>>>> those reservations will be magnified. There can be
> >>>>>>>>>>>> legitimate reasons. Tigers are
> >>>>>>>>>>>> rare and need to be conserved, you can't let anyone who
> >>>>>>>>>>>> wants have access to the
> >>>>>>>>>>>> tigers to try to repeat the measurements. But there's
> >>>>>>>>>>>> also a common illegitimate
> >>>>>>>>>>>> reason put forwards by people who make extraordinary
> >>>>>>>>>>>> claims. If the claims were
> >>>>>>>>>>>> unexceptional, such as that tigers have a similar energy
> >>>>>>>>>>>> budget to lions, then no-one
> >>>>>>>>>>>> would be saying "Show me your notebooks. How do you know
> >>>>>>>>>>>> that calorimeter was
> >>>>>>>>>>>> calibrated accurately? What's the name of the person who
> >>>>>>>>>>>> took that measurement
> >>>>>>>>>>>> and can I interview them?" Extraordinary claims are put
> >>>>>>>>>>>> through the wringer in a way
> >>>>>>>>>>>> that ordinary ones are not. I've seen complaints about
> >>>>>>>>>>>> this from parapsychologists.
> >>>>>>>>>>>> But if you're going to claim to have discovered a new
> >>>>>>>>>>>> physical principle, you need
> >>>>>>>>>>>> to present rock solid evidence.
> >>>>>>>>>>>>
> >>>>>>>>>>>> In this case, we can't see H. We can only suggest
> >>>>>>>>>>>> explanations for its behaviour.
> >>>>>>>>>>> It seems that you simply lack the technical competence.
> >>>>>>>>>>> Go back and look at my proof again.
> >>>>>>>>>>>
> >>>>>>>>>> Sorry no. I've been programming since I was a boy and I
> >>>>>>>>>> have a PhD in a computational-
> >>>>>>>>>> related subject. I'm confident of my technical abilities.
> >>>>>>>>>> What I can't do of course
> >>>>>>>>>> is tell you exactly what is going on in code I cannot see.
> >>>>>>>>>> I've got a pretty good idea,
> >>>>>>>>>> but I can only reconstruct on the basis of what you tell
> >>>>>>>>>> me. Ben thinks that I've
> >>>>>>>>>> got it wrong and in fact there are no nested emulations at
> >>>>>>>>>> all. I've no way of actually
> >>>>>>>>>> disproving that idea without seeing H.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> To fully understand this a software engineer must be an
> >>>>>>>>> expert in: (a) The C programming language,
> >>>>>>>>> (b) The x86 programming language,
> >>>>>>>>> (c) Exactly how C translates into x86 and,
> >>>>>>>>> (d) The ability to recognize infinite recursion at the x86
> >>>>>>>>> assembly language level.
> >>>>>>>>>
> >>>>>>>>> Anyone having the above credentials can validate my work, if
> >>>>>>>>> you cannot validate my work then you do not sufficiently
> >>>>>>>>> have the above credentials.
> >>>>>>>>>
> >>>>>>>>> Exactly how C translates into x86 is mandatory. If you don't
> >>>>>>>>> know how the C calling conventions are implemented in x86
> >>>>>>>>> you cannot validate my work.
> >>>>>>>>>
> >>>>>>>>> From a purely software engineering perspective H(P,P)
> >>>>>>>>> is required to to correctly determine that its correct and
> >>>>>>>>> complete x86 emulation of its input would never reach the
> >>>>>>>>> "ret" instruction of this input and H must do this in a
> >>>>>>>>> finite number of steps.
> >>>>>>>>>
> >>>>>>>>> The ordinary semantics of standard C and the conventional
> >>>>>>>>> x86 language are the entire semantics required to
> >>>>>>>>> conclusively prove that H(P,P) does correctly determine
> >>>>>>>>> that its correct and complete x86 emulation of its input
> >>>>>>>>> would never reach the "ret" instruction (final state) of
> >>>>>>>>> this input thus never halts.
> >>>>>>>>>
> >>>>>>>>> The correct and complete x86 emulation of its input by
> >>>>>>>>> H(P,P) would never reach the "ret" instruction of P because
> >>>>>>>>> both H and P would remain stuck in infinitely nested
> >>>>>>>>> emulation.
> >>>>>>>>>
> >>>>>>>>> void P(u32 x)
> >>>>>>>>> {
> >>>>>>>>> if (H(x, x))
> >>>>>>>>> HERE: goto HERE;
> >>>>>>>>> return;
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> int main()
> >>>>>>>>> {
> >>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> _P()
> >>>>>>>>> [00001202](01) 55 push ebp
> >>>>>>>>> [00001203](02) 8bec mov ebp,esp
> >>>>>>>>> [00001205](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>> [00001208](01) 50 push eax
> >>>>>>>>> [00001209](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>> [0000120c](01) 51 push ecx
> >>>>>>>>> [0000120d](05) e820feffff call 00001032
> >>>>>>>>> [00001212](03) 83c408 add esp,+08
> >>>>>>>>> [00001215](02) 85c0 test eax,eax
> >>>>>>>>> [00001217](02) 7402 jz 0000121b
> >>>>>>>>> [00001219](02) ebfe jmp 00001219
> >>>>>>>>> [0000121b](01) 5d pop ebp
> >>>>>>>>> [0000121c](01) c3 ret
> >>>>>>>>> Size in bytes:(0027) [0000121c]
> >>>>>>>>>
> >>>>>>>>> _main()
> >>>>>>>>> [00001222](01) 55 push ebp
> >>>>>>>>> [00001223](02) 8bec mov ebp,esp
> >>>>>>>>> [00001225](05) 6802120000 push 00001202
> >>>>>>>>> [0000122a](05) 6802120000 push 00001202
> >>>>>>>>> [0000122f](05) e8fefdffff call 00001032
> >>>>>>>>> [00001234](03) 83c408 add esp,+08
> >>>>>>>>> [00001237](01) 50 push eax
> >>>>>>>>> [00001238](05) 68b3030000 push 000003b3
> >>>>>>>>> [0000123d](05) e8c0f1ffff call 00000402
> >>>>>>>>> [00001242](03) 83c408 add esp,+08
> >>>>>>>>> [00001245](02) 33c0 xor eax,eax
> >>>>>>>>> [00001247](01) 5d pop ebp
> >>>>>>>>> [00001248](01) c3 ret
> >>>>>>>>> Size in bytes:(0039) [00001248]
> >>>>>>>>>
> >>>>>>>>> machine stack stack machine assembly
> >>>>>>>>> address address data code language
> >>>>>>>>> ======== ======== ======== ========= =============
> >>>>>>>>> [00001222][0010200f][00000000] 55 push ebp
> >>>>>>>>> [00001223][0010200f][00000000] 8bec mov ebp,esp
> >>>>>>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 //
> >>>>>>>>> push P [0000122a][00102007][00001202] 6802120000 push
> >>>>>>>>> 00001202 // push P [0000122f][00102003][00001234] e8fefdffff
> >>>>>>>>> call 00001032 // call executed H
> >>>>>>>>>
> >>>>>>>>> Begin Simulation Execution Trace Stored at:2120c3
> >>>>>>>>> Address_of_H:1032
> >>>>>>>>> [00001202][002120af][002120b3] 55 push ebp
> >>>>>>>>> [00001203][002120af][002120b3] 8bec mov ebp,esp
> >>>>>>>>> [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
> >>>>>>>>> [00001208][002120ab][00001202] 50 push eax //
> >>>>>>>>> push P [00001209][002120ab][00001202] 8b4d08 mov
> >>>>>>>>> ecx,[ebp+08] [0000120c][002120a7][00001202] 51 push
> >>>>>>>>> ecx // push P [0000120d][002120a3][00001212] e820feffff
> >>>>>>>>> call 00001032 // call emulated H Infinitely Recursive
> >>>>>>>>> Simulation Detected Simulation Stopped
> >>>>>>>>>
> >>>>>>>>> H knows its own machine address and on this basis it can
> >>>>>>>>> easily examine its stored execution_trace of P (see above)
> >>>>>>>>> to determine: (a) P is calling H with the same arguments
> >>>>>>>>> that H was called with. (b) No instructions in P could
> >>>>>>>>> possibly escape this otherwise infinitely recursive
> >>>>>>>>> emulation. (c) H aborts its emulation of P before its call
> >>>>>>>>> to H is emulated.
> >>>>>>>>
> >>>>>>>> When you know that H simply implements the above algorithm
> >>>>>>>> there is no need to see its source code. I am reserving the
> >>>>>>>> publication of the 5 pages of the source code of the halt
> >>>>>>>> decider for journal publication.
> >>>>>>>
> >>>>>>> Your H is not a pure function as it behaves differently
> >>>>>>> depending on what is invoking it (it returns a decision answer
> >>>>>>> to main() but not to P()) and it has side effects (aborting a
> >>>>>>> simulation).
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> Finally a critique that has a reasonable basis.
> >>>>>>
> >>>>>> When I transformed H into a pure function of its inputs it
> >>>>>> always has the same behavior no matter how it is invoked.
> >>>>>>
> >>>>>> The x86 emulation of P is aborted before P invokes H.
> >>>>>
> >>>>> Nope. Preventing a call to H is equivalent to H behaving
> >>>>> differently for same inputs. Aborting a simulation is a side
> >>>>> effect: pure functions do not have side effects.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> In other words you are saying that a halt decider is simply not
> >>>> allowed to report when it correctly detects that it is being
> >>>> called in infinitely recursive simulation.
> >>>
> >>> I keep telling you this: the infinite recursion is NOT present
> >>> when using a valid halt decider: your H is NOT a valid halt
> >>> decider.
> >>>
> >>> Simulation is an erroneous approach as a simulating halt decider
> >>> can not answer in finite time for a non-halting input as there is
> >>> no proven general solution for detecting non-halting behaviour.
> >>>
> >>> /Flibble
> >>>
> >>
> >> IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY
> >> YOU DENY THIS VERIFIABLE FACT:
> >>
> >> The correct and complete x86 emulation of its input by H(P,P)
> >> would never reach the "ret" instruction of P because both H and
> >> P would remain stuck in infinitely nested emulation.
> >
> > For [Strachey 1965] (and the proofs based on it) H is NOT a
> > simulating halt decider so there is no infinite recursion as there
> > is no emulation.
> >
> > Valid halt deciders ANALYSE P, they do not EMULATE P.
> >
> > /Flibble
> >
>
> I provide a halt decider H that gets the right answer and your
> rebuttal is that H does not get the right answer because there is
> another different halt decider named H1 that gets the wrong answer.
Your H also gets the wrong answer:
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-25 14:20 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] |
| Message-ID | <VNOdnS2kSbh1wir_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52965 |
On 6/25/2022 2:12 PM, Mr Flibble wrote:
> On Sat, 25 Jun 2022 11:32:12 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 11:25 AM, Mr Flibble wrote:
>>> On Sat, 25 Jun 2022 11:06:12 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/25/2022 10:59 AM, Mr Flibble wrote:
>>>>> On Sat, 25 Jun 2022 10:54:13 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/25/2022 10:21 AM, Mr Flibble wrote:
>>>>>>> On Sat, 25 Jun 2022 10:19:02 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 6/25/2022 10:09 AM, Mr Flibble wrote:
>>>>>>>>> On Sat, 25 Jun 2022 10:03:17 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 6/25/2022 9:28 AM, olcott wrote:
>>>>>>>>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
>>>>>>>>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>>>>>>>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>>>>>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben
>>>>>>>>>>>>>>>> Bacarisse wrote:
>>>>>>>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> "Dry run" means that a human programmer looks at the
>>>>>>>>>>>>>>>>>> code, and determines
>>>>>>>>>>>>>>>>>> what it does, without actually executing it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Going back, now, to what you think needs to be
>>>>>>>>>>>>>>>>> resolved: | He's dry-run P(P) and established that it
>>>>>>>>>>>>>>>>> doesn't halt. He's invoked H
>>>>>>>>>>>>>>>>> | on it and H reports that it doesn't halt. He's run
>>>>>>>>>>>>>>>>> P(P) and it halts.
>>>>>>>>>>>>>>>>> The obvious conclusion is that PO's dry run (if he has
>>>>>>>>>>>>>>>>> indeed done such
>>>>>>>>>>>>>>>>> a thing) is incorrect.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Exactly.
>>>>>>>>>>>>>>>> We do our little energy budget on tigers, and find that
>>>>>>>>>>>>>>>> tigers spend more energy
>>>>>>>>>>>>>>>> than they take in. Well potentially this is dynamite.
>>>>>>>>>>>>>>>> One explanation is that the
>>>>>>>>>>>>>>>> law of conservation of energy is wrong.
>>>>>>>>>>>>>>>> Except, before we countenance that explanation, we need
>>>>>>>>>>>>>>>> to rule out a much
>>>>>>>>>>>>>>>> simpler explanation. Which is that our measurements are
>>>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should
>>>>>>>>>>>>>>>> be doing, by dry-running
>>>>>>>>>>>>>>>> it, and then actually run P(P) and obtained a different
>>>>>>>>>>>>>>>> result. He also found that H
>>>>>>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
>>>>>>>>>>>>>>>> conclusion, but it is extensive
>>>>>>>>>>>>>>>> and far-reaching in its implications. The behaviour of
>>>>>>>>>>>>>>>> code when run is different
>>>>>>>>>>>>>>>> from the correct behaviour of the code when simulated.
>>>>>>>>>>>>>>>> If that's true, then it has
>>>>>>>>>>>>>>>> similar implications for computer science that
>>>>>>>>>>>>>>>> disproving the conservation law
>>>>>>>>>>>>>>>> has for physics.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But the obvious explanation is that the dry-run was
>>>>>>>>>>>>>>>> incorrect. Lots of people have
>>>>>>>>>>>>>>>> suggested why it is incorrect. But they can't actually
>>>>>>>>>>>>>>>> see the code. PO needs to
>>>>>>>>>>>>>>>> understand that no-one will accept the complicated,
>>>>>>>>>>>>>>>> far-reaching explanation,
>>>>>>>>>>>>>>>> until the simple explanation has been ruled out.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I already proved that the dry run is correct.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Someone reports that tigers use more energy than they
>>>>>>>>>>>>>> take in, and concludes that
>>>>>>>>>>>>>> the energy conservation law is incorrect.
>>>>>>>>>>>>>> Naturally, everyone is going to say "There must be some
>>>>>>>>>>>>>> mistake. How were your
>>>>>>>>>>>>>> measurements taken? Show us your calculations, maybe
>>>>>>>>>>>>>> you've got your sums wrong."
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now if they are also uncooperative about sharing the
>>>>>>>>>>>>>> details of the investigation,
>>>>>>>>>>>>>> those reservations will be magnified. There can be
>>>>>>>>>>>>>> legitimate reasons. Tigers are
>>>>>>>>>>>>>> rare and need to be conserved, you can't let anyone who
>>>>>>>>>>>>>> wants have access to the
>>>>>>>>>>>>>> tigers to try to repeat the measurements. But there's
>>>>>>>>>>>>>> also a common illegitimate
>>>>>>>>>>>>>> reason put forwards by people who make extraordinary
>>>>>>>>>>>>>> claims. If the claims were
>>>>>>>>>>>>>> unexceptional, such as that tigers have a similar energy
>>>>>>>>>>>>>> budget to lions, then no-one
>>>>>>>>>>>>>> would be saying "Show me your notebooks. How do you know
>>>>>>>>>>>>>> that calorimeter was
>>>>>>>>>>>>>> calibrated accurately? What's the name of the person who
>>>>>>>>>>>>>> took that measurement
>>>>>>>>>>>>>> and can I interview them?" Extraordinary claims are put
>>>>>>>>>>>>>> through the wringer in a way
>>>>>>>>>>>>>> that ordinary ones are not. I've seen complaints about
>>>>>>>>>>>>>> this from parapsychologists.
>>>>>>>>>>>>>> But if you're going to claim to have discovered a new
>>>>>>>>>>>>>> physical principle, you need
>>>>>>>>>>>>>> to present rock solid evidence.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In this case, we can't see H. We can only suggest
>>>>>>>>>>>>>> explanations for its behaviour.
>>>>>>>>>>>>> It seems that you simply lack the technical competence.
>>>>>>>>>>>>> Go back and look at my proof again.
>>>>>>>>>>>>>
>>>>>>>>>>>> Sorry no. I've been programming since I was a boy and I
>>>>>>>>>>>> have a PhD in a computational-
>>>>>>>>>>>> related subject. I'm confident of my technical abilities.
>>>>>>>>>>>> What I can't do of course
>>>>>>>>>>>> is tell you exactly what is going on in code I cannot see.
>>>>>>>>>>>> I've got a pretty good idea,
>>>>>>>>>>>> but I can only reconstruct on the basis of what you tell
>>>>>>>>>>>> me. Ben thinks that I've
>>>>>>>>>>>> got it wrong and in fact there are no nested emulations at
>>>>>>>>>>>> all. I've no way of actually
>>>>>>>>>>>> disproving that idea without seeing H.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> To fully understand this a software engineer must be an
>>>>>>>>>>> expert in: (a) The C programming language,
>>>>>>>>>>> (b) The x86 programming language,
>>>>>>>>>>> (c) Exactly how C translates into x86 and,
>>>>>>>>>>> (d) The ability to recognize infinite recursion at the x86
>>>>>>>>>>> assembly language level.
>>>>>>>>>>>
>>>>>>>>>>> Anyone having the above credentials can validate my work, if
>>>>>>>>>>> you cannot validate my work then you do not sufficiently
>>>>>>>>>>> have the above credentials.
>>>>>>>>>>>
>>>>>>>>>>> Exactly how C translates into x86 is mandatory. If you don't
>>>>>>>>>>> know how the C calling conventions are implemented in x86
>>>>>>>>>>> you cannot validate my work.
>>>>>>>>>>>
>>>>>>>>>>> From a purely software engineering perspective H(P,P)
>>>>>>>>>>> is required to to correctly determine that its correct and
>>>>>>>>>>> complete x86 emulation of its input would never reach the
>>>>>>>>>>> "ret" instruction of this input and H must do this in a
>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>
>>>>>>>>>>> The ordinary semantics of standard C and the conventional
>>>>>>>>>>> x86 language are the entire semantics required to
>>>>>>>>>>> conclusively prove that H(P,P) does correctly determine
>>>>>>>>>>> that its correct and complete x86 emulation of its input
>>>>>>>>>>> would never reach the "ret" instruction (final state) of
>>>>>>>>>>> this input thus never halts.
>>>>>>>>>>>
>>>>>>>>>>> The correct and complete x86 emulation of its input by
>>>>>>>>>>> H(P,P) would never reach the "ret" instruction of P because
>>>>>>>>>>> both H and P would remain stuck in infinitely nested
>>>>>>>>>>> emulation.
>>>>>>>>>>>
>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>> {
>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>> return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> _P()
>>>>>>>>>>> [00001202](01) 55 push ebp
>>>>>>>>>>> [00001203](02) 8bec mov ebp,esp
>>>>>>>>>>> [00001205](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>> [00001208](01) 50 push eax
>>>>>>>>>>> [00001209](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>> [0000120c](01) 51 push ecx
>>>>>>>>>>> [0000120d](05) e820feffff call 00001032
>>>>>>>>>>> [00001212](03) 83c408 add esp,+08
>>>>>>>>>>> [00001215](02) 85c0 test eax,eax
>>>>>>>>>>> [00001217](02) 7402 jz 0000121b
>>>>>>>>>>> [00001219](02) ebfe jmp 00001219
>>>>>>>>>>> [0000121b](01) 5d pop ebp
>>>>>>>>>>> [0000121c](01) c3 ret
>>>>>>>>>>> Size in bytes:(0027) [0000121c]
>>>>>>>>>>>
>>>>>>>>>>> _main()
>>>>>>>>>>> [00001222](01) 55 push ebp
>>>>>>>>>>> [00001223](02) 8bec mov ebp,esp
>>>>>>>>>>> [00001225](05) 6802120000 push 00001202
>>>>>>>>>>> [0000122a](05) 6802120000 push 00001202
>>>>>>>>>>> [0000122f](05) e8fefdffff call 00001032
>>>>>>>>>>> [00001234](03) 83c408 add esp,+08
>>>>>>>>>>> [00001237](01) 50 push eax
>>>>>>>>>>> [00001238](05) 68b3030000 push 000003b3
>>>>>>>>>>> [0000123d](05) e8c0f1ffff call 00000402
>>>>>>>>>>> [00001242](03) 83c408 add esp,+08
>>>>>>>>>>> [00001245](02) 33c0 xor eax,eax
>>>>>>>>>>> [00001247](01) 5d pop ebp
>>>>>>>>>>> [00001248](01) c3 ret
>>>>>>>>>>> Size in bytes:(0039) [00001248]
>>>>>>>>>>>
>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>> address address data code language
>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>> [00001222][0010200f][00000000] 55 push ebp
>>>>>>>>>>> [00001223][0010200f][00000000] 8bec mov ebp,esp
>>>>>>>>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 //
>>>>>>>>>>> push P [0000122a][00102007][00001202] 6802120000 push
>>>>>>>>>>> 00001202 // push P [0000122f][00102003][00001234] e8fefdffff
>>>>>>>>>>> call 00001032 // call executed H
>>>>>>>>>>>
>>>>>>>>>>> Begin Simulation Execution Trace Stored at:2120c3
>>>>>>>>>>> Address_of_H:1032
>>>>>>>>>>> [00001202][002120af][002120b3] 55 push ebp
>>>>>>>>>>> [00001203][002120af][002120b3] 8bec mov ebp,esp
>>>>>>>>>>> [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>> [00001208][002120ab][00001202] 50 push eax //
>>>>>>>>>>> push P [00001209][002120ab][00001202] 8b4d08 mov
>>>>>>>>>>> ecx,[ebp+08] [0000120c][002120a7][00001202] 51 push
>>>>>>>>>>> ecx // push P [0000120d][002120a3][00001212] e820feffff
>>>>>>>>>>> call 00001032 // call emulated H Infinitely Recursive
>>>>>>>>>>> Simulation Detected Simulation Stopped
>>>>>>>>>>>
>>>>>>>>>>> H knows its own machine address and on this basis it can
>>>>>>>>>>> easily examine its stored execution_trace of P (see above)
>>>>>>>>>>> to determine: (a) P is calling H with the same arguments
>>>>>>>>>>> that H was called with. (b) No instructions in P could
>>>>>>>>>>> possibly escape this otherwise infinitely recursive
>>>>>>>>>>> emulation. (c) H aborts its emulation of P before its call
>>>>>>>>>>> to H is emulated.
>>>>>>>>>>
>>>>>>>>>> When you know that H simply implements the above algorithm
>>>>>>>>>> there is no need to see its source code. I am reserving the
>>>>>>>>>> publication of the 5 pages of the source code of the halt
>>>>>>>>>> decider for journal publication.
>>>>>>>>>
>>>>>>>>> Your H is not a pure function as it behaves differently
>>>>>>>>> depending on what is invoking it (it returns a decision answer
>>>>>>>>> to main() but not to P()) and it has side effects (aborting a
>>>>>>>>> simulation).
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> Finally a critique that has a reasonable basis.
>>>>>>>>
>>>>>>>> When I transformed H into a pure function of its inputs it
>>>>>>>> always has the same behavior no matter how it is invoked.
>>>>>>>>
>>>>>>>> The x86 emulation of P is aborted before P invokes H.
>>>>>>>
>>>>>>> Nope. Preventing a call to H is equivalent to H behaving
>>>>>>> differently for same inputs. Aborting a simulation is a side
>>>>>>> effect: pure functions do not have side effects.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> In other words you are saying that a halt decider is simply not
>>>>>> allowed to report when it correctly detects that it is being
>>>>>> called in infinitely recursive simulation.
>>>>>
>>>>> I keep telling you this: the infinite recursion is NOT present
>>>>> when using a valid halt decider: your H is NOT a valid halt
>>>>> decider.
>>>>>
>>>>> Simulation is an erroneous approach as a simulating halt decider
>>>>> can not answer in finite time for a non-halting input as there is
>>>>> no proven general solution for detecting non-halting behaviour.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY
>>>> YOU DENY THIS VERIFIABLE FACT:
>>>>
>>>> The correct and complete x86 emulation of its input by H(P,P)
>>>> would never reach the "ret" instruction of P because both H and
>>>> P would remain stuck in infinitely nested emulation.
>>>
>>> For [Strachey 1965] (and the proofs based on it) H is NOT a
>>> simulating halt decider so there is no infinite recursion as there
>>> is no emulation.
>>>
>>> Valid halt deciders ANALYSE P, they do not EMULATE P.
>>>
>>> /Flibble
>>>
>>
>> I provide a halt decider H that gets the right answer and your
>> rebuttal is that H does not get the right answer because there is
>> another different halt decider named H1 that gets the wrong answer.
>
> Your H also gets the wrong answer:
>
> 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
>
Yet you only have dogma and no supporting reasoning.
The reason that you only have dogma and no supporting reasoning is that
tautologies such as this one have no correct rebuttal in the universe:
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly predict that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.
--
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-25 20:33 +0100 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ tautology ] |
| Message-ID | <20220625203333.00007944@reddwarf.jmc> |
| In reply to | #52969 |
On Sat, 25 Jun 2022 14:20:06 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 6/25/2022 2:12 PM, Mr Flibble wrote:
> > On Sat, 25 Jun 2022 11:32:12 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/25/2022 11:25 AM, Mr Flibble wrote:
> >>> On Sat, 25 Jun 2022 11:06:12 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/25/2022 10:59 AM, Mr Flibble wrote:
> >>>>> On Sat, 25 Jun 2022 10:54:13 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 6/25/2022 10:21 AM, Mr Flibble wrote:
> >>>>>>> On Sat, 25 Jun 2022 10:19:02 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 6/25/2022 10:09 AM, Mr Flibble wrote:
> >>>>>>>>> On Sat, 25 Jun 2022 10:03:17 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 6/25/2022 9:28 AM, olcott wrote:
> >>>>>>>>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
> >>>>>>>>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
> >>>>>>>>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
> >>>>>>>>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben
> >>>>>>>>>>>>>>>> Bacarisse wrote:
> >>>>>>>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> "Dry run" means that a human programmer looks at
> >>>>>>>>>>>>>>>>>> the code, and determines
> >>>>>>>>>>>>>>>>>> what it does, without actually executing it.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Going back, now, to what you think needs to be
> >>>>>>>>>>>>>>>>> resolved: | He's dry-run P(P) and established that
> >>>>>>>>>>>>>>>>> it doesn't halt. He's invoked H
> >>>>>>>>>>>>>>>>> | on it and H reports that it doesn't halt. He's run
> >>>>>>>>>>>>>>>>> P(P) and it halts.
> >>>>>>>>>>>>>>>>> The obvious conclusion is that PO's dry run (if he
> >>>>>>>>>>>>>>>>> has indeed done such
> >>>>>>>>>>>>>>>>> a thing) is incorrect.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Exactly.
> >>>>>>>>>>>>>>>> We do our little energy budget on tigers, and find
> >>>>>>>>>>>>>>>> that tigers spend more energy
> >>>>>>>>>>>>>>>> than they take in. Well potentially this is dynamite.
> >>>>>>>>>>>>>>>> One explanation is that the
> >>>>>>>>>>>>>>>> law of conservation of energy is wrong.
> >>>>>>>>>>>>>>>> Except, before we countenance that explanation, we
> >>>>>>>>>>>>>>>> need to rule out a much
> >>>>>>>>>>>>>>>> simpler explanation. Which is that our measurements
> >>>>>>>>>>>>>>>> are wrong.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Similarly, PO has worked out what he thinks P(P)
> >>>>>>>>>>>>>>>> should be doing, by dry-running
> >>>>>>>>>>>>>>>> it, and then actually run P(P) and obtained a
> >>>>>>>>>>>>>>>> different result. He also found that H
> >>>>>>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
> >>>>>>>>>>>>>>>> conclusion, but it is extensive
> >>>>>>>>>>>>>>>> and far-reaching in its implications. The behaviour
> >>>>>>>>>>>>>>>> of code when run is different
> >>>>>>>>>>>>>>>> from the correct behaviour of the code when
> >>>>>>>>>>>>>>>> simulated. If that's true, then it has
> >>>>>>>>>>>>>>>> similar implications for computer science that
> >>>>>>>>>>>>>>>> disproving the conservation law
> >>>>>>>>>>>>>>>> has for physics.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> But the obvious explanation is that the dry-run was
> >>>>>>>>>>>>>>>> incorrect. Lots of people have
> >>>>>>>>>>>>>>>> suggested why it is incorrect. But they can't
> >>>>>>>>>>>>>>>> actually see the code. PO needs to
> >>>>>>>>>>>>>>>> understand that no-one will accept the complicated,
> >>>>>>>>>>>>>>>> far-reaching explanation,
> >>>>>>>>>>>>>>>> until the simple explanation has been ruled out.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I already proved that the dry run is correct.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Someone reports that tigers use more energy than they
> >>>>>>>>>>>>>> take in, and concludes that
> >>>>>>>>>>>>>> the energy conservation law is incorrect.
> >>>>>>>>>>>>>> Naturally, everyone is going to say "There must be some
> >>>>>>>>>>>>>> mistake. How were your
> >>>>>>>>>>>>>> measurements taken? Show us your calculations, maybe
> >>>>>>>>>>>>>> you've got your sums wrong."
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Now if they are also uncooperative about sharing the
> >>>>>>>>>>>>>> details of the investigation,
> >>>>>>>>>>>>>> those reservations will be magnified. There can be
> >>>>>>>>>>>>>> legitimate reasons. Tigers are
> >>>>>>>>>>>>>> rare and need to be conserved, you can't let anyone who
> >>>>>>>>>>>>>> wants have access to the
> >>>>>>>>>>>>>> tigers to try to repeat the measurements. But there's
> >>>>>>>>>>>>>> also a common illegitimate
> >>>>>>>>>>>>>> reason put forwards by people who make extraordinary
> >>>>>>>>>>>>>> claims. If the claims were
> >>>>>>>>>>>>>> unexceptional, such as that tigers have a similar
> >>>>>>>>>>>>>> energy budget to lions, then no-one
> >>>>>>>>>>>>>> would be saying "Show me your notebooks. How do you
> >>>>>>>>>>>>>> know that calorimeter was
> >>>>>>>>>>>>>> calibrated accurately? What's the name of the person
> >>>>>>>>>>>>>> who took that measurement
> >>>>>>>>>>>>>> and can I interview them?" Extraordinary claims are put
> >>>>>>>>>>>>>> through the wringer in a way
> >>>>>>>>>>>>>> that ordinary ones are not. I've seen complaints about
> >>>>>>>>>>>>>> this from parapsychologists.
> >>>>>>>>>>>>>> But if you're going to claim to have discovered a new
> >>>>>>>>>>>>>> physical principle, you need
> >>>>>>>>>>>>>> to present rock solid evidence.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> In this case, we can't see H. We can only suggest
> >>>>>>>>>>>>>> explanations for its behaviour.
> >>>>>>>>>>>>> It seems that you simply lack the technical competence.
> >>>>>>>>>>>>> Go back and look at my proof again.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Sorry no. I've been programming since I was a boy and I
> >>>>>>>>>>>> have a PhD in a computational-
> >>>>>>>>>>>> related subject. I'm confident of my technical abilities.
> >>>>>>>>>>>> What I can't do of course
> >>>>>>>>>>>> is tell you exactly what is going on in code I cannot
> >>>>>>>>>>>> see. I've got a pretty good idea,
> >>>>>>>>>>>> but I can only reconstruct on the basis of what you tell
> >>>>>>>>>>>> me. Ben thinks that I've
> >>>>>>>>>>>> got it wrong and in fact there are no nested emulations
> >>>>>>>>>>>> at all. I've no way of actually
> >>>>>>>>>>>> disproving that idea without seeing H.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> To fully understand this a software engineer must be an
> >>>>>>>>>>> expert in: (a) The C programming language,
> >>>>>>>>>>> (b) The x86 programming language,
> >>>>>>>>>>> (c) Exactly how C translates into x86 and,
> >>>>>>>>>>> (d) The ability to recognize infinite recursion at the x86
> >>>>>>>>>>> assembly language level.
> >>>>>>>>>>>
> >>>>>>>>>>> Anyone having the above credentials can validate my work,
> >>>>>>>>>>> if you cannot validate my work then you do not
> >>>>>>>>>>> sufficiently have the above credentials.
> >>>>>>>>>>>
> >>>>>>>>>>> Exactly how C translates into x86 is mandatory. If you
> >>>>>>>>>>> don't know how the C calling conventions are implemented
> >>>>>>>>>>> in x86 you cannot validate my work.
> >>>>>>>>>>>
> >>>>>>>>>>> From a purely software engineering perspective
> >>>>>>>>>>> H(P,P) is required to to correctly determine that its
> >>>>>>>>>>> correct and complete x86 emulation of its input would
> >>>>>>>>>>> never reach the "ret" instruction of this input and H
> >>>>>>>>>>> must do this in a finite number of steps.
> >>>>>>>>>>>
> >>>>>>>>>>> The ordinary semantics of standard C and the conventional
> >>>>>>>>>>> x86 language are the entire semantics required to
> >>>>>>>>>>> conclusively prove that H(P,P) does correctly determine
> >>>>>>>>>>> that its correct and complete x86 emulation of its input
> >>>>>>>>>>> would never reach the "ret" instruction (final state) of
> >>>>>>>>>>> this input thus never halts.
> >>>>>>>>>>>
> >>>>>>>>>>> The correct and complete x86 emulation of its input by
> >>>>>>>>>>> H(P,P) would never reach the "ret" instruction of P
> >>>>>>>>>>> because both H and P would remain stuck in infinitely
> >>>>>>>>>>> nested emulation.
> >>>>>>>>>>>
> >>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>> {
> >>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>> return;
> >>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>> int main()
> >>>>>>>>>>> {
> >>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>> _P()
> >>>>>>>>>>> [00001202](01) 55 push ebp
> >>>>>>>>>>> [00001203](02) 8bec mov ebp,esp
> >>>>>>>>>>> [00001205](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>> [00001208](01) 50 push eax
> >>>>>>>>>>> [00001209](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>> [0000120c](01) 51 push ecx
> >>>>>>>>>>> [0000120d](05) e820feffff call 00001032
> >>>>>>>>>>> [00001212](03) 83c408 add esp,+08
> >>>>>>>>>>> [00001215](02) 85c0 test eax,eax
> >>>>>>>>>>> [00001217](02) 7402 jz 0000121b
> >>>>>>>>>>> [00001219](02) ebfe jmp 00001219
> >>>>>>>>>>> [0000121b](01) 5d pop ebp
> >>>>>>>>>>> [0000121c](01) c3 ret
> >>>>>>>>>>> Size in bytes:(0027) [0000121c]
> >>>>>>>>>>>
> >>>>>>>>>>> _main()
> >>>>>>>>>>> [00001222](01) 55 push ebp
> >>>>>>>>>>> [00001223](02) 8bec mov ebp,esp
> >>>>>>>>>>> [00001225](05) 6802120000 push 00001202
> >>>>>>>>>>> [0000122a](05) 6802120000 push 00001202
> >>>>>>>>>>> [0000122f](05) e8fefdffff call 00001032
> >>>>>>>>>>> [00001234](03) 83c408 add esp,+08
> >>>>>>>>>>> [00001237](01) 50 push eax
> >>>>>>>>>>> [00001238](05) 68b3030000 push 000003b3
> >>>>>>>>>>> [0000123d](05) e8c0f1ffff call 00000402
> >>>>>>>>>>> [00001242](03) 83c408 add esp,+08
> >>>>>>>>>>> [00001245](02) 33c0 xor eax,eax
> >>>>>>>>>>> [00001247](01) 5d pop ebp
> >>>>>>>>>>> [00001248](01) c3 ret
> >>>>>>>>>>> Size in bytes:(0039) [00001248]
> >>>>>>>>>>>
> >>>>>>>>>>> machine stack stack machine assembly
> >>>>>>>>>>> address address data code language
> >>>>>>>>>>> ======== ======== ======== =========
> >>>>>>>>>>> ============= [00001222][0010200f][00000000] 55
> >>>>>>>>>>> push ebp [00001223][0010200f][00000000] 8bec mov
> >>>>>>>>>>> ebp,esp [00001225][0010200b][00001202] 6802120000 push
> >>>>>>>>>>> 00001202 // push P [0000122a][00102007][00001202]
> >>>>>>>>>>> 6802120000 push 00001202 // push P
> >>>>>>>>>>> [0000122f][00102003][00001234] e8fefdffff call 00001032
> >>>>>>>>>>> // call executed H
> >>>>>>>>>>>
> >>>>>>>>>>> Begin Simulation Execution Trace Stored at:2120c3
> >>>>>>>>>>> Address_of_H:1032
> >>>>>>>>>>> [00001202][002120af][002120b3] 55 push ebp
> >>>>>>>>>>> [00001203][002120af][002120b3] 8bec mov ebp,esp
> >>>>>>>>>>> [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>> [00001208][002120ab][00001202] 50 push eax //
> >>>>>>>>>>> push P [00001209][002120ab][00001202] 8b4d08 mov
> >>>>>>>>>>> ecx,[ebp+08] [0000120c][002120a7][00001202] 51
> >>>>>>>>>>> push ecx // push P [0000120d][002120a3][00001212]
> >>>>>>>>>>> e820feffff call 00001032 // call emulated H Infinitely
> >>>>>>>>>>> Recursive Simulation Detected Simulation Stopped
> >>>>>>>>>>>
> >>>>>>>>>>> H knows its own machine address and on this basis it can
> >>>>>>>>>>> easily examine its stored execution_trace of P (see above)
> >>>>>>>>>>> to determine: (a) P is calling H with the same arguments
> >>>>>>>>>>> that H was called with. (b) No instructions in P could
> >>>>>>>>>>> possibly escape this otherwise infinitely recursive
> >>>>>>>>>>> emulation. (c) H aborts its emulation of P before its call
> >>>>>>>>>>> to H is emulated.
> >>>>>>>>>>
> >>>>>>>>>> When you know that H simply implements the above algorithm
> >>>>>>>>>> there is no need to see its source code. I am reserving the
> >>>>>>>>>> publication of the 5 pages of the source code of the halt
> >>>>>>>>>> decider for journal publication.
> >>>>>>>>>
> >>>>>>>>> Your H is not a pure function as it behaves differently
> >>>>>>>>> depending on what is invoking it (it returns a decision
> >>>>>>>>> answer to main() but not to P()) and it has side effects
> >>>>>>>>> (aborting a simulation).
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Finally a critique that has a reasonable basis.
> >>>>>>>>
> >>>>>>>> When I transformed H into a pure function of its inputs it
> >>>>>>>> always has the same behavior no matter how it is invoked.
> >>>>>>>>
> >>>>>>>> The x86 emulation of P is aborted before P invokes H.
> >>>>>>>
> >>>>>>> Nope. Preventing a call to H is equivalent to H behaving
> >>>>>>> differently for same inputs. Aborting a simulation is a side
> >>>>>>> effect: pure functions do not have side effects.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> In other words you are saying that a halt decider is simply not
> >>>>>> allowed to report when it correctly detects that it is being
> >>>>>> called in infinitely recursive simulation.
> >>>>>
> >>>>> I keep telling you this: the infinite recursion is NOT present
> >>>>> when using a valid halt decider: your H is NOT a valid halt
> >>>>> decider.
> >>>>>
> >>>>> Simulation is an erroneous approach as a simulating halt decider
> >>>>> can not answer in finite time for a non-halting input as there
> >>>>> is no proven general solution for detecting non-halting
> >>>>> behaviour.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR
> >>>> DISHONESTLY YOU DENY THIS VERIFIABLE FACT:
> >>>>
> >>>> The correct and complete x86 emulation of its input by H(P,P)
> >>>> would never reach the "ret" instruction of P because both H and
> >>>> P would remain stuck in infinitely nested emulation.
> >>>
> >>> For [Strachey 1965] (and the proofs based on it) H is NOT a
> >>> simulating halt decider so there is no infinite recursion as there
> >>> is no emulation.
> >>>
> >>> Valid halt deciders ANALYSE P, they do not EMULATE P.
> >>>
> >>> /Flibble
> >>>
> >>
> >> I provide a halt decider H that gets the right answer and your
> >> rebuttal is that H does not get the right answer because there is
> >> another different halt decider named H1 that gets the wrong
> >> answer.
> >
> > Your H also gets the wrong answer:
> >
> > 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
> >
>
> Yet you only have dogma and no supporting reasoning.
>
> The reason that you only have dogma and no supporting reasoning is
> that tautologies such as this one have no correct rebuttal in the
> universe:
>
> The ordinary semantics of standard C and the conventional x86
> language are the entire semantics required to conclusively prove that
> H(P,P) does correctly predict that its correct and complete x86
> emulation of its input would never reach the "ret" instruction (final
> state) of this input thus never halts.
No halting decider (including yours) can return a correct answer of
non-halting for the general case as there is no proven method for
detecting non-halting behaviour for the general case. Feel free to
prove me wrong by publishing the source code of your magical non-halting
detection algorithm.
The more obvious problem with your halting decider is that it cannot
even return a correct answer of halting for a program that can be
trivially shown to halt:
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-25 13:03 -0400 |
| Message-ID | <ndHtK.236184$70j.134397@fx16.iad> |
| In reply to | #52950 |
On 6/25/22 12:06 PM, olcott wrote:
> On 6/25/2022 10:59 AM, Mr Flibble wrote:
>> On Sat, 25 Jun 2022 10:54:13 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/25/2022 10:21 AM, Mr Flibble wrote:
>>>> On Sat, 25 Jun 2022 10:19:02 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 6/25/2022 10:09 AM, Mr Flibble wrote:
>>>>>> On Sat, 25 Jun 2022 10:03:17 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 6/25/2022 9:28 AM, olcott wrote:
>>>>>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
>>>>>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>>>>>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>>>>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>>>>>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>>>>>> "Dry run" means that a human programmer looks at the
>>>>>>>>>>>>>>> code, and determines
>>>>>>>>>>>>>>> what it does, without actually executing it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt.
>>>>>>>>>>>>>> He's invoked H
>>>>>>>>>>>>>> | on it and H reports that it doesn't halt. He's run P(P)
>>>>>>>>>>>>>> and it halts.
>>>>>>>>>>>>>> The obvious conclusion is that PO's dry run (if he has
>>>>>>>>>>>>>> indeed done such
>>>>>>>>>>>>>> a thing) is incorrect.
>>>>>>>>>>>>> Exactly.
>>>>>>>>>>>>> We do our little energy budget on tigers, and find that
>>>>>>>>>>>>> tigers spend more energy
>>>>>>>>>>>>> than they take in. Well potentially this is dynamite. One
>>>>>>>>>>>>> explanation is that the
>>>>>>>>>>>>> law of conservation of energy is wrong.
>>>>>>>>>>>>> Except, before we countenance that explanation, we need to
>>>>>>>>>>>>> rule out a much
>>>>>>>>>>>>> simpler explanation. Which is that our measurements are
>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should be
>>>>>>>>>>>>> doing, by dry-running
>>>>>>>>>>>>> it, and then actually run P(P) and obtained a different
>>>>>>>>>>>>> result. He also found that H
>>>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
>>>>>>>>>>>>> conclusion, but it is extensive
>>>>>>>>>>>>> and far-reaching in its implications. The behaviour of code
>>>>>>>>>>>>> when run is different
>>>>>>>>>>>>> from the correct behaviour of the code when simulated. If
>>>>>>>>>>>>> that's true, then it has
>>>>>>>>>>>>> similar implications for computer science that disproving
>>>>>>>>>>>>> the conservation law
>>>>>>>>>>>>> has for physics.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But the obvious explanation is that the dry-run was
>>>>>>>>>>>>> incorrect. Lots of people have
>>>>>>>>>>>>> suggested why it is incorrect. But they can't actually see
>>>>>>>>>>>>> the code. PO needs to
>>>>>>>>>>>>> understand that no-one will accept the complicated,
>>>>>>>>>>>>> far-reaching explanation,
>>>>>>>>>>>>> until the simple explanation has been ruled out.
>>>>>>>>>>>>
>>>>>>>>>>>> I already proved that the dry run is correct.
>>>>>>>>>>> Someone reports that tigers use more energy than they take
>>>>>>>>>>> in, and concludes that
>>>>>>>>>>> the energy conservation law is incorrect.
>>>>>>>>>>> Naturally, everyone is going to say "There must be some
>>>>>>>>>>> mistake. How were your
>>>>>>>>>>> measurements taken? Show us your calculations, maybe you've
>>>>>>>>>>> got your sums wrong."
>>>>>>>>>>>
>>>>>>>>>>> Now if they are also uncooperative about sharing the details
>>>>>>>>>>> of the investigation,
>>>>>>>>>>> those reservations will be magnified. There can be legitimate
>>>>>>>>>>> reasons. Tigers are
>>>>>>>>>>> rare and need to be conserved, you can't let anyone who wants
>>>>>>>>>>> have access to the
>>>>>>>>>>> tigers to try to repeat the measurements. But there's also a
>>>>>>>>>>> common illegitimate
>>>>>>>>>>> reason put forwards by people who make extraordinary claims.
>>>>>>>>>>> If the claims were
>>>>>>>>>>> unexceptional, such as that tigers have a similar energy
>>>>>>>>>>> budget to lions, then no-one
>>>>>>>>>>> would be saying "Show me your notebooks. How do you know that
>>>>>>>>>>> calorimeter was
>>>>>>>>>>> calibrated accurately? What's the name of the person who took
>>>>>>>>>>> that measurement
>>>>>>>>>>> and can I interview them?" Extraordinary claims are put
>>>>>>>>>>> through the wringer in a way
>>>>>>>>>>> that ordinary ones are not. I've seen complaints about this
>>>>>>>>>>> from parapsychologists.
>>>>>>>>>>> But if you're going to claim to have discovered a new
>>>>>>>>>>> physical principle, you need
>>>>>>>>>>> to present rock solid evidence.
>>>>>>>>>>>
>>>>>>>>>>> In this case, we can't see H. We can only suggest
>>>>>>>>>>> explanations for its behaviour.
>>>>>>>>>> It seems that you simply lack the technical competence.
>>>>>>>>>> Go back and look at my proof again.
>>>>>>>>> Sorry no. I've been programming since I was a boy and I have a
>>>>>>>>> PhD in a computational-
>>>>>>>>> related subject. I'm confident of my technical abilities. What
>>>>>>>>> I can't do of course
>>>>>>>>> is tell you exactly what is going on in code I cannot see. I've
>>>>>>>>> got a pretty good idea,
>>>>>>>>> but I can only reconstruct on the basis of what you tell me.
>>>>>>>>> Ben thinks that I've
>>>>>>>>> got it wrong and in fact there are no nested emulations at all.
>>>>>>>>> I've no way of actually
>>>>>>>>> disproving that idea without seeing H.
>>>>>>>>
>>>>>>>> To fully understand this a software engineer must be an expert
>>>>>>>> in: (a) The C programming language,
>>>>>>>> (b) The x86 programming language,
>>>>>>>> (c) Exactly how C translates into x86 and,
>>>>>>>> (d) The ability to recognize infinite recursion at the x86
>>>>>>>> assembly language level.
>>>>>>>>
>>>>>>>> Anyone having the above credentials can validate my work, if you
>>>>>>>> cannot validate my work then you do not sufficiently have the
>>>>>>>> above credentials.
>>>>>>>>
>>>>>>>> Exactly how C translates into x86 is mandatory. If you don't
>>>>>>>> know how the C calling conventions are implemented in x86 you
>>>>>>>> cannot validate my work.
>>>>>>>>
>>>>>>>> From a purely software engineering perspective H(P,P) is
>>>>>>>> required to to correctly determine that its correct and complete
>>>>>>>> x86 emulation of its input would never reach the "ret"
>>>>>>>> instruction of this input and H must do this in a finite number
>>>>>>>> of steps.
>>>>>>>>
>>>>>>>> The ordinary semantics of standard C and the conventional x86
>>>>>>>> language are the entire semantics required to conclusively prove
>>>>>>>> that H(P,P) does correctly determine that its correct and
>>>>>>>> complete x86 emulation of its input would never reach the "ret"
>>>>>>>> instruction (final state) of this input thus never halts.
>>>>>>>>
>>>>>>>> The correct and complete x86 emulation of its input by H(P,P)
>>>>>>>> would never reach the "ret" instruction of P because both H and
>>>>>>>> P would remain stuck in infinitely nested emulation.
>>>>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>> if (H(x, x))
>>>>>>>> HERE: goto HERE;
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [00001202](01) 55 push ebp
>>>>>>>> [00001203](02) 8bec mov ebp,esp
>>>>>>>> [00001205](03) 8b4508 mov eax,[ebp+08]
>>>>>>>> [00001208](01) 50 push eax
>>>>>>>> [00001209](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [0000120c](01) 51 push ecx
>>>>>>>> [0000120d](05) e820feffff call 00001032
>>>>>>>> [00001212](03) 83c408 add esp,+08
>>>>>>>> [00001215](02) 85c0 test eax,eax
>>>>>>>> [00001217](02) 7402 jz 0000121b
>>>>>>>> [00001219](02) ebfe jmp 00001219
>>>>>>>> [0000121b](01) 5d pop ebp
>>>>>>>> [0000121c](01) c3 ret
>>>>>>>> Size in bytes:(0027) [0000121c]
>>>>>>>>
>>>>>>>> _main()
>>>>>>>> [00001222](01) 55 push ebp
>>>>>>>> [00001223](02) 8bec mov ebp,esp
>>>>>>>> [00001225](05) 6802120000 push 00001202
>>>>>>>> [0000122a](05) 6802120000 push 00001202
>>>>>>>> [0000122f](05) e8fefdffff call 00001032
>>>>>>>> [00001234](03) 83c408 add esp,+08
>>>>>>>> [00001237](01) 50 push eax
>>>>>>>> [00001238](05) 68b3030000 push 000003b3
>>>>>>>> [0000123d](05) e8c0f1ffff call 00000402
>>>>>>>> [00001242](03) 83c408 add esp,+08
>>>>>>>> [00001245](02) 33c0 xor eax,eax
>>>>>>>> [00001247](01) 5d pop ebp
>>>>>>>> [00001248](01) c3 ret
>>>>>>>> Size in bytes:(0039) [00001248]
>>>>>>>>
>>>>>>>> machine stack stack machine assembly
>>>>>>>> address address data code language
>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>> [00001222][0010200f][00000000] 55 push ebp
>>>>>>>> [00001223][0010200f][00000000] 8bec mov ebp,esp
>>>>>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 // push
>>>>>>>> P [0000122a][00102007][00001202] 6802120000 push 00001202 //
>>>>>>>> push P [0000122f][00102003][00001234] e8fefdffff call 00001032
>>>>>>>> // call executed H
>>>>>>>>
>>>>>>>> Begin Simulation Execution Trace Stored at:2120c3
>>>>>>>> Address_of_H:1032
>>>>>>>> [00001202][002120af][002120b3] 55 push ebp
>>>>>>>> [00001203][002120af][002120b3] 8bec mov ebp,esp
>>>>>>>> [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
>>>>>>>> [00001208][002120ab][00001202] 50 push eax // push
>>>>>>>> P [00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [0000120c][002120a7][00001202] 51 push ecx // push
>>>>>>>> P [0000120d][002120a3][00001212] e820feffff call 00001032 //
>>>>>>>> call emulated H Infinitely Recursive Simulation Detected
>>>>>>>> Simulation Stopped
>>>>>>>>
>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>> examine its stored execution_trace of P (see above) to
>>>>>>>> determine: (a) P is calling H with the same arguments that H
>>>>>>>> was called with. (b) No instructions in P could possibly escape
>>>>>>>> this otherwise infinitely recursive emulation.
>>>>>>>> (c) H aborts its emulation of P before its call to H is
>>>>>>>> emulated.
>>>>>>>
>>>>>>> When you know that H simply implements the above algorithm there
>>>>>>> is no need to see its source code. I am reserving the
>>>>>>> publication of the 5 pages of the source code of the halt
>>>>>>> decider for journal publication.
>>>>>>
>>>>>> Your H is not a pure function as it behaves differently depending
>>>>>> on what is invoking it (it returns a decision answer to main()
>>>>>> but not to P()) and it has side effects (aborting a simulation).
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> Finally a critique that has a reasonable basis.
>>>>>
>>>>> When I transformed H into a pure function of its inputs it always
>>>>> has the same behavior no matter how it is invoked.
>>>>>
>>>>> The x86 emulation of P is aborted before P invokes H.
>>>> Nope. Preventing a call to H is equivalent to H behaving differently
>>>> for same inputs. Aborting a simulation is a side effect: pure
>>>> functions do not have side effects.
>>>>
>>>> /Flibble
>>>
>>> In other words you are saying that a halt decider is simply not
>>> allowed to report when it correctly detects that it is being called
>>> in infinitely recursive simulation.
>>
>> I keep telling you this: the infinite recursion is NOT present when
>> using a valid halt decider: your H is NOT a valid halt
>> decider.
>>
>> Simulation is an erroneous approach as a simulating halt decider
>> can not answer in finite time for a non-halting input as there is no
>> proven general solution for detecting non-halting behaviour.
>>
>> /Flibble
>>
>
> IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY YOU
> DENY THIS VERIFIABLE FACT:
>
> The correct and complete x86 emulation of its input by H(P,P)
> would never reach the "ret" instruction of P because both H and
> P would remain stuck in infinitely nested emulation.
>
SO?
H doesn't do a correct and complete x86 emulation of its input so the
statement doesn't apply.
H FALSELY ASSUMES that its copy will do this, so it is incorrect.
Either H is doing an INCORRECT emulation by that assumption, or H isn't
a pure function and behaving differently in different contexts.
Maybe we can't tell HOW H is wrong, becuase you don't give us enough
information, but it IS wrong, even by the nature of your definition.
Putting FALSE rules into you logic means you are working in a FALSE
logic system.
YOU FAIL.
[toc] | [prev] | [next] | [standalone]
| From | Python <python@example.invalid> |
|---|---|
| Date | 2022-06-25 18:31 +0200 |
| Message-ID | <t97d9j$135f$2@gioia.aioe.org> |
| In reply to | #52948 |
Demented bigot, Peter Olcott wrote: ... > In other words you are saying that a halt decider is simply not allowed > to report when it correctly detects that it is being called in > infinitely recursive simulation. > > We could also "prove" that a correct halt decider is impossible by > making another similar rule that halt deciders are simply not allowed to > report on infinite loops. You can also "prove" that a natural number that is both even and odd is even. It doesn't mean that such a number exists. Publish your code for H. We do have a proof (mutiple proofs) that it cannot exist as you specify it. You know that we could, then, prove that it doesn't work. This is why you are not publishing it. You are a LIAR, a DELUSIONAL CRANK, a DESPICABLE FRAUD, Olcott. [AGAIN: STOP MULTI-POSTING WITHOUT FOLLOW-UP, YOU ASSHOLE!!!]
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.theory
csiph-web