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 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 12:58 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] |
| Message-ID | <z6SdnegBwYHIxS7_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52763 |
On 6/22/2022 10:50 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>
>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>> DEFINITION of the behavior of H(P,P),
>>>>> Linz and others were aware that: A halt decider must compute the mapping
>>>>> from its inputs to an accept or reject state on the basis of the actual
>>>>> behavior that is actually specified by these inputs.
>>>>> Linz and others made the false assumption that the actual behavior that
>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>> this because no one previously fully examined a simulating halt decider
>>>>> ever before.
>>>>>> especially if that is what P calls
>>>>>> and P is claimed to be built by the Linz template.
>>>>>>
>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>
>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>
>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>> halt decider is not the same as the direct execution of these inputs"?
>>>
>>> That is an actual immutable verified fact.
>>>
>> That's your conclusion from your observations and reasoning. You've
>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>> reports "non-halting". You've run P(P), and it halts. So one
>> explanation is the one you've given but, as I said, that explanation
>> has rather far-reaching consequences.
>
> There is only one explanation. What you call the "dry-run" is not that
> same as the P(P). We've known this since the "line 15 commented out"
> days. There are two computations -- one that is not stopped and one
> that is, the "dry-run" and the run, the "simulation of the input to
> H(P,P)" and P(P). All PO is doing is trying to find words that hide
> what's going on.
>
My words are perfectly clear and correct thus leaving the only possible
rebuttal of changing the words and forming a rebuttal on the basis of
these changed words.
straw man
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely recursive emulation.
If H can determine that this is the case in a finite number of steps
then H could correctly reject its input on this basis.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-22 19:11 -0400 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] |
| Message-ID | <HkNsK.9450$mY1.3592@fx01.iad> |
| In reply to | #52768 |
On 6/22/22 1:58 PM, olcott wrote: > > My words are perfectly clear and correct thus leaving the only possible > rebuttal of changing the words and forming a rebuttal on the basis of > these changed words. No, they aren't because they don't match the definitons of the problem you claim to be working on. Start with wrong definitions, and NOTHING that follows is valid. or correct. H applied to M, x needs to accept this input if M applied to x reaches a final state in a finite number of steps and reject this input if M applied to x will NEVER, after an unbounded number of steps, reach a final state. Since when P applied to P uses H applied to P, P and then does the opposite gets the reject answer from H it Halts, then H applied to P,P rejecting this input can't be correct. PERIOD. DEFINITION. The fact that you try to twist the requirements and definitions to try to show something else, just proves that you are either dishonest or ignorant. You will NEVER be right, because your ideas are just WRONG.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 19:00 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] |
| Message-ID | <X8WdncO0l525MC7_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52791 |
On 6/22/2022 6:11 PM, Richard Damon wrote: > On 6/22/22 1:58 PM, olcott wrote: >> >> My words are perfectly clear and correct thus leaving the only >> possible rebuttal of changing the words and forming a rebuttal on the >> basis of these changed words. > > No, they aren't because they don't match the definitons of the problem > you claim to be working on. That is an entirely separate issue that cannot possibly be correctly addressed until after my words are totally agreed to in the precise context that they are specified. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-22 20:25 -0400 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ strawman deception ] |
| Message-ID | <kqOsK.155346$X_i.5924@fx18.iad> |
| In reply to | #52794 |
On 6/22/22 8:00 PM, olcott wrote: > On 6/22/2022 6:11 PM, Richard Damon wrote: >> On 6/22/22 1:58 PM, olcott wrote: >>> >>> My words are perfectly clear and correct thus leaving the only >>> possible rebuttal of changing the words and forming a rebuttal on the >>> basis of these changed words. >> >> No, they aren't because they don't match the definitons of the problem >> you claim to be working on. > > That is an entirely separate issue that cannot possibly be correctly > addressed until after my words are totally agreed to in the precise > context that they are specified. > If you start with the wrong definitions, why do people need (or even want to) agree with them. Your whole argument STARTS with a misunderstanding of the basic terms, therefore the full thing is just garbage. I wll note, that when you get ready to try to publish, the FIRST thing that the publisher is going to want to see is your list of refences for where you get your basics from. The fact that they are just your own misunderstanding of the fundamentals means you are going to get a foot into the door.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 19:34 -0500 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] |
| Message-ID | <N5WdnYziDptmKS7_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52796 |
On 6/22/2022 7:25 PM, Richard Damon wrote: > On 6/22/22 8:00 PM, olcott wrote: >> On 6/22/2022 6:11 PM, Richard Damon wrote: >>> On 6/22/22 1:58 PM, olcott wrote: >>>> >>>> My words are perfectly clear and correct thus leaving the only >>>> possible rebuttal of changing the words and forming a rebuttal on >>>> the basis of these changed words. >>> >>> No, they aren't because they don't match the definitons of the >>> problem you claim to be working on. >> >> That is an entirely separate issue that cannot possibly be correctly >> addressed until after my words are totally agreed to in the precise >> context that they are specified. >> > > If you start with the wrong definitions, why do people need (or even > want to) agree with them. > First you agree that my words are perfectly correct within their specified context then after this we can proceed with your objection that they do not meet the definitions. It is required that we have incremental closure on sub-points or full closure will be impossible to achieve. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-22 21:05 -0400 |
| Subject | Re: Technically competent Software engineers can verify this halting problem proof refutation [ full closure ] |
| Message-ID | <C%OsK.34908$f81.34498@fx43.iad> |
| In reply to | #52799 |
On 6/22/22 8:34 PM, olcott wrote: > On 6/22/2022 7:25 PM, Richard Damon wrote: >> On 6/22/22 8:00 PM, olcott wrote: >>> On 6/22/2022 6:11 PM, Richard Damon wrote: >>>> On 6/22/22 1:58 PM, olcott wrote: >>>>> >>>>> My words are perfectly clear and correct thus leaving the only >>>>> possible rebuttal of changing the words and forming a rebuttal on >>>>> the basis of these changed words. >>>> >>>> No, they aren't because they don't match the definitons of the >>>> problem you claim to be working on. >>> >>> That is an entirely separate issue that cannot possibly be correctly >>> addressed until after my words are totally agreed to in the precise >>> context that they are specified. >>> >> >> If you start with the wrong definitions, why do people need (or even >> want to) agree with them. >> > > First you agree that my words are perfectly correct within their > specified context then after this we can proceed with your objection > that they do not meet the definitions. > > It is required that we have incremental closure on sub-points or full > closure will be impossible to achieve. > > I will not agree that Falshoods are correct. IF you make that a precondition, you might as well give up. The Journal reviews will not accept that either. You need to break down your first points to show that they actually are correct. This will require you to CLEARLY define your terms in terms of what the standard theory uses. You are hamstringing yourself by moving away from the simplicity of Turing Macines into stored program machines, as you are going to first need to show that you can actually properly express the problem in that space. Note, the "C Function" P that you show, by itself, is not something that Computation Theory talks much about, as it doesn't express a complete algorithm without a PROPER definition of H. You clearly don't know the field well enough to provide that, since you haven't yet. An ACTUAL source code of H, and everything it calls, would be such a definition, PROVIDED that code obeys the requriements of being a computation (which is close to, but not identical to, a 'Pure Function' that you have been talking about).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-06-23 01:19 -0700 |
| Message-ID | <a9adde1d-ad2c-444c-9b14-88841f5e8783n@googlegroups.com> |
| In reply to | #52763 |
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: > >> On 6/22/2022 2:55 AM, Malcolm McLean wrote: > >> > On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: > >> >> On 6/21/2022 9:52 PM, Richard Damon wrote: > >> >>> > >> >>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H > >> >>> was incorrect in its mapping, since the behavior of P(P) is the > >> >>> DEFINITION of the behavior of H(P,P), > >> >> Linz and others were aware that: A halt decider must compute the mapping > >> >> from its inputs to an accept or reject state on the basis of the actual > >> >> behavior that is actually specified by these inputs. > >> >> Linz and others made the false assumption that the actual behavior that > >> >> is actually specified by the inputs to a simulating halt decider is not > >> >> the same as the direct execution of these inputs. They were unaware of > >> >> this because no one previously fully examined a simulating halt decider > >> >> ever before. > >> >>> especially if that is what P calls > >> >>> and P is claimed to be built by the Linz template. > >> >>> > >> >>> So, either P isn't built right, or H isn't built fight, or H is wrong. > >> >> > >> > You've dry-run P(P) and it doesn't halt. Additionally the halt decider H > >> > reports it as non-halting. So it's reasonable to assume that H is correct. > >> > > >> > However, when run, P(P) halts. So what are we to conclude? That "the > >> > actual behaviour that is actually specified by the inputs to a simulating > >> > halt decider is not the same as the direct execution of these inputs"? > >> > >> That is an actual immutable verified fact. > >> > > That's your conclusion from your observations and reasoning. You've > > dry-run P(P), and it doesn't halt. You've run H on P(P), and it > > reports "non-halting". You've run P(P), and it halts. So one > > explanation is the one you've given but, as I said, that explanation > > has rather far-reaching consequences. > There is only one explanation. What you call the "dry-run" is not that > same as the P(P). We've known this since the "line 15 commented out" > days. There are two computations -- one that is not stopped and one > that is, the "dry-run" and the run, the "simulation of the input to > H(P,P)" and P(P). All PO is doing is trying to find words that hide > what's going on. > I'm a scientists, not a mathematician. The example I always use is that you are doing an energy budget for tigers. You work how much they use on running about, lactating, maintaining their body temperature, and so on. Now let's say that you find that all results are within a few percentage points of a similar budget done for lions. You'd instantly accept this data. Now let's say that the results are wildly different from a previous budget done for lions. You wouldn't just accept that data. You'd check. You'd want to understand the reasons tigers spend far less energy on movement than lions. Now let's say that the result show that tigers use more energy than they take in food. Would you instantly conclude that the law of conservation of energy must be incorrect? The third is what PO is doing.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-23 13:14 -0500 |
| Subject | Software engineers can verify this halting problem proof refutation [ H(P,P) versus P(P) ] |
| Message-ID | <n5idnblW-_zrMCn_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52838 |
On 6/23/2022 3:19 AM, Malcolm McLean wrote:
> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>> Linz and others were aware that: A halt decider must compute the mapping
>>>>>> from its inputs to an accept or reject state on the basis of the actual
>>>>>> behavior that is actually specified by these inputs.
>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>> ever before.
>>>>>>> especially if that is what P calls
>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>
>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>
>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>
>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>
>>>> That is an actual immutable verified fact.
>>>>
>>> That's your conclusion from your observations and reasoning. You've
>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>> reports "non-halting". You've run P(P), and it halts. So one
>>> explanation is the one you've given but, as I said, that explanation
>>> has rather far-reaching consequences.
>> There is only one explanation. What you call the "dry-run" is not that
>> same as the P(P). We've known this since the "line 15 commented out"
>> days. There are two computations -- one that is not stopped and one
>> that is, the "dry-run" and the run, the "simulation of the input to
>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>> what's going on.
>>
> I'm a scientists, not a mathematician.
> The example I always use is that you are doing an energy budget for tigers.
> You work how much they use on running about, lactating, maintaining their
> body temperature, and so on.
>
> Now let's say that you find that all results are within a few percentage points
> of a similar budget done for lions. You'd instantly accept this data.
>
> Now let's say that the results are wildly different from a previous budget done
> for lions. You wouldn't just accept that data. You'd check. You'd want to
> understand the reasons tigers spend far less energy on movement than lions.
>
> Now let's say that the result show that tigers use more energy than they
> take in food. Would you instantly conclude that the law of conservation of
> energy must be incorrect?
>
> The third is what PO is doing.
I rewrote this up so that sufficiently competent software engineers
would be able to confirm that the following is correct:
To fully understand this code a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C
translates into x86 and the ability to recognize infinite recursion at
the x86 assembly language level. No knowledge of the halting problem is
required.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of P.
In computer science terminology this means that complete and correct
emulation P by H would never reach its final state and halt.
The dependency relationship that P(P) has on H(P,P) causes its behavior
to be quite different than the complete and correct x86 emulation of the
input to H(P,P) that has no such dependency relationship.
As shown below because P(P) depends on the return value of H(P,P) it has
different behavior than the correctly emulated input to H(P,P).
The correctly emulated input to H(P,P) remains stuck in recursive
emulation that never gets to the point of receiving a return value from
H, thus lacks the dependency of the executed P(P).
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
P(P);
}
_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]
_main()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) e8d3ffffff call 000011f0
[0000121d](03) 83c404 add esp,+04
[00001220](02) 33c0 xor eax,eax
[00001222](01) 5d pop ebp
[00001223](01) c3 ret
Size in bytes:(0020) [00001223]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001210][00101fba][00000000] 55 push ebp
[00001211][00101fba][00000000] 8bec mov ebp,esp
[00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
[00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
[000011f0][00101fae][00101fba] 55 push ebp // enter executed P
[000011f1][00101fae][00101fba] 8bec mov ebp,esp
[000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
[000011f6][00101faa][000011f0] 50 push eax // push P
[000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00101fa6][000011f0] 51 push ecx // push P
[000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
Begin Simulation Execution Trace Stored at:21206e
Address_of_H:1020
[000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
[000011f1][0021205a][0021205e] 8bec mov ebp,esp
[000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
[000011f6][00212056][000011f0] 50 push eax // push P
[000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00212052][000011f0] 51 push ecx // push P
[000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
Infinitely Recursive Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can easily examine
its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.
[00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
executed P
[00001203][00101fae][00101fba] 85c0 test eax,eax
[00001205][00101fae][00101fba] 7402 jz 00001209
[00001209][00101fb2][0000121d] 5d pop ebp
[0000120a][00101fb6][000011f0] c3 ret // return from
executed P
[0000121d][00101fba][00000000] 83c404 add esp,+04
[00001220][00101fba][00000000] 33c0 xor eax,eax
[00001222][00101fbe][00100000] 5d pop ebp
[00001223][00101fc2][00000000] c3 ret // ret from main
Number of Instructions Executed(878) / 67 = 13 pages
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pehoushek <pehoushek1@gmail.com> |
|---|---|
| Date | 2022-06-23 11:26 -0700 |
| Subject | Re: Software engineers can verify this halting problem proof refutation [ H(P,P) versus P(P) ] |
| Message-ID | <1be20a39-a78d-4d9f-a17e-bbb4d7097773n@googlegroups.com> |
| In reply to | #52849 |
i tell ten lines of intelligence daniel2391++
// high order reason for solving all qbfs of model set s
// transform all boolean models into all true questions
// ergo of thought is trailing universalism
static joy think (num vee, numnums& ezists, numnums& univessel)
{// when ezists isnay fill with univesselism
if (ezists.size() == zero) {
for (num g = zero; g < univessel.size(); g++) ezists.add(univessel[g]);
univessel.setsize(zero); return; }
// span deeper left span right
numnums al; numnums ar; span(vee + one, ezists, al, ar); ezists.setsize(zero);
numnums bl; numnums br; span(vee + one, univessel, bl, br); univessel.setsize(zero);
// think left think right
think(vee + one, al, bl);
think(vee + one, ar, br);
// reorder left right
for (num g = zero; g < al.size(); g++) { ezists.add(al[g]); }
for (num g = zero; g < ar.size(); g++) { ezists.add(ar[g]); }
for (num g = zero; g < bl.size(); g++) { univessel.add(bl[g]); }
for (num g = zero; g < br.size(); g++) { univessel.add(br[g]); } }
static joy spread (num vee, numnums& models) {
// vee true to right rest to left
numnums left;
numnums right;
span(vee, models, left, right); models.setsize(zero);
// spread left right then think
when( left.size()) spread(vee + one, left);
when(right.size()) spread(vee + one, right);
// left justify with right
think (vee, left, right);
// the vee level of the twiddle is primary depth
//
// note bring universal plan into ezistance affirmation to vee bit having spread vee plus one
for (num gee = zero; gee < left.size(); gee++) { ezis(*( left[gee]), vee); models.add( left[gee]); } left.setsize(zero);
// note universal plan ezists as needed
for (num g = zero; g < right.size(); g++) { univ(*(right[g]), vee); models.add(right[g]); } right.setsize(zero); }
static joy zerotoone /*bit is on*/(nums& s, num b) { (s[b >> five] += (ones[b & fifthtau])); } //
static num be /*is bit on*/(nums& s, num b) { return (s[b >> five] & (ones[b & fifthtau])); } //
static joy ezis(nums& s, num b) { s[b >> five] &= zeroes[b & fifthtau]; } //
static joy univ(nums& s, num b) { s[b >> five] & ones[b & fifthtau]; } //
static joy span /*leftright around bit*/(num b, numnums& s, numnums& l, numnums& r) // left right on bit b //
{for (num g = zero; g < s.size(); g++) if (be((*s[g]), b)) r.add(s[g]); else l.add(s[g]); } // oh of s.size() //
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-23 19:00 -0400 |
| Subject | Re: Software engineers can verify this halting problem proof refutation [ H(P,P) versus P(P) ] |
| Message-ID | <Gg6tK.131399$ntj.27012@fx15.iad> |
| In reply to | #52849 |
On 6/23/22 2:14 PM, olcott wrote:
> On 6/23/2022 3:19 AM, Malcolm McLean wrote:
>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0,
>>>>>>>> so H
>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>> Linz and others were aware that: A halt decider must compute the
>>>>>>> mapping
>>>>>>> from its inputs to an accept or reject state on the basis of the
>>>>>>> actual
>>>>>>> behavior that is actually specified by these inputs.
>>>>>>> Linz and others made the false assumption that the actual
>>>>>>> behavior that
>>>>>>> is actually specified by the inputs to a simulating halt decider
>>>>>>> is not
>>>>>>> the same as the direct execution of these inputs. They were
>>>>>>> unaware of
>>>>>>> this because no one previously fully examined a simulating halt
>>>>>>> decider
>>>>>>> ever before.
>>>>>>>> especially if that is what P calls
>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>
>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is
>>>>>>>> wrong.
>>>>>>>
>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt
>>>>>> decider H
>>>>>> reports it as non-halting. So it's reasonable to assume that H is
>>>>>> correct.
>>>>>>
>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>> actual behaviour that is actually specified by the inputs to a
>>>>>> simulating
>>>>>> halt decider is not the same as the direct execution of these
>>>>>> inputs"?
>>>>>
>>>>> That is an actual immutable verified fact.
>>>>>
>>>> That's your conclusion from your observations and reasoning. You've
>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>> explanation is the one you've given but, as I said, that explanation
>>>> has rather far-reaching consequences.
>>> There is only one explanation. What you call the "dry-run" is not that
>>> same as the P(P). We've known this since the "line 15 commented out"
>>> days. There are two computations -- one that is not stopped and one
>>> that is, the "dry-run" and the run, the "simulation of the input to
>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>> what's going on.
>>>
>> I'm a scientists, not a mathematician.
>> The example I always use is that you are doing an energy budget for
>> tigers.
>> You work how much they use on running about, lactating, maintaining their
>> body temperature, and so on.
>>
>> Now let's say that you find that all results are within a few
>> percentage points
>> of a similar budget done for lions. You'd instantly accept this data.
>>
>> Now let's say that the results are wildly different from a previous
>> budget done
>> for lions. You wouldn't just accept that data. You'd check. You'd want to
>> understand the reasons tigers spend far less energy on movement than
>> lions.
>>
>> Now let's say that the result show that tigers use more energy than they
>> take in food. Would you instantly conclude that the law of
>> conservation of
>> energy must be incorrect?
>>
>> The third is what PO is doing.
>
> I rewrote this up so that sufficiently competent software engineers
> would be able to confirm that the following is correct:
>
> To fully understand this code a software engineer must be an expert in:
> the C programming language, the x86 programming language, exactly how C
> translates into x86 and the ability to recognize infinite recursion at
> the x86 assembly language level. No knowledge of the halting problem is
> required.
>
> The ordinary semantics of standard C and the conventional x86 language
> are the entire semantics required to conclusively prove that H(P,P) does
> correctly determine that its correct and complete x86 emulation of its
> input would never reach the "ret" instruction of P.
>
> In computer science terminology this means that complete and correct
> emulation P by H would never reach its final state and halt.
>
> The dependency relationship that P(P) has on H(P,P) causes its behavior
> to be quite different than the complete and correct x86 emulation of the
> input to H(P,P) that has no such dependency relationship.
>
> As shown below because P(P) depends on the return value of H(P,P) it has
> different behavior than the correctly emulated input to H(P,P).
>
> The correctly emulated input to H(P,P) remains stuck in recursive
> emulation that never gets to the point of receiving a return value from
> H, thus lacks the dependency of the executed P(P).
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> P(P);
> }
>
> _P()
> [000011f0](01) 55 push ebp
> [000011f1](02) 8bec mov ebp,esp
> [000011f3](03) 8b4508 mov eax,[ebp+08]
> [000011f6](01) 50 push eax
> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
> [000011fa](01) 51 push ecx
> [000011fb](05) e820feffff call 00001020
> [00001200](03) 83c408 add esp,+08
> [00001203](02) 85c0 test eax,eax
> [00001205](02) 7402 jz 00001209
> [00001207](02) ebfe jmp 00001207
> [00001209](01) 5d pop ebp
> [0000120a](01) c3 ret
> Size in bytes:(0027) [0000120a]
>
> _main()
> [00001210](01) 55 push ebp
> [00001211](02) 8bec mov ebp,esp
> [00001213](05) 68f0110000 push 000011f0
> [00001218](05) e8d3ffffff call 000011f0
> [0000121d](03) 83c404 add esp,+04
> [00001220](02) 33c0 xor eax,eax
> [00001222](01) 5d pop ebp
> [00001223](01) c3 ret
> Size in bytes:(0020) [00001223]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [00001210][00101fba][00000000] 55 push ebp
> [00001211][00101fba][00000000] 8bec mov ebp,esp
> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
> [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
> [000011f1][00101fae][00101fba] 8bec mov ebp,esp
> [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
> [000011f6][00101faa][000011f0] 50 push eax // push P
> [000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
> [000011fa][00101fa6][000011f0] 51 push ecx // push P
> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
>
> Begin Simulation Execution Trace Stored at:21206e
> Address_of_H:1020
> [000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
> [000011f1][0021205a][0021205e] 8bec mov ebp,esp
> [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
> [000011f6][00212056][000011f0] 50 push eax // push P
> [000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
> [000011fa][00212052][000011f0] 51 push ecx // push P
> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
> Infinitely Recursive Simulation Detected Simulation Stopped
>
> H knows its own machine address and on this basis it can easily examine
> its stored execution_trace of P (see above) to determine:
> (a) P is calling H with the same arguments that H was called with.
> (b) No instructions in P could possibly escape this otherwise infinitely
> recursive emulation.
> (c) H aborts its emulation of P before its call to H is emulated.
>
> [00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
> executed P
> [00001203][00101fae][00101fba] 85c0 test eax,eax
> [00001205][00101fae][00101fba] 7402 jz 00001209
> [00001209][00101fb2][0000121d] 5d pop ebp
> [0000120a][00101fb6][000011f0] c3 ret // return from
> executed P
> [0000121d][00101fba][00000000] 83c404 add esp,+04
> [00001220][00101fba][00000000] 33c0 xor eax,eax
> [00001222][00101fbe][00100000] 5d pop ebp
> [00001223][00101fc2][00000000] c3 ret // ret from main
> Number of Instructions Executed(878) / 67 = 13 pages
>
>
(b) is invalid, so H is not correct.
H's criteria of being defined to deside on ITS OWN compelete and correct
emulation is basicaly saying that cats that are dog can bark, thus there
exists cats that bark.
ANY simulating decider H that somehow decides that its input is
non-halting and stops its simulations doesn't do a complete and correct
simulation, and thus it is WRONG to say that was a basis for its decision.
Until you can show how a simulator can simulate an unbounded number of
steps (aka infinite number) in a finite number of steps, you have an
impossible premise.
That means you need to find a computation system that can do infinite
work in finite time for your arguement to be valid.
YOU FAIL.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-06-23 23:44 +0100 |
| Message-ID | <87sfnv2e6e.fsf@bsb.me.uk> |
| In reply to | #52838 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >> > On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >> >> On 6/22/2022 2:55 AM, Malcolm McLean wrote: >> >> > On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >> >> >> On 6/21/2022 9:52 PM, Richard Damon wrote: >> >> >>> >> >> >>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H >> >> >>> was incorrect in its mapping, since the behavior of P(P) is the >> >> >>> DEFINITION of the behavior of H(P,P), >> >> >> Linz and others were aware that: A halt decider must compute the mapping >> >> >> from its inputs to an accept or reject state on the basis of the actual >> >> >> behavior that is actually specified by these inputs. >> >> >> Linz and others made the false assumption that the actual behavior that >> >> >> is actually specified by the inputs to a simulating halt decider is not >> >> >> the same as the direct execution of these inputs. They were unaware of >> >> >> this because no one previously fully examined a simulating halt decider >> >> >> ever before. >> >> >>> especially if that is what P calls >> >> >>> and P is claimed to be built by the Linz template. >> >> >>> >> >> >>> So, either P isn't built right, or H isn't built fight, or H is wrong. >> >> >> >> >> > You've dry-run P(P) and it doesn't halt. Additionally the halt decider H >> >> > reports it as non-halting. So it's reasonable to assume that H is correct. >> >> > >> >> > However, when run, P(P) halts. So what are we to conclude? That "the >> >> > actual behaviour that is actually specified by the inputs to a simulating >> >> > halt decider is not the same as the direct execution of these inputs"? >> >> >> >> That is an actual immutable verified fact. >> >> >> > That's your conclusion from your observations and reasoning. You've >> > dry-run P(P), and it doesn't halt. You've run H on P(P), and it >> > reports "non-halting". You've run P(P), and it halts. So one >> > explanation is the one you've given but, as I said, that explanation >> > has rather far-reaching consequences. >> There is only one explanation. What you call the "dry-run" is not that >> same as the P(P). We've known this since the "line 15 commented out" >> days. There are two computations -- one that is not stopped and one >> that is, the "dry-run" and the run, the "simulation of the input to >> H(P,P)" and P(P). All PO is doing is trying to find words that hide >> what's going on. >> > I'm a scientists, not a mathematician. > The example I always use is that you are doing an energy budget for tigers. > You work how much they use on running about, lactating, maintaining their > body temperature, and so on. > > Now let's say that you find that all results are within a few percentage points > of a similar budget done for lions. You'd instantly accept this data. > > Now let's say that the results are wildly different from a previous budget done > for lions. You wouldn't just accept that data. You'd check. You'd want to > understand the reasons tigers spend far less energy on movement than lions. > > Now let's say that the result show that tigers use more energy than they > take in food. Would you instantly conclude that the law of conservation of > energy must be incorrect? > > The third is what PO is doing. I have no idea what parts of this analogy map to the current situation. PO has no contradictory results about anything. There's no conflict with any established facts in anything he is doing. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-23 20:38 -0500 |
| Message-ID | <TdWdnWNGBqY0iCj_nZ2dnUU7_81QAAAA@giganews.com> |
| In reply to | #52855 |
On 6/23/2022 5:44 PM, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>> >>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote: >>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote: >>>>>>>> >>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H >>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>> DEFINITION of the behavior of H(P,P), >>>>>>> Linz and others were aware that: A halt decider must compute the mapping >>>>>>> from its inputs to an accept or reject state on the basis of the actual >>>>>>> behavior that is actually specified by these inputs. >>>>>>> Linz and others made the false assumption that the actual behavior that >>>>>>> is actually specified by the inputs to a simulating halt decider is not >>>>>>> the same as the direct execution of these inputs. They were unaware of >>>>>>> this because no one previously fully examined a simulating halt decider >>>>>>> ever before. >>>>>>>> especially if that is what P calls >>>>>>>> and P is claimed to be built by the Linz template. >>>>>>>> >>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong. >>>>>>> >>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H >>>>>> reports it as non-halting. So it's reasonable to assume that H is correct. >>>>>> >>>>>> However, when run, P(P) halts. So what are we to conclude? That "the >>>>>> actual behaviour that is actually specified by the inputs to a simulating >>>>>> halt decider is not the same as the direct execution of these inputs"? >>>>> >>>>> That is an actual immutable verified fact. >>>>> >>>> That's your conclusion from your observations and reasoning. You've >>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>> reports "non-halting". You've run P(P), and it halts. So one >>>> explanation is the one you've given but, as I said, that explanation >>>> has rather far-reaching consequences. >>> There is only one explanation. What you call the "dry-run" is not that >>> same as the P(P). We've known this since the "line 15 commented out" >>> days. There are two computations -- one that is not stopped and one >>> that is, the "dry-run" and the run, the "simulation of the input to >>> H(P,P)" and P(P). All PO is doing is trying to find words that hide >>> what's going on. >>> >> I'm a scientists, not a mathematician. >> The example I always use is that you are doing an energy budget for tigers. >> You work how much they use on running about, lactating, maintaining their >> body temperature, and so on. >> >> Now let's say that you find that all results are within a few percentage points >> of a similar budget done for lions. You'd instantly accept this data. >> >> Now let's say that the results are wildly different from a previous budget done >> for lions. You wouldn't just accept that data. You'd check. You'd want to >> understand the reasons tigers spend far less energy on movement than lions. >> >> Now let's say that the result show that tigers use more energy than they >> take in food. Would you instantly conclude that the law of conservation of >> energy must be incorrect? >> >> The third is what PO is doing. > > I have no idea what parts of this analogy map to the current situation. > PO has no contradictory results about anything. There's no conflict > with any established facts in anything he is doing. > Thanks for that. -- 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 00:53 -0700 |
| Message-ID | <3a337f21-4828-46c4-b5be-87c76cff9db4n@googlegroups.com> |
| In reply to | #52855 |
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: > >> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >> > >> > On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: > >> >> On 6/22/2022 2:55 AM, Malcolm McLean wrote: > >> >> > On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: > >> >> >> On 6/21/2022 9:52 PM, Richard Damon wrote: > >> >> >>> > >> >> >>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H > >> >> >>> was incorrect in its mapping, since the behavior of P(P) is the > >> >> >>> DEFINITION of the behavior of H(P,P), > >> >> >> Linz and others were aware that: A halt decider must compute the mapping > >> >> >> from its inputs to an accept or reject state on the basis of the actual > >> >> >> behavior that is actually specified by these inputs. > >> >> >> Linz and others made the false assumption that the actual behavior that > >> >> >> is actually specified by the inputs to a simulating halt decider is not > >> >> >> the same as the direct execution of these inputs. They were unaware of > >> >> >> this because no one previously fully examined a simulating halt decider > >> >> >> ever before. > >> >> >>> especially if that is what P calls > >> >> >>> and P is claimed to be built by the Linz template. > >> >> >>> > >> >> >>> So, either P isn't built right, or H isn't built fight, or H is wrong. > >> >> >> > >> >> > You've dry-run P(P) and it doesn't halt. Additionally the halt decider H > >> >> > reports it as non-halting. So it's reasonable to assume that H is correct. > >> >> > > >> >> > However, when run, P(P) halts. So what are we to conclude? That "the > >> >> > actual behaviour that is actually specified by the inputs to a simulating > >> >> > halt decider is not the same as the direct execution of these inputs"? > >> >> > >> >> That is an actual immutable verified fact. > >> >> > >> > That's your conclusion from your observations and reasoning. You've > >> > dry-run P(P), and it doesn't halt. You've run H on P(P), and it > >> > reports "non-halting". You've run P(P), and it halts. So one > >> > explanation is the one you've given but, as I said, that explanation > >> > has rather far-reaching consequences. > >> There is only one explanation. What you call the "dry-run" is not that > >> same as the P(P). We've known this since the "line 15 commented out" > >> days. There are two computations -- one that is not stopped and one > >> that is, the "dry-run" and the run, the "simulation of the input to > >> H(P,P)" and P(P). All PO is doing is trying to find words that hide > >> what's going on. > >> > > I'm a scientists, not a mathematician. > > The example I always use is that you are doing an energy budget for tigers. > > You work how much they use on running about, lactating, maintaining their > > body temperature, and so on. > > > > Now let's say that you find that all results are within a few percentage points > > of a similar budget done for lions. You'd instantly accept this data. > > > > Now let's say that the results are wildly different from a previous budget done > > for lions. You wouldn't just accept that data. You'd check. You'd want to > > understand the reasons tigers spend far less energy on movement than lions. > > > > Now let's say that the result show that tigers use more energy than they > > take in food. Would you instantly conclude that the law of conservation of > > energy must be incorrect? > > > > The third is what PO is doing. > I have no idea what parts of this analogy map to the current situation. > PO has no contradictory results about anything. There's no conflict > with any established facts in anything he is doing. > 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. So something odd is going on there that needs an explanation.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-24 08:07 -0500 |
| Message-ID | <A-2dnVjBk9RiKyj_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52874 |
On 6/24/2022 2:53 AM, Malcolm McLean wrote: > On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>> >>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote: >>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote: >>>>>>>>> >>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H >>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>> DEFINITION of the behavior of H(P,P), >>>>>>>> Linz and others were aware that: A halt decider must compute the mapping >>>>>>>> from its inputs to an accept or reject state on the basis of the actual >>>>>>>> behavior that is actually specified by these inputs. >>>>>>>> Linz and others made the false assumption that the actual behavior that >>>>>>>> is actually specified by the inputs to a simulating halt decider is not >>>>>>>> the same as the direct execution of these inputs. They were unaware of >>>>>>>> this because no one previously fully examined a simulating halt decider >>>>>>>> ever before. >>>>>>>>> especially if that is what P calls >>>>>>>>> and P is claimed to be built by the Linz template. >>>>>>>>> >>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong. >>>>>>>> >>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H >>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct. >>>>>>> >>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the >>>>>>> actual behaviour that is actually specified by the inputs to a simulating >>>>>>> halt decider is not the same as the direct execution of these inputs"? >>>>>> >>>>>> That is an actual immutable verified fact. >>>>>> >>>>> That's your conclusion from your observations and reasoning. You've >>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>> reports "non-halting". You've run P(P), and it halts. So one >>>>> explanation is the one you've given but, as I said, that explanation >>>>> has rather far-reaching consequences. >>>> There is only one explanation. What you call the "dry-run" is not that >>>> same as the P(P). We've known this since the "line 15 commented out" >>>> days. There are two computations -- one that is not stopped and one >>>> that is, the "dry-run" and the run, the "simulation of the input to >>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide >>>> what's going on. >>>> >>> I'm a scientists, not a mathematician. >>> The example I always use is that you are doing an energy budget for tigers. >>> You work how much they use on running about, lactating, maintaining their >>> body temperature, and so on. >>> >>> Now let's say that you find that all results are within a few percentage points >>> of a similar budget done for lions. You'd instantly accept this data. >>> >>> Now let's say that the results are wildly different from a previous budget done >>> for lions. You wouldn't just accept that data. You'd check. You'd want to >>> understand the reasons tigers spend far less energy on movement than lions. >>> >>> Now let's say that the result show that tigers use more energy than they >>> take in food. Would you instantly conclude that the law of conservation of >>> energy must be incorrect? >>> >>> The third is what PO is doing. >> I have no idea what parts of this analogy map to the current situation. >> PO has no contradictory results about anything. There's no conflict >> with any established facts in anything he is doing. >> > 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. > > So something odd is going on there that needs an explanation. I already fully addressed that in my reply to you yesterday. P(P) has a dependency relationship on the return value of H(P,P) that the correctly emulated input to H(P,P) does not have. This changes their behavior relative to each other. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-24 09:18 -0400 |
| Message-ID | <fQitK.15130$%i2.4349@fx48.iad> |
| In reply to | #52877 |
On 6/24/22 9:07 AM, olcott wrote: > On 6/24/2022 2:53 AM, Malcolm McLean wrote: >> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote: >>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>> >>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>> >>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote: >>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote: >>>>>>>>>> >>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns >>>>>>>>>> 0, so H >>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>> DEFINITION of the behavior of H(P,P), >>>>>>>>> Linz and others were aware that: A halt decider must compute >>>>>>>>> the mapping >>>>>>>>> from its inputs to an accept or reject state on the basis of >>>>>>>>> the actual >>>>>>>>> behavior that is actually specified by these inputs. >>>>>>>>> Linz and others made the false assumption that the actual >>>>>>>>> behavior that >>>>>>>>> is actually specified by the inputs to a simulating halt >>>>>>>>> decider is not >>>>>>>>> the same as the direct execution of these inputs. They were >>>>>>>>> unaware of >>>>>>>>> this because no one previously fully examined a simulating halt >>>>>>>>> decider >>>>>>>>> ever before. >>>>>>>>>> especially if that is what P calls >>>>>>>>>> and P is claimed to be built by the Linz template. >>>>>>>>>> >>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H >>>>>>>>>> is wrong. >>>>>>>>> >>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt >>>>>>>> decider H >>>>>>>> reports it as non-halting. So it's reasonable to assume that H >>>>>>>> is correct. >>>>>>>> >>>>>>>> However, when run, P(P) halts. So what are we to conclude? That >>>>>>>> "the >>>>>>>> actual behaviour that is actually specified by the inputs to a >>>>>>>> simulating >>>>>>>> halt decider is not the same as the direct execution of these >>>>>>>> inputs"? >>>>>>> >>>>>>> That is an actual immutable verified fact. >>>>>>> >>>>>> That's your conclusion from your observations and reasoning. You've >>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>> reports "non-halting". You've run P(P), and it halts. So one >>>>>> explanation is the one you've given but, as I said, that explanation >>>>>> has rather far-reaching consequences. >>>>> There is only one explanation. What you call the "dry-run" is not that >>>>> same as the P(P). We've known this since the "line 15 commented out" >>>>> days. There are two computations -- one that is not stopped and one >>>>> that is, the "dry-run" and the run, the "simulation of the input to >>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide >>>>> what's going on. >>>>> >>>> I'm a scientists, not a mathematician. >>>> The example I always use is that you are doing an energy budget for >>>> tigers. >>>> You work how much they use on running about, lactating, maintaining >>>> their >>>> body temperature, and so on. >>>> >>>> Now let's say that you find that all results are within a few >>>> percentage points >>>> of a similar budget done for lions. You'd instantly accept this data. >>>> >>>> Now let's say that the results are wildly different from a previous >>>> budget done >>>> for lions. You wouldn't just accept that data. You'd check. You'd >>>> want to >>>> understand the reasons tigers spend far less energy on movement than >>>> lions. >>>> >>>> Now let's say that the result show that tigers use more energy than >>>> they >>>> take in food. Would you instantly conclude that the law of >>>> conservation of >>>> energy must be incorrect? >>>> >>>> The third is what PO is doing. >>> I have no idea what parts of this analogy map to the current situation. >>> PO has no contradictory results about anything. There's no conflict >>> with any established facts in anything he is doing. >>> >> 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. >> >> So something odd is going on there that needs an explanation. > > I already fully addressed that in my reply to you yesterday. P(P) has a > dependency relationship on the return value of H(P,P) that the correctly > emulated input to H(P,P) does not have. This changes their behavior > relative to each other. > So, Since the behavior of P(P) depends on H, when you change the behavor of H, you have invaldated anything you have learned about P. Thus changing H from doing a pure complete and correct emulation of its input to one that Halt decides it an no longer does a complete emulation of it, you now have a DIFFERENT P, even though you didn't touch the source code of the C function P. The CORRECTLY emulated input to H(P,P), being the representation of the computation P(P) has exactly that same dependency. Rememember, P has been defined to be the Linz "impossible program", which is DEFINED to ask H about itself applied to its input, so if H(P,P) doesn't refer to P(P), then your P isn't the required function. FAIL.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-06-24 06:34 -0700 |
| Message-ID | <ae991ec7-edb8-4a8f-8461-b87ba83cdf62n@googlegroups.com> |
| In reply to | #52877 |
On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote: > On 6/24/2022 2:53 AM, Malcolm McLean wrote: > > On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote: > >> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >> > >>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: > >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >>>> > >>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: > >>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote: > >>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: > >>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote: > >>>>>>>>> > >>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H > >>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the > >>>>>>>>> DEFINITION of the behavior of H(P,P), > >>>>>>>> Linz and others were aware that: A halt decider must compute the mapping > >>>>>>>> from its inputs to an accept or reject state on the basis of the actual > >>>>>>>> behavior that is actually specified by these inputs. > >>>>>>>> Linz and others made the false assumption that the actual behavior that > >>>>>>>> is actually specified by the inputs to a simulating halt decider is not > >>>>>>>> the same as the direct execution of these inputs. They were unaware of > >>>>>>>> this because no one previously fully examined a simulating halt decider > >>>>>>>> ever before. > >>>>>>>>> especially if that is what P calls > >>>>>>>>> and P is claimed to be built by the Linz template. > >>>>>>>>> > >>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong. > >>>>>>>> > >>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H > >>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct. > >>>>>>> > >>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the > >>>>>>> actual behaviour that is actually specified by the inputs to a simulating > >>>>>>> halt decider is not the same as the direct execution of these inputs"? > >>>>>> > >>>>>> That is an actual immutable verified fact. > >>>>>> > >>>>> That's your conclusion from your observations and reasoning. You've > >>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it > >>>>> reports "non-halting". You've run P(P), and it halts. So one > >>>>> explanation is the one you've given but, as I said, that explanation > >>>>> has rather far-reaching consequences. > >>>> There is only one explanation. What you call the "dry-run" is not that > >>>> same as the P(P). We've known this since the "line 15 commented out" > >>>> days. There are two computations -- one that is not stopped and one > >>>> that is, the "dry-run" and the run, the "simulation of the input to > >>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide > >>>> what's going on. > >>>> > >>> I'm a scientists, not a mathematician. > >>> The example I always use is that you are doing an energy budget for tigers. > >>> You work how much they use on running about, lactating, maintaining their > >>> body temperature, and so on. > >>> > >>> Now let's say that you find that all results are within a few percentage points > >>> of a similar budget done for lions. You'd instantly accept this data. > >>> > >>> Now let's say that the results are wildly different from a previous budget done > >>> for lions. You wouldn't just accept that data. You'd check. You'd want to > >>> understand the reasons tigers spend far less energy on movement than lions. > >>> > >>> Now let's say that the result show that tigers use more energy than they > >>> take in food. Would you instantly conclude that the law of conservation of > >>> energy must be incorrect? > >>> > >>> The third is what PO is doing. > >> I have no idea what parts of this analogy map to the current situation. > >> PO has no contradictory results about anything. There's no conflict > >> with any established facts in anything he is doing. > >> > > 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. > > > > So something odd is going on there that needs an explanation. > > I already fully addressed that in my reply to you yesterday. P(P) has a > dependency relationship on the return value of H(P,P) that the correctly > emulated input to H(P,P) does not have. This changes their behavior > relative to each other. > I can see an alternative explanation. I was going to say "it is obvious" but no-one else has stepped in to point it out. Maybe because it's too obvious and they want to give other posters a chance.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-24 09:32 -0500 |
| Message-ID | <zfCdnUrEbbibVij_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52879 |
On 6/24/2022 8:34 AM, Malcolm McLean wrote:
> On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:
>> On 6/24/2022 2:53 AM, Malcolm McLean wrote:
>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>> Linz and others were aware that: A halt decider must compute the mapping
>>>>>>>>>> from its inputs to an accept or reject state on the basis of the actual
>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>>>>>> ever before.
>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>
>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>>>>>
>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>>>>>
>>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>>>>>
>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>
>>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>> explanation is the one you've given but, as I said, that explanation
>>>>>>> has rather far-reaching consequences.
>>>>>> There is only one explanation. What you call the "dry-run" is not that
>>>>>> same as the P(P). We've known this since the "line 15 commented out"
>>>>>> days. There are two computations -- one that is not stopped and one
>>>>>> that is, the "dry-run" and the run, the "simulation of the input to
>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>>>>> what's going on.
>>>>>>
>>>>> I'm a scientists, not a mathematician.
>>>>> The example I always use is that you are doing an energy budget for tigers.
>>>>> You work how much they use on running about, lactating, maintaining their
>>>>> body temperature, and so on.
>>>>>
>>>>> Now let's say that you find that all results are within a few percentage points
>>>>> of a similar budget done for lions. You'd instantly accept this data.
>>>>>
>>>>> Now let's say that the results are wildly different from a previous budget done
>>>>> for lions. You wouldn't just accept that data. You'd check. You'd want to
>>>>> understand the reasons tigers spend far less energy on movement than lions.
>>>>>
>>>>> Now let's say that the result show that tigers use more energy than they
>>>>> take in food. Would you instantly conclude that the law of conservation of
>>>>> energy must be incorrect?
>>>>>
>>>>> The third is what PO is doing.
>>>> I have no idea what parts of this analogy map to the current situation.
>>>> PO has no contradictory results about anything. There's no conflict
>>>> with any established facts in anything he is doing.
>>>>
>>> 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.
>>>
>>> So something odd is going on there that needs an explanation.
>>
>> I already fully addressed that in my reply to you yesterday. P(P) has a
>> dependency relationship on the return value of H(P,P) that the correctly
>> emulated input to H(P,P) does not have. This changes their behavior
>> relative to each other.
>>
> I can see an alternative explanation. I was going to say "it is obvious" but
> no-one else has stepped in to point it out. Maybe because it's too obvious
> and they want to give other posters a chance.
The provably correct execution trace proves that the complete and
correct x86 emulation of the input to H(P,P) by H would never reach the
"ret" instruction (final state) of P, thus never halts. It is also
proven that H does determine this in a finite number of states.
The provably correct execution trace of P(P) proves that the it halts.
Because it is a fact that the actual input to H(P,P) has actual behavior
that never halts then H must report on this behavior and cannot report
on any other behavior.
If you need to verify that you have a white dog in your living room
checking for a black cat in you kitchen is the wrong criteria.
If you need to verify that an input to a halt decider reaches its final
state it must be the actual behavior of this actual input. P(P) is
provably not the actual behavior of the actual input on the basis of the
ordinary semantics of the x86 language as shown in the two provably
correct execution traces.
To fully understand this code a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C
translates into x86 and the ability to recognize infinite recursion at
the x86 assembly language level. No knowledge of the halting problem is
required.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of P.
In computer science terminology this means that complete and correct
emulation P by H would never reach its final state and halt.
The dependency relationship that P(P) has on H(P,P) causes its behavior
to be quite different than the complete and correct x86 emulation of the
input to H(P,P) that has no such dependency relationship.
As shown below because P(P) depends on the return value of H(P,P) it has
different behavior than the correctly emulated input to H(P,P).
The correctly emulated input to H(P,P) remains stuck in recursive
emulation that never gets to the point of receiving a return value from
H, thus lacks the dependency of the executed P(P).
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
P(P);
}
_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]
_main()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) e8d3ffffff call 000011f0
[0000121d](03) 83c404 add esp,+04
[00001220](02) 33c0 xor eax,eax
[00001222](01) 5d pop ebp
[00001223](01) c3 ret
Size in bytes:(0020) [00001223]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001210][00101fba][00000000] 55 push ebp
[00001211][00101fba][00000000] 8bec mov ebp,esp
[00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
[00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
[000011f0][00101fae][00101fba] 55 push ebp // enter executed P
[000011f1][00101fae][00101fba] 8bec mov ebp,esp
[000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
[000011f6][00101faa][000011f0] 50 push eax // push P
[000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00101fa6][000011f0] 51 push ecx // push P
[000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
Begin Simulation Execution Trace Stored at:21206e
Address_of_H:1020
[000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
[000011f1][0021205a][0021205e] 8bec mov ebp,esp
[000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
[000011f6][00212056][000011f0] 50 push eax // push P
[000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00212052][000011f0] 51 push ecx // push P
[000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
Infinitely Recursive Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.
[00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
executed P
[00001203][00101fae][00101fba] 85c0 test eax,eax
[00001205][00101fae][00101fba] 7402 jz 00001209
[00001209][00101fb2][0000121d] 5d pop ebp
[0000120a][00101fb6][000011f0] c3 ret // return from
executed P
[0000121d][00101fba][00000000] 83c404 add esp,+04
[00001220][00101fba][00000000] 33c0 xor eax,eax
[00001222][00101fbe][00100000] 5d pop ebp
[00001223][00101fc2][00000000] c3 ret // ret from main
Number of Instructions Executed(878) / 67 = 13 pages
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-24 12:07 -0400 |
| Message-ID | <LiltK.409493$wIO9.133257@fx12.iad> |
| In reply to | #52881 |
On 6/24/22 10:32 AM, olcott wrote:
> On 6/24/2022 8:34 AM, Malcolm McLean wrote:
>> On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:
>>> On 6/24/2022 2:53 AM, Malcolm McLean wrote:
>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P)
>>>>>>>>>>>> returns 0, so H
>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>> Linz and others were aware that: A halt decider must compute
>>>>>>>>>>> the mapping
>>>>>>>>>>> from its inputs to an accept or reject state on the basis of
>>>>>>>>>>> the actual
>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>> Linz and others made the false assumption that the actual
>>>>>>>>>>> behavior that
>>>>>>>>>>> is actually specified by the inputs to a simulating halt
>>>>>>>>>>> decider is not
>>>>>>>>>>> the same as the direct execution of these inputs. They were
>>>>>>>>>>> unaware of
>>>>>>>>>>> this because no one previously fully examined a simulating
>>>>>>>>>>> halt decider
>>>>>>>>>>> ever before.
>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>
>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H
>>>>>>>>>>>> is wrong.
>>>>>>>>>>>
>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt
>>>>>>>>>> decider H
>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H
>>>>>>>>>> is correct.
>>>>>>>>>>
>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude?
>>>>>>>>>> That "the
>>>>>>>>>> actual behaviour that is actually specified by the inputs to a
>>>>>>>>>> simulating
>>>>>>>>>> halt decider is not the same as the direct execution of these
>>>>>>>>>> inputs"?
>>>>>>>>>
>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>
>>>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>> explanation is the one you've given but, as I said, that
>>>>>>>> explanation
>>>>>>>> has rather far-reaching consequences.
>>>>>>> There is only one explanation. What you call the "dry-run" is not
>>>>>>> that
>>>>>>> same as the P(P). We've known this since the "line 15 commented out"
>>>>>>> days. There are two computations -- one that is not stopped and one
>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to
>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>>>>>> what's going on.
>>>>>>>
>>>>>> I'm a scientists, not a mathematician.
>>>>>> The example I always use is that you are doing an energy budget
>>>>>> for tigers.
>>>>>> You work how much they use on running about, lactating,
>>>>>> maintaining their
>>>>>> body temperature, and so on.
>>>>>>
>>>>>> Now let's say that you find that all results are within a few
>>>>>> percentage points
>>>>>> of a similar budget done for lions. You'd instantly accept this data.
>>>>>>
>>>>>> Now let's say that the results are wildly different from a
>>>>>> previous budget done
>>>>>> for lions. You wouldn't just accept that data. You'd check. You'd
>>>>>> want to
>>>>>> understand the reasons tigers spend far less energy on movement
>>>>>> than lions.
>>>>>>
>>>>>> Now let's say that the result show that tigers use more energy
>>>>>> than they
>>>>>> take in food. Would you instantly conclude that the law of
>>>>>> conservation of
>>>>>> energy must be incorrect?
>>>>>>
>>>>>> The third is what PO is doing.
>>>>> I have no idea what parts of this analogy map to the current
>>>>> situation.
>>>>> PO has no contradictory results about anything. There's no conflict
>>>>> with any established facts in anything he is doing.
>>>>>
>>>> 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.
>>>>
>>>> So something odd is going on there that needs an explanation.
>>>
>>> I already fully addressed that in my reply to you yesterday. P(P) has a
>>> dependency relationship on the return value of H(P,P) that the correctly
>>> emulated input to H(P,P) does not have. This changes their behavior
>>> relative to each other.
>>>
>> I can see an alternative explanation. I was going to say "it is
>> obvious" but
>> no-one else has stepped in to point it out. Maybe because it's too
>> obvious
>> and they want to give other posters a chance.
>
>
> The provably correct execution trace proves that the complete and
> correct x86 emulation of the input to H(P,P) by H would never reach the
> "ret" instruction (final state) of P, thus never halts. It is also
> proven that H does determine this in a finite number of states.
No, it doesn't because you don't seem to understand what correct x86
emulation MEANS.
Correct x86 emulation of a call instruction means the emulation now
continues at the x86 instruction at the target of the call, and thus the
correct x86 emualtion of the call H needs to be followed by the
emulation of the actual x86 assembly code of H. PERIOD.
What you are doing ISN'T x86 emulation at all, so all you are doing is
showing you are a liar.
Now, maybe part of the problem is that H isn't a halt decider and the
input 'P' isn't actually a description of the computation of P to be
decided on, so the 'behavior' of that input isn't the same as P(P) but
then you are just shown to be lying that you are working on the halting
problem and have defined H and P per the theorem you are claiming to be
working on.
Note, to actually define the input as a representation of the
computation P. it needs to include the x86 assembly of H as part of it,
so the fact that you say it doesn't just says your emulator is not
actually doing a correct emulation of its input at all.
>
> The provably correct execution trace of P(P) proves that the it halts.
>
> Because it is a fact that the actual input to H(P,P) has actual behavior
> that never halts then H must report on this behavior and cannot report
> on any other behavior.
>
Only if you define H to not do an accurate emulation of its input, or it
fails to return an answer.
> If you need to verify that you have a white dog in your living room
> checking for a black cat in you kitchen is the wrong criteria.
And that is the problem that YOU do. H needs to be EITHER a complete and
correct emulator, or a machine tha can abort its emulation to return an
answer when given a non-halting input.
YOU are the one looking at the black cat for what's happening when the
question is about the white dog.
Yea, the black cat, the H that does a complete emulation, creates a P
that is none-halting, but when the white dog looks at the P built on IT,
you are giving it the P built on the white cat instead, and thus get the
wrong answer.
>
> If you need to verify that an input to a halt decider reaches its final
> state it must be the actual behavior of this actual input. P(P) is
> provably not the actual behavior of the actual input on the basis of the
> ordinary semantics of the x86 language as shown in the two provably
> correct execution traces.
>
Right, and since that behavior is defined by a complete and correct
behavior, and a halt decider that aborts is simulation of its input
doesn't do that, you can't ask about the impossible case of what it does
with its input, because it isn't what is defined as the actual behavior.
If you try to define it that way, then you have LIED that P is corret,
because P MUST ask H about P(P), so if H(P,P) doesn't do that, P is
defined wrong.
If P can't ask H about P(P), then H is proved to be incomplete and
unable to give the correct answer to a question that it won't let you
answer.
>
>
> To fully understand this code a software engineer must be an expert in:
> the C programming language, the x86 programming language, exactly how C
> translates into x86 and the ability to recognize infinite recursion at
> the x86 assembly language level. No knowledge of the halting problem is
> required.
Nope, That is your problem, knowledge of the Halting Problem IS
required, because you need to make sure your terms are defined correctly.
You have proved that YOU don't have that knowledge, and you "proof" is
shown to be incorret.
>
> 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 of P.
>
Nope, not per the
> In computer science terminology this means that complete and correct
> emulation P by H would never reach its final state and halt.
You are missing, H never DOES a complete and correct emulation of its
input when it answers non-halting, and thus has no basis to say it is
correct. You have reached a paradox.
>
> The dependency relationship that P(P) has on H(P,P) causes its behavior
> to be quite different than the complete and correct x86 emulation of the
> input to H(P,P) that has no such dependency relationship.
Nope. the input to H(P,P) DOES have a dependency on the behavior of
H(P,P) since is uses that as part of its code.
All you are doing is admitting that you are not correctly emulating the
call H instruction, and thus fail.
>
> As shown below because P(P) depends on the return value of H(P,P) it has
> different behavior than the correctly emulated input to H(P,P).
>
> The correctly emulated input to H(P,P) remains stuck in recursive
> emulation that never gets to the point of receiving a return value from
> H, thus lacks the dependency of the executed P(P).
because you aren't CORRECTLY emulating the input as an x86 representation.
FAIL.
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> P(P);
> }
>
> _P()
> [000011f0](01) 55 push ebp
> [000011f1](02) 8bec mov ebp,esp
> [000011f3](03) 8b4508 mov eax,[ebp+08]
> [000011f6](01) 50 push eax
> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
> [000011fa](01) 51 push ecx
> [000011fb](05) e820feffff call 00001020
> [00001200](03) 83c408 add esp,+08
> [00001203](02) 85c0 test eax,eax
> [00001205](02) 7402 jz 00001209
> [00001207](02) ebfe jmp 00001207
> [00001209](01) 5d pop ebp
> [0000120a](01) c3 ret
> Size in bytes:(0027) [0000120a]
>
> _main()
> [00001210](01) 55 push ebp
> [00001211](02) 8bec mov ebp,esp
> [00001213](05) 68f0110000 push 000011f0
> [00001218](05) e8d3ffffff call 000011f0
> [0000121d](03) 83c404 add esp,+04
> [00001220](02) 33c0 xor eax,eax
> [00001222](01) 5d pop ebp
> [00001223](01) c3 ret
> Size in bytes:(0020) [00001223]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [00001210][00101fba][00000000] 55 push ebp
> [00001211][00101fba][00000000] 8bec mov ebp,esp
> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
> [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
> [000011f1][00101fae][00101fba] 8bec mov ebp,esp
> [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
> [000011f6][00101faa][000011f0] 50 push eax // push P
> [000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
> [000011fa][00101fa6][000011f0] 51 push ecx // push P
> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
>
> Begin Simulation Execution Trace Stored at:21206e
> Address_of_H:1020
> [000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
> [000011f1][0021205a][0021205e] 8bec mov ebp,esp
> [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
> [000011f6][00212056][000011f0] 50 push eax // push P
> [000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
> [000011fa][00212052][000011f0] 51 push ecx // push P
> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
> Infinitely Recursive Simulation Detected Simulation Stopped
>
> H knows its own machine address and on this basis it can easily
> examine its stored execution_trace of P (see above) to determine:
> (a) P is calling H with the same arguments that H was called with.
> (b) No instructions in P could possibly escape this otherwise infinitely
> recursive emulation.
> (c) H aborts its emulation of P before its call to H is emulated.
>
> [00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
> executed P
> [00001203][00101fae][00101fba] 85c0 test eax,eax
> [00001205][00101fae][00101fba] 7402 jz 00001209
> [00001209][00101fb2][0000121d] 5d pop ebp
> [0000120a][00101fb6][000011f0] c3 ret // return from
> executed P
> [0000121d][00101fba][00000000] 83c404 add esp,+04
> [00001220][00101fba][00000000] 33c0 xor eax,eax
> [00001222][00101fbe][00100000] 5d pop ebp
> [00001223][00101fc2][00000000] c3 ret // ret from main
> Number of Instructions Executed(878) / 67 = 13 pages
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-06-24 10:50 -0500 |
| Message-ID | <t94mff$8jv$1@dont-email.me> |
| In reply to | #52879 |
On 6/24/2022 8:34 AM, Malcolm McLean wrote: > On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote: >> On 6/24/2022 2:53 AM, Malcolm McLean wrote: >>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote: >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>> >>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>>> >>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote: >>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote: >>>>>>>>>>> >>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H >>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>>> DEFINITION of the behavior of H(P,P), >>>>>>>>>> Linz and others were aware that: A halt decider must compute the mapping >>>>>>>>>> from its inputs to an accept or reject state on the basis of the actual >>>>>>>>>> behavior that is actually specified by these inputs. >>>>>>>>>> Linz and others made the false assumption that the actual behavior that >>>>>>>>>> is actually specified by the inputs to a simulating halt decider is not >>>>>>>>>> the same as the direct execution of these inputs. They were unaware of >>>>>>>>>> this because no one previously fully examined a simulating halt decider >>>>>>>>>> ever before. >>>>>>>>>>> especially if that is what P calls >>>>>>>>>>> and P is claimed to be built by the Linz template. >>>>>>>>>>> >>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong. >>>>>>>>>> >>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H >>>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct. >>>>>>>>> >>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the >>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating >>>>>>>>> halt decider is not the same as the direct execution of these inputs"? >>>>>>>> >>>>>>>> That is an actual immutable verified fact. >>>>>>>> >>>>>>> That's your conclusion from your observations and reasoning. You've >>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>> reports "non-halting". You've run P(P), and it halts. So one >>>>>>> explanation is the one you've given but, as I said, that explanation >>>>>>> has rather far-reaching consequences. >>>>>> There is only one explanation. What you call the "dry-run" is not that >>>>>> same as the P(P). We've known this since the "line 15 commented out" >>>>>> days. There are two computations -- one that is not stopped and one >>>>>> that is, the "dry-run" and the run, the "simulation of the input to >>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide >>>>>> what's going on. >>>>>> >>>>> I'm a scientists, not a mathematician. >>>>> The example I always use is that you are doing an energy budget for tigers. >>>>> You work how much they use on running about, lactating, maintaining their >>>>> body temperature, and so on. >>>>> >>>>> Now let's say that you find that all results are within a few percentage points >>>>> of a similar budget done for lions. You'd instantly accept this data. >>>>> >>>>> Now let's say that the results are wildly different from a previous budget done >>>>> for lions. You wouldn't just accept that data. You'd check. You'd want to >>>>> understand the reasons tigers spend far less energy on movement than lions. >>>>> >>>>> Now let's say that the result show that tigers use more energy than they >>>>> take in food. Would you instantly conclude that the law of conservation of >>>>> energy must be incorrect? >>>>> >>>>> The third is what PO is doing. >>>> I have no idea what parts of this analogy map to the current situation. >>>> PO has no contradictory results about anything. There's no conflict >>>> with any established facts in anything he is doing. >>>> >>> 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. >>> >>> So something odd is going on there that needs an explanation. >> >> I already fully addressed that in my reply to you yesterday. P(P) has a >> dependency relationship on the return value of H(P,P) that the correctly >> emulated input to H(P,P) does not have. This changes their behavior >> relative to each other. >> > I can see an alternative explanation. I was going to say "it is obvious" but > no-one else has stepped in to point it out. Maybe because it's too obvious > and they want to give other posters a chance. To what exact extent do you have this mandatory prerequisite knowledge? To fully understand this code a software engineer must be an expert in: the C programming language, the x86 programming language, exactly how C translates into x86 and the ability to recognize infinite recursion at the x86 assembly language level. 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 of P. The halt decider and its input are written in C compiled with a Microsoft C compiler that generates a standard COFF object file. This file is the input to the x86utm operating system that runs on both Microsoft Windows and Linux. -- 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 09:09 -0700 |
| Message-ID | <bab8ec9f-5d54-4399-bd07-58fdc239d783n@googlegroups.com> |
| In reply to | #52885 |
On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote: > On 6/24/2022 8:34 AM, Malcolm McLean wrote: > > On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote: > >> On 6/24/2022 2:53 AM, Malcolm McLean wrote: > >>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote: > >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >>>> > >>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: > >>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >>>>>> > >>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: > >>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote: > >>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: > >>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote: > >>>>>>>>>>> > >>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H > >>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the > >>>>>>>>>>> DEFINITION of the behavior of H(P,P), > >>>>>>>>>> Linz and others were aware that: A halt decider must compute the mapping > >>>>>>>>>> from its inputs to an accept or reject state on the basis of the actual > >>>>>>>>>> behavior that is actually specified by these inputs. > >>>>>>>>>> Linz and others made the false assumption that the actual behavior that > >>>>>>>>>> is actually specified by the inputs to a simulating halt decider is not > >>>>>>>>>> the same as the direct execution of these inputs. They were unaware of > >>>>>>>>>> this because no one previously fully examined a simulating halt decider > >>>>>>>>>> ever before. > >>>>>>>>>>> especially if that is what P calls > >>>>>>>>>>> and P is claimed to be built by the Linz template. > >>>>>>>>>>> > >>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong. > >>>>>>>>>> > >>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H > >>>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct. > >>>>>>>>> > >>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the > >>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating > >>>>>>>>> halt decider is not the same as the direct execution of these inputs"? > >>>>>>>> > >>>>>>>> That is an actual immutable verified fact. > >>>>>>>> > >>>>>>> That's your conclusion from your observations and reasoning. You've > >>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it > >>>>>>> reports "non-halting". You've run P(P), and it halts. So one > >>>>>>> explanation is the one you've given but, as I said, that explanation > >>>>>>> has rather far-reaching consequences. > >>>>>> There is only one explanation. What you call the "dry-run" is not that > >>>>>> same as the P(P). We've known this since the "line 15 commented out" > >>>>>> days. There are two computations -- one that is not stopped and one > >>>>>> that is, the "dry-run" and the run, the "simulation of the input to > >>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide > >>>>>> what's going on. > >>>>>> > >>>>> I'm a scientists, not a mathematician. > >>>>> The example I always use is that you are doing an energy budget for tigers. > >>>>> You work how much they use on running about, lactating, maintaining their > >>>>> body temperature, and so on. > >>>>> > >>>>> Now let's say that you find that all results are within a few percentage points > >>>>> of a similar budget done for lions. You'd instantly accept this data. > >>>>> > >>>>> Now let's say that the results are wildly different from a previous budget done > >>>>> for lions. You wouldn't just accept that data. You'd check. You'd want to > >>>>> understand the reasons tigers spend far less energy on movement than lions. > >>>>> > >>>>> Now let's say that the result show that tigers use more energy than they > >>>>> take in food. Would you instantly conclude that the law of conservation of > >>>>> energy must be incorrect? > >>>>> > >>>>> The third is what PO is doing. > >>>> I have no idea what parts of this analogy map to the current situation. > >>>> PO has no contradictory results about anything. There's no conflict > >>>> with any established facts in anything he is doing. > >>>> > >>> 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. > >>> > >>> So something odd is going on there that needs an explanation. > >> > >> I already fully addressed that in my reply to you yesterday. P(P) has a > >> dependency relationship on the return value of H(P,P) that the correctly > >> emulated input to H(P,P) does not have. This changes their behavior > >> relative to each other. > >> > > I can see an alternative explanation. I was going to say "it is obvious" but > > no-one else has stepped in to point it out. Maybe because it's too obvious > > and they want to give other posters a chance. > To what exact extent do you have this mandatory prerequisite knowledge? > To fully understand this code a software engineer must be an expert in: > the C programming language, the x86 programming language, exactly how C > translates into x86 and the ability to recognize infinite recursion at > the x86 assembly language level. > 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 of P. > The halt decider and its input are written in C compiled with a > Microsoft C compiler that generates a standard COFF object file. This > file is the input to the x86utm operating system that runs on both > Microsoft Windows and Linux. > I'm a C programmer and I have done machine code programming, though not with the x86 chip. But I'd dispute your requirements. To re-tread the analogy, our measurements show that tigers use more energy than they take in. Now you could construct an very complicated explanation for that using advanced quantum mechanics and other concepts. And you do need to have a rudimentary understanding of physics to see where the difficulty lies. But you don't need more than the rudimentary understanding to suggest the alternative explanation, and to realise that it is overwhelmingly more likely.
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.theory
csiph-web