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 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-24 11:32 -0500 |
| Message-ID | <ePednUX7feSMeij_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52887 |
On 6/24/2022 11:09 AM, Malcolm McLean wrote: > 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. THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS DISAGREEMENT IS INHERENTLY INCORRECT. From a purely software engineering perspective H is correctly defined to correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction of this input and it is proven that H does do this correctly in a finite number of steps. > 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. It seems that you may be saying that it is OK to disbelieve verified facts some of the time. I vehemently disagree and this position could cause both the end of Democracy in the USA and the extinction of humanity in the world through lack of climate change action. Ordinary software engineering conclusively proves that all of my claims that I just stated are easily verified as factually correct. Anyone that disagrees with claims that are verified as factually correct is either insufficiently technically competent or less than totally honest. Someone that refuses to acknowledge that claims are correct when they know that these claims are correct is less than totally honest. I believe that you are as honest as you can be and the issue is that you have a lack of sufficient understanding. -- 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:46 -0400 |
| Message-ID | <5UltK.132528$ntj.54082@fx15.iad> |
| In reply to | #52889 |
On 6/24/22 12:32 PM, olcott wrote: > On 6/24/2022 11:09 AM, Malcolm McLean wrote: >> 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. > > > THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS > DISAGREEMENT IS INHERENTLY INCORRECT. > > From a purely software engineering perspective H is correctly defined > to correctly determine that its correct and complete x86 emulation of > its input would never reach the "ret" instruction of this input and it > is proven that H does do this correctly in a finite number of steps. YOU CAN'T "STIPULATE" correctness. ARGUEMENT FATALLY FLAWED. > >> 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. > > It seems that you may be saying that it is OK to disbelieve verified > facts some of the time. I vehemently disagree and this position could > cause both the end of Democracy in the USA and the extinction of > humanity in the world through lack of climate change action. > > Ordinary software engineering conclusively proves that all of my claims > that I just stated are easily verified as factually correct. > > Anyone that disagrees with claims that are verified as factually correct > is either insufficiently technically competent or less than totally > honest. Someone that refuses to acknowledge that claims are correct when > they know that these claims are correct is less than totally honest. > > I believe that you are as honest as you can be and the issue is that you > have a lack of sufficient understanding. >
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-24 11:52 -0500 |
| Message-ID | <nfKdncxZra16dij_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52889 |
On 6/24/2022 11:32 AM, olcott wrote: > On 6/24/2022 11:09 AM, Malcolm McLean wrote: >> 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. > > > THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS > DISAGREEMENT IS INHERENTLY INCORRECT. > > From a purely software engineering perspective H is correctly defined > to correctly determine that its correct and complete x86 emulation of > its input would never reach the "ret" instruction of this input and it > is proven that H does do this correctly in a finite number of steps. > THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS DISAGREEMENT IS INHERENTLY INCORRECT. From a purely software engineering perspective H(P,P) is required to to correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction of this input and H must do this in a finite number of steps. It is proven that H does meet this requirement. >> 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. > > It seems that you may be saying that it is OK to disbelieve verified > facts some of the time. I vehemently disagree and this position could > cause both the end of Democracy in the USA and the extinction of > humanity in the world through lack of climate change action. > > Ordinary software engineering conclusively proves that all of my claims > that I just stated are easily verified as factually correct. > > Anyone that disagrees with claims that are verified as factually correct > is either insufficiently technically competent or less than totally > honest. Someone that refuses to acknowledge that claims are correct when > they know that these claims are correct is less than totally honest. > > I believe that you are as honest as you can be and the issue is that you > have a lack of sufficient understanding. > -- 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 15:55 -0400 |
| Message-ID | <9FotK.137484$ntj.95074@fx15.iad> |
| In reply to | #52892 |
On 6/24/22 12:52 PM, olcott wrote: > On 6/24/2022 11:32 AM, olcott wrote: >> On 6/24/2022 11:09 AM, Malcolm McLean wrote: >>> 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. >> >> >> THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS >> DISAGREEMENT IS INHERENTLY INCORRECT. >> >> Â From a purely software engineering perspective H is correctly defined >> to correctly determine that its correct and complete x86 emulation of >> its input would never reach the "ret" instruction of this input and it >> is proven that H does do this correctly in a finite number of steps. >> > > THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS > DISAGREEMENT IS INHERENTLY INCORRECT. STIPULTING that something is correct is inherently incorrect. > > From a purely software engineering perspective H(P,P) is required to > to correctly determine that its correct and complete x86 emulation of > its input would never reach the "ret" instruction of this input and H > must do this in a finite number of steps. > > It is proven that H does meet this requirement. No, because you said *ITS* correct and complete x86 emulation was showing something when it didn't do one. Thus, H has FAILED to meet its requirements. Until you can show how H can do a COMPLETE emulation of a non-halting input in finite time (not just 'prove' that it doesn't halt, that wasn't the requrement, it was DO the emulation) your H just fails to meet you software specifications for it. Note, a Halt Decider isn't normally required to do a complete emulation of its input, but that is because it isn't also the test of its answer being correct, that is done by the INDEPENDENT running or complete emulation of the input, which allow the decider to correct answer at least some non-halting inputs. (Because it can find patterns that are proven to be non-halting for the test machine). Your removal of the allowance of a separate test operation, that CAN be infinite in operation while the decider stays finite in operation dooms your decider to either not meet its requriment to show non-halting, or not meet its requirement to answer in finite time. Note, your H fails to meet YOUR requirements when deciding on Infinite_Loop, even though it can give the correct answer by the normal requirements, because it never showed by its own complete and correct emulation that the input doesn't halt (only by referencing another emulation that does, which isn't YOUR stated requirement). > > >>> 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. >> >> It seems that you may be saying that it is OK to disbelieve verified >> facts some of the time. I vehemently disagree and this position could >> cause both the end of Democracy in the USA and the extinction of >> humanity in the world through lack of climate change action. >> >> Ordinary software engineering conclusively proves that all of my >> claims that I just stated are easily verified as factually correct. >> >> Anyone that disagrees with claims that are verified as factually >> correct is either insufficiently technically competent or less than >> totally honest. Someone that refuses to acknowledge that claims are >> correct when they know that these claims are correct is less than >> totally honest. >> >> I believe that you are as honest as you can be and the issue is that >> you have a lack of sufficient understanding. >> > >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-06-24 10:29 -0700 |
| Message-ID | <8e402d70-748a-4dcb-a6ae-809d4d352b87n@googlegroups.com> |
| In reply to | #52889 |
On Friday, 24 June 2022 at 17:32:24 UTC+1, olcott wrote:
> On 6/24/2022 11:09 AM, Malcolm McLean wrote:
> > 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.
> THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
> DISAGREEMENT IS INHERENTLY INCORRECT.
>
> From a purely software engineering perspective H is correctly defined
> to correctly determine that its correct and complete x86 emulation of
> its input would never reach the "ret" instruction of this input and it
> is proven that H does do this correctly in a finite number of steps.
> > 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.
> It seems that you may be saying that it is OK to disbelieve verified
> facts some of the time. I vehemently disagree and this position could
> cause both the end of Democracy in the USA and the extinction of
> humanity in the world through lack of climate change action.
>
> Ordinary software engineering conclusively proves that all of my claims
> that I just stated are easily verified as factually correct.
>
> Anyone that disagrees with claims that are verified as factually correct
> is either insufficiently technically competent or less than totally
> honest. Someone that refuses to acknowledge that claims are correct when
> they know that these claims are correct is less than totally honest.
>
Let's say we do our measurements on tigers. They come back
average calorie intake (prey) 2000 calories.
average outgoings
stored fat 100 calories
metabolism (body temperature) 1500 calories
movement 500 calories
lactation 200 calories.
these are averaged over a long period.
Now what is your conclusion?
>
> I believe that you are as honest as you can be and the issue is that you
> have a lack of sufficient understanding.
>
See if you can work out the tiger example first.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-24 12:42 -0500 |
| Message-ID | <s7CdnU0jlegYaij_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52893 |
On 6/24/2022 12:29 PM, Malcolm McLean wrote: > On Friday, 24 June 2022 at 17:32:24 UTC+1, olcott wrote: >> On 6/24/2022 11:09 AM, Malcolm McLean wrote: >>> 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. >> THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS >> DISAGREEMENT IS INHERENTLY INCORRECT. >> >> From a purely software engineering perspective H is correctly defined >> to correctly determine that its correct and complete x86 emulation of >> its input would never reach the "ret" instruction of this input and it >> is proven that H does do this correctly in a finite number of steps. >>> 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. >> It seems that you may be saying that it is OK to disbelieve verified >> facts some of the time. I vehemently disagree and this position could >> cause both the end of Democracy in the USA and the extinction of >> humanity in the world through lack of climate change action. >> >> Ordinary software engineering conclusively proves that all of my claims >> that I just stated are easily verified as factually correct. >> >> Anyone that disagrees with claims that are verified as factually correct >> is either insufficiently technically competent or less than totally >> honest. Someone that refuses to acknowledge that claims are correct when >> they know that these claims are correct is less than totally honest. >> > Let's say we do our measurements on tigers. They come back > average calorie intake (prey) 2000 calories. > average outgoings > stored fat 100 calories > metabolism (body temperature) 1500 calories > movement 500 calories > lactation 200 calories. > > these are averaged over a long period. > > Now what is your conclusion? The measurements are inaccurate as can occur with all empirical science that relies on physical observation. It is also the case the all empirical science utterly relies on a possibly false fundamental assumption that is discussed at length as the problem of induction. https://en.wikipedia.org/wiki/Problem_of_induction On the other hand when we look at the analytic side of the analytic / synthetic distinction: https://en.wikipedia.org/wiki/Analytic%E2%80%93synthetic_distinction We can verify that an expression of language is totally true entirely on the basis of its meaning. This proves that your analogy is not apt. From a purely software engineering perspective H(P,P) is required to to correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction of this input and H must do this in a finite number of steps. The ordinary semantics of standard C and the conventional x86 language are the entire semantics required to conclusively prove that H(P,P) does correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction (final state) of this input thus never halts. >> >> I believe that you are as honest as you can be and the issue is that you >> have a lack of sufficient understanding. >> > See if you can work out the tiger example first. -- 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 12:34 -0700 |
| Message-ID | <a1276375-15c7-4fe0-b66b-5787c9666d86n@googlegroups.com> |
| In reply to | #52894 |
On Friday, 24 June 2022 at 18:42:36 UTC+1, olcott wrote: > On 6/24/2022 12:29 PM, Malcolm McLean wrote: > > On Friday, 24 June 2022 at 17:32:24 UTC+1, olcott wrote: > >> On 6/24/2022 11:09 AM, Malcolm McLean wrote: > >>> 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. > >> THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS > >> DISAGREEMENT IS INHERENTLY INCORRECT. > >> > >> From a purely software engineering perspective H is correctly defined > >> to correctly determine that its correct and complete x86 emulation of > >> its input would never reach the "ret" instruction of this input and it > >> is proven that H does do this correctly in a finite number of steps. > >>> 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. > >> It seems that you may be saying that it is OK to disbelieve verified > >> facts some of the time. I vehemently disagree and this position could > >> cause both the end of Democracy in the USA and the extinction of > >> humanity in the world through lack of climate change action. > >> > >> Ordinary software engineering conclusively proves that all of my claims > >> that I just stated are easily verified as factually correct. > >> > >> Anyone that disagrees with claims that are verified as factually correct > >> is either insufficiently technically competent or less than totally > >> honest. Someone that refuses to acknowledge that claims are correct when > >> they know that these claims are correct is less than totally honest. > >> > > Let's say we do our measurements on tigers. They come back > > average calorie intake (prey) 2000 calories. > > average outgoings > > stored fat 100 calories > > metabolism (body temperature) 1500 calories > > movement 500 calories > > lactation 200 calories. > > > > these are averaged over a long period. > > > > Now what is your conclusion? > The measurements are inaccurate as can occur with all empirical science > that relies on physical observation. It is also the case the all > empirical science utterly relies on a possibly false fundamental > assumption that is discussed at length as the problem of induction. > https://en.wikipedia.org/wiki/Problem_of_induction > Exactly. You've got it. Either the measurements are inaccurate, or the theory that energy is conserved is wrong. > On the other hand when we look at the analytic side of the analytic / > synthetic distinction: > https://en.wikipedia.org/wiki/Analytic%E2%80%93synthetic_distinction > > We can verify that an expression of language is totally true entirely on > the basis of its meaning. This proves that your analogy is not apt. > I'm not sure about this. > > From a purely software engineering perspective H(P,P) is required to to > correctly determine that its correct and complete x86 emulation of its > input would never reach the "ret" instruction of this input and H must > do this in a finite number of steps. > The ordinary semantics of standard C and the conventional x86 language > are the entire semantics required to conclusively prove that H(P,P) does > correctly determine that its correct and complete x86 emulation of its > input would never reach the "ret" instruction (final state) of this > input thus never halts. > So you've dry-run P(P) and determined that it doesn't halt. Just as our hypothetical ecologists measured the tigers' energy budget. What is the obvious conclusion? > > >> I believe that you are as honest as you can be and the issue is that you > >> have a lack of sufficient understanding. > >> > > See if you can work out the tiger example first. >
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-24 15:20 -0500 |
| Message-ID | <vJidnck_EtDogSv_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52897 |
On 6/24/2022 2:34 PM, Malcolm McLean wrote: > On Friday, 24 June 2022 at 18:42:36 UTC+1, olcott wrote: >> On 6/24/2022 12:29 PM, Malcolm McLean wrote: >>> On Friday, 24 June 2022 at 17:32:24 UTC+1, olcott wrote: >>>> On 6/24/2022 11:09 AM, Malcolm McLean wrote: >>>>> 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. >>>> THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS >>>> DISAGREEMENT IS INHERENTLY INCORRECT. >>>> >>>> From a purely software engineering perspective H is correctly defined >>>> to correctly determine that its correct and complete x86 emulation of >>>> its input would never reach the "ret" instruction of this input and it >>>> is proven that H does do this correctly in a finite number of steps. >>>>> 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. >>>> It seems that you may be saying that it is OK to disbelieve verified >>>> facts some of the time. I vehemently disagree and this position could >>>> cause both the end of Democracy in the USA and the extinction of >>>> humanity in the world through lack of climate change action. >>>> >>>> Ordinary software engineering conclusively proves that all of my claims >>>> that I just stated are easily verified as factually correct. >>>> >>>> Anyone that disagrees with claims that are verified as factually correct >>>> is either insufficiently technically competent or less than totally >>>> honest. Someone that refuses to acknowledge that claims are correct when >>>> they know that these claims are correct is less than totally honest. >>>> >>> Let's say we do our measurements on tigers. They come back >>> average calorie intake (prey) 2000 calories. >>> average outgoings >>> stored fat 100 calories >>> metabolism (body temperature) 1500 calories >>> movement 500 calories >>> lactation 200 calories. >>> >>> these are averaged over a long period. >>> >>> Now what is your conclusion? >> The measurements are inaccurate as can occur with all empirical science >> that relies on physical observation. It is also the case the all >> empirical science utterly relies on a possibly false fundamental >> assumption that is discussed at length as the problem of induction. >> https://en.wikipedia.org/wiki/Problem_of_induction >> > Exactly. You've got it. Either the measurements are inaccurate, or the > theory that energy is conserved is wrong. >> On the other hand when we look at the analytic side of the analytic / >> synthetic distinction: >> https://en.wikipedia.org/wiki/Analytic%E2%80%93synthetic_distinction >> >> We can verify that an expression of language is totally true entirely on >> the basis of its meaning. This proves that your analogy is not apt. >> > I'm not sure about this. >> >> From a purely software engineering perspective H(P,P) is required to to >> correctly determine that its correct and complete x86 emulation of its >> input would never reach the "ret" instruction of this input and H must >> do this in a finite number of steps. >> The ordinary semantics of standard C and the conventional x86 language >> are the entire semantics required to conclusively prove that H(P,P) does >> correctly determine that its correct and complete x86 emulation of its >> input would never reach the "ret" instruction (final state) of this >> input thus never halts. >> > So you've dry-run P(P) and determined that it doesn't halt. Just as our > hypothetical ecologists measured the tigers' energy budget. > What is the obvious conclusion? From a purely software engineering perspective H(P,P) is required to to correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction of this input and H must do this in a finite number of steps. The ordinary semantics of standard C and the conventional x86 language are the entire semantics required to conclusively prove that H(P,P) does correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction (final state) of this input thus never halts. THERE IS NO POSSIBLE WAY AROUND THIS. >> >>>> I believe that you are as honest as you can be and the issue is that you >>>> have a lack of sufficient understanding. >>>> >>> See if you can work out the tiger example first. >> -- 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 16:00 -0400 |
| Message-ID | <iJotK.137485$ntj.16746@fx15.iad> |
| In reply to | #52894 |
On 6/24/22 1:42 PM, olcott wrote: > On 6/24/2022 12:29 PM, Malcolm McLean wrote: >> On Friday, 24 June 2022 at 17:32:24 UTC+1, olcott wrote: >>> On 6/24/2022 11:09 AM, Malcolm McLean wrote: >>>> 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. >>> THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS >>> DISAGREEMENT IS INHERENTLY INCORRECT. >>> >>>  From a purely software engineering perspective H is correctly defined >>> to correctly determine that its correct and complete x86 emulation of >>> its input would never reach the "ret" instruction of this input and it >>> is proven that H does do this correctly in a finite number of steps. >>>> 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. >>> It seems that you may be saying that it is OK to disbelieve verified >>> facts some of the time. I vehemently disagree and this position could >>> cause both the end of Democracy in the USA and the extinction of >>> humanity in the world through lack of climate change action. >>> >>> Ordinary software engineering conclusively proves that all of my claims >>> that I just stated are easily verified as factually correct. >>> >>> Anyone that disagrees with claims that are verified as factually correct >>> is either insufficiently technically competent or less than totally >>> honest. Someone that refuses to acknowledge that claims are correct when >>> they know that these claims are correct is less than totally honest. >>> >> Let's say we do our measurements on tigers. They come back >> average calorie intake (prey) 2000 calories. >> average outgoings >>           stored fat 100 calories >>           metabolism (body temperature) 1500 calories >>           movement 500 calories >>           lactation   200 calories. >> >> these are averaged over a long period. >> >> Now what is your conclusion? > > The measurements are inaccurate as can occur with all empirical science > that relies on physical observation. It is also the case the all > empirical science utterly relies on a possibly false fundamental > assumption that is discussed at length as the problem of induction. > https://en.wikipedia.org/wiki/Problem_of_induction > > On the other hand when we look at the analytic side of the analytic / > synthetic distinction: > https://en.wikipedia.org/wiki/Analytic%E2%80%93synthetic_distinction > > We can verify that an expression of language is totally true entirely on > the basis of its meaning. This proves that your analogy is not apt. > > From a purely software engineering perspective H(P,P) is required to to > correctly determine that its correct and complete x86 emulation of its > input would never reach the "ret" instruction of this input and H must > do this in a finite number of steps. > > The ordinary semantics of standard C and the conventional x86 language > are the entire semantics required to conclusively prove that H(P,P) does > correctly determine that its correct and complete x86 emulation of its > input would never reach the "ret" instruction (final state) of this > input thus never halts. > > >>> >>> I believe that you are as honest as you can be and the issue is that you >>> have a lack of sufficient understanding. >>> >> See if you can work out the tiger example first. > > And your fundamental problem is that Halting is defined based on MACHINES, i.e the actual computation itself. "Inputs" are just strings of symbols and don't have any behavior by them selves. If H(P.P) doesn't represent the computation P(P), then you haven't designed you P by the rules, so your arguement is invalid. If P CAN'T ask H about P(P), then your H just admitted defeat. Since H(P,P) doesn't match the bahavior of P(P), either H is just wrong, or your problem doesn't match the required setup and you are proved to be either a liar or incompetent. Take your choice on how you want to be wrong.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-06-24 20:42 +0100 |
| Message-ID | <878rplyhj6.fsf@bsb.me.uk> |
| In reply to | #52874 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > 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. Then I don't know what you mean by "dry-run" and what needs an explanation (for me) is your description of what he's doing. Nothing in what PO is doing needs to be explained as far as I can see. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-06-24 13:25 -0700 |
| Message-ID | <b6163094-01b0-4bb4-a3b1-4e48457527a0n@googlegroups.com> |
| In reply to | #52898 |
On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > 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. > Then I don't know what you mean by "dry-run" and what needs an > explanation (for me) is your description of what he's doing. Nothing in > what PO is doing needs to be explained as far as I can see. > "Dry run" means that a human programmer looks at the code, and determines what it does, without actually executing it. It's a very important technique, because it's not always practical or even possible to run a debugger. Even where a debugger is available, often dry-running will reveal bugs in a fraction of the time. In this case, PO has dry run P(P). That is, he has looked at the source, and worked out what it will do. Which is to run an infinite sequence of nested emulations. So it won't halt. H(P,P) also reports "non-halting". So this is powerful evidence that H is correct. However when he actually executes P(P) on hardware, it terminates. Something isn't right. PO's explanation is that P(P) has different correct behaviour when run and when emulated by H. I can think of an obvious alternative explanation which is much simpler and much less far-reaching in its implications. However despite a lot of coaxing, no-one else seems to have arrived at it.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-24 15:35 -0500 |
| Message-ID | <bYSdnbm5OKWcvSv_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52905 |
On 6/24/2022 3:25 PM, Malcolm McLean wrote: > On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >>> 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. >> Then I don't know what you mean by "dry-run" and what needs an >> explanation (for me) is your description of what he's doing. Nothing in >> what PO is doing needs to be explained as far as I can see. >> > "Dry run" means that a human programmer looks at the code, and determines > what it does, without actually executing it. > It's a very important technique, because it's not always practical or even > possible to run a debugger. Even where a debugger is available, often > dry-running will reveal bugs in a fraction of the time. > In this case, PO has dry run P(P). That is, he has looked at the source, and > worked out what it will do. Which is to run an infinite sequence of nested > emulations. So it won't halt. H(P,P) also reports "non-halting". So this is > powerful evidence that H is correct. Great! > However when he actually executes P(P) on hardware, it terminates. > Something isn't right. None-the-less when everyone in the entire universe disagrees with a verified fact then they are all necessarily incorrect. The ordinary semantics of standard C and the conventional x86 language are the entire semantics required to conclusively prove that H(P,P) does correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction (final state) of this input thus never halts. > PO's explanation is that P(P) has different correct behaviour when run and > when emulated by H. It is very easily proven as an established fact that the correctly emulated input to H(P,P) would never halt and P(P) halts. > I can think of an obvious alternative explanation which is much simpler and > much less far-reaching in its implications. However despite a lot of coaxing, > no-one else seems to have arrived at it. I think that most of my reviewers are only interested in rebuttal at the expense of an actual honest dialogue. You are certainly the exception to this. -- 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 16:59 -0400 |
| Message-ID | <tAptK.352007$zgr9.264390@fx13.iad> |
| In reply to | #52908 |
On 6/24/22 4:35 PM, olcott wrote: > On 6/24/2022 3:25 PM, Malcolm McLean wrote: >> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote: >>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>> >>>> 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. >>> Then I don't know what you mean by "dry-run" and what needs an >>> explanation (for me) is your description of what he's doing. Nothing in >>> what PO is doing needs to be explained as far as I can see. >>> >> "Dry run" means that a human programmer looks at the code, and determines >> what it does, without actually executing it. >> It's a very important technique, because it's not always practical or >> even >> possible to run a debugger. Even where a debugger is available, often >> dry-running will reveal bugs in a fraction of the time. >> In this case, PO has dry run P(P). That is, he has looked at the >> source, and >> worked out what it will do. Which is to run an infinite sequence of >> nested >> emulations. So it won't halt. H(P,P) also reports "non-halting". So >> this is >> powerful evidence that H is correct. > > Great! > Except, of course, that the "Dry-run" didn't evalute H as what H actually ends up being, but by what H was specifed to be, that is a comptation that completely em >> However when he actually executes P(P) on hardware, it terminates. >> Something isn't right. > > None-the-less when everyone in the entire universe disagrees with a > verified fact then they are all necessarily incorrect. > > The ordinary semantics of standard C and the conventional x86 language > are the entire semantics required to conclusively prove that H(P,P) does > correctly determine that its correct and complete x86 emulation of its > input would never reach the "ret" instruction (final state) of this > input thus never halts. > >> PO's explanation is that P(P) has different correct behaviour when run >> and >> when emulated by H. > > It is very easily proven as an established fact that the correctly > emulated input to H(P,P) would never halt and P(P) halts. Only if you accept that P isn't requred to be the H^ of Linz. Remember, THAT machine, by definition, makes a call that asks H to evalute what it will do when applie to its input. If H(P,P) doesn't mean that, then P isn't the impossible program example of Linz but something else, so we haven't countered his example. > >> I can think of an obvious alternative explanation which is much >> simpler and >> much less far-reaching in its implications. However despite a lot of >> coaxing, >> no-one else seems to have arrived at it. > > I think that most of my reviewers are only interested in rebuttal at the > expense of an actual honest dialogue. You are certainly the exception to > this. >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-06-24 23:16 +0100 |
| Message-ID | <87fsjtwvut.fsf@bsb.me.uk> |
| In reply to | #52905 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >> > 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. >> Then I don't know what you mean by "dry-run" and what needs an >> explanation (for me) is your description of what he's doing. Nothing in >> what PO is doing needs to be explained as far as I can see. >> > "Dry run" means that a human programmer looks at the code, and determines > what it does, without actually executing it. OK. So what value does it have in this case? Do you think PO is competent to "dry run" any code at all? Going back, now, to what you think needs to be resolved: | He's dry-run P(P) and established that it doesn't halt. He's invoked H | on it and H reports that it doesn't halt. He's run P(P) and it halts. The obvious conclusion is that PO's dry run (if he has indeed done such a thing) is incorrect. Anyone who eyeballs some case and concludes that it does not do what it down when actually run has just made a mistake. Do you think it's interesting to find out what mistake PO has made when guessing what the code does? If so have fun trying to get the code from him... The more interesting (at least at one time) is fact that H is not correct since, by definition, H(X,Y) should report on the "halting" of the call X(Y). > It's a very important technique, because it's not always practical or even > possible to run a debugger. Even where a debugger is available, often > dry-running will reveal bugs in a fraction of the time. In this case, we have the undisputed fact that P(P) halts, so there's really no value in a "dry run" from a debugging perspective. > In this case, PO has dry run P(P). And, if that is indeed what he's done (and I don't think it is) he knows he's made some mistake in his "dry run". > That is, he has looked at the source, and > worked out what it will do. But, I hope you agree, he's made some mistake or he's been lying when re reports that P(P) halts. > Which is to run an infinite sequence of nested > emulations. So it won't halt. The execution of P(P) does not represent an infinite sequence of nested simulations. We know that because P(P) halts. > H(P,P) also reports "non-halting". So this is > powerful evidence that H is correct. Eh? How is some code eyeballing more compelling evidence than the 100% undisputed fact that P(P) halts? How is the opinion of someone who can't write a parity checking TM powerful evidence of anything? > However when he actually executes P(P) on hardware, it terminates. > Something isn't right. Yes. > PO's explanation is that P(P) has different correct behaviour when run and > when emulated by H. That can't be an explanation of anything because, according to you, he is wrong about the dry run of P(P) and an actual run of P(P). Both the dry run and the actual run must take account of the fact that H is (partially) emulating P(P). > I can think of an obvious alternative explanation which is much > simpler and much less far-reaching in its implications. However > despite a lot of coaxing, no-one else seems to have arrived at it. There is nothing here with any far-reaching implications and since I've never shared your explanation, I'm not going to look for an alternative. I don't think he's done a "dry run" at all. He knows P(P) halts so he's relying on sophistry. H "aborts" so P never reaches its "ret" instruction. That's why P(P) and "the simulation of the inputs to H(P,P)" are different. 18 years of work for what? An H that, on the basis of his own words, obviously gets the wrong answer. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-24 17:25 -0500 |
| Message-ID | <sq-dnVRwmaVtpCv_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52914 |
On 6/24/2022 5:16 PM, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote: >>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>> >>>> 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. >>> Then I don't know what you mean by "dry-run" and what needs an >>> explanation (for me) is your description of what he's doing. Nothing in >>> what PO is doing needs to be explained as far as I can see. >>> >> "Dry run" means that a human programmer looks at the code, and determines >> what it does, without actually executing it. > > OK. So what value does it have in this case? Do you think PO is > competent to "dry run" any code at all? > > Going back, now, to what you think needs to be resolved: > > | He's dry-run P(P) and established that it doesn't halt. He's invoked H > | on it and H reports that it doesn't halt. He's run P(P) and it halts. > > The obvious conclusion is that PO's dry run (if he has indeed done such > a thing) is incorrect. Anyone who eyeballs some case and concludes that > it does not do what it down when actually run has just made a mistake. > Do you think it's interesting to find out what mistake PO has made when > guessing what the code does? If so have fun trying to get the code from > him... > > The more interesting (at least at one time) is fact that H is not > correct since, by definition, H(X,Y) should report on the "halting" of > the call X(Y). > >> It's a very important technique, because it's not always practical or even >> possible to run a debugger. Even where a debugger is available, often >> dry-running will reveal bugs in a fraction of the time. > > In this case, we have the undisputed fact that P(P) halts, so there's > really no value in a "dry run" from a debugging perspective. > >> In this case, PO has dry run P(P). > > And, if that is indeed what he's done (and I don't think it is) he knows > he's made some mistake in his "dry run". > >> That is, he has looked at the source, and >> worked out what it will do. > > But, I hope you agree, he's made some mistake or he's been lying when re > reports that P(P) halts. > >> Which is to run an infinite sequence of nested >> emulations. So it won't halt. > > The execution of P(P) does not represent an infinite sequence of nested > simulations. We know that because P(P) halts. > >> H(P,P) also reports "non-halting". So this is >> powerful evidence that H is correct. > > Eh? How is some code eyeballing more compelling evidence than the 100% > undisputed fact that P(P) halts? How is the opinion of someone who > can't write a parity checking TM powerful evidence of anything? > >> However when he actually executes P(P) on hardware, it terminates. >> Something isn't right. > > Yes. > >> PO's explanation is that P(P) has different correct behaviour when run and >> when emulated by H. > > That can't be an explanation of anything because, according to you, he > is wrong about the dry run of P(P) and an actual run of P(P). Both the > dry run and the actual run must take account of the fact that H is > (partially) emulating P(P). > >> I can think of an obvious alternative explanation which is much >> simpler and much less far-reaching in its implications. However >> despite a lot of coaxing, no-one else seems to have arrived at it. > > There is nothing here with any far-reaching implications and since I've > never shared your explanation, I'm not going to look for an alternative. > > I don't think he's done a "dry run" at all. He knows P(P) halts so he's > relying on sophistry. H "aborts" so P never reaches its "ret" > instruction. That's why P(P) and "the simulation of the inputs to > H(P,P)" are different. 18 years of work for what? An H that, on the > basis of his own words, obviously gets the wrong answer. > The ordinary semantics of standard C and the conventional x86 language are the entire semantics required to conclusively prove that H(P,P) does correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction (final state) of this input thus never halts. That your understanding of the semantics of the x86 language is insufficient to directly confirm this is less than no rebuttal at all. -- 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 | "dklei...@gmail.com" <dkleinecke@gmail.com> |
|---|---|
| Date | 2022-06-24 16:58 -0700 |
| Message-ID | <d4d1011f-c7d4-4dba-b5f7-5747c5b01d10n@googlegroups.com> |
| In reply to | #52916 |
On Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote: > On 6/24/2022 5:16 PM, Ben Bacarisse wrote: > > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > >> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote: > >>> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >>> > >>>> 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. > >>> Then I don't know what you mean by "dry-run" and what needs an > >>> explanation (for me) is your description of what he's doing. Nothing in > >>> what PO is doing needs to be explained as far as I can see. > >>> > >> "Dry run" means that a human programmer looks at the code, and determines > >> what it does, without actually executing it. > > > > OK. So what value does it have in this case? Do you think PO is > > competent to "dry run" any code at all? > > > > Going back, now, to what you think needs to be resolved: > > > > | He's dry-run P(P) and established that it doesn't halt. He's invoked H > > | on it and H reports that it doesn't halt. He's run P(P) and it halts. > > > > The obvious conclusion is that PO's dry run (if he has indeed done such > > a thing) is incorrect. Anyone who eyeballs some case and concludes that > > it does not do what it down when actually run has just made a mistake. > > Do you think it's interesting to find out what mistake PO has made when > > guessing what the code does? If so have fun trying to get the code from > > him... > > > > The more interesting (at least at one time) is fact that H is not > > correct since, by definition, H(X,Y) should report on the "halting" of > > the call X(Y). > > > >> It's a very important technique, because it's not always practical or even > >> possible to run a debugger. Even where a debugger is available, often > >> dry-running will reveal bugs in a fraction of the time. > > > > In this case, we have the undisputed fact that P(P) halts, so there's > > really no value in a "dry run" from a debugging perspective. > > > >> In this case, PO has dry run P(P). > > > > And, if that is indeed what he's done (and I don't think it is) he knows > > he's made some mistake in his "dry run". > > > >> That is, he has looked at the source, and > >> worked out what it will do. > > > > But, I hope you agree, he's made some mistake or he's been lying when re > > reports that P(P) halts. > > > >> Which is to run an infinite sequence of nested > >> emulations. So it won't halt. > > > > The execution of P(P) does not represent an infinite sequence of nested > > simulations. We know that because P(P) halts. > > > >> H(P,P) also reports "non-halting". So this is > >> powerful evidence that H is correct. > > > > Eh? How is some code eyeballing more compelling evidence than the 100% > > undisputed fact that P(P) halts? How is the opinion of someone who > > can't write a parity checking TM powerful evidence of anything? > > > >> However when he actually executes P(P) on hardware, it terminates. > >> Something isn't right. > > > > Yes. > > > >> PO's explanation is that P(P) has different correct behaviour when run and > >> when emulated by H. > > > > That can't be an explanation of anything because, according to you, he > > is wrong about the dry run of P(P) and an actual run of P(P). Both the > > dry run and the actual run must take account of the fact that H is > > (partially) emulating P(P). > > > >> I can think of an obvious alternative explanation which is much > >> simpler and much less far-reaching in its implications. However > >> despite a lot of coaxing, no-one else seems to have arrived at it. > > > > There is nothing here with any far-reaching implications and since I've > > never shared your explanation, I'm not going to look for an alternative. > > > > I don't think he's done a "dry run" at all. He knows P(P) halts so he's > > relying on sophistry. H "aborts" so P never reaches its "ret" > > instruction. That's why P(P) and "the simulation of the inputs to > > H(P,P)" are different. 18 years of work for what? An H that, on the > > basis of his own words, obviously gets the wrong answer. > > > The ordinary semantics of standard C and the conventional x86 language > are the entire semantics required to conclusively prove that H(P,P) does > correctly determine that its correct and complete x86 emulation of its > input would never reach the "ret" instruction (final state) of this > input thus never halts. > That your understanding of the semantics of the x86 language is > insufficient to directly confirm this is less than no rebuttal at all. I assume the semantics of C are defined by the 1989 Standard. The semantics of x86 assembly language are described (not actually authoritatively defined) in other documents. The mapping of C onto the assembly language is far from unique (every compiler could be different) PO appears to using a version of Microsoft's C# compiler. Then we must define how a Turing machine is emulated by a C program. All that is needed of C is the struct concept and assignment. In that case using C seems unadvisable.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-24 19:12 -0500 |
| Message-ID | <196dnYFoP-efziv_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52918 |
On 6/24/2022 6:58 PM, dklei...@gmail.com wrote: > On Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote: >> On 6/24/2022 5:16 PM, Ben Bacarisse wrote: >>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>> >>>> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote: >>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>> >>>>>> 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. >>>>> Then I don't know what you mean by "dry-run" and what needs an >>>>> explanation (for me) is your description of what he's doing. Nothing in >>>>> what PO is doing needs to be explained as far as I can see. >>>>> >>>> "Dry run" means that a human programmer looks at the code, and determines >>>> what it does, without actually executing it. >>> >>> OK. So what value does it have in this case? Do you think PO is >>> competent to "dry run" any code at all? >>> >>> Going back, now, to what you think needs to be resolved: >>> >>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H >>> | on it and H reports that it doesn't halt. He's run P(P) and it halts. >>> >>> The obvious conclusion is that PO's dry run (if he has indeed done such >>> a thing) is incorrect. Anyone who eyeballs some case and concludes that >>> it does not do what it down when actually run has just made a mistake. >>> Do you think it's interesting to find out what mistake PO has made when >>> guessing what the code does? If so have fun trying to get the code from >>> him... >>> >>> The more interesting (at least at one time) is fact that H is not >>> correct since, by definition, H(X,Y) should report on the "halting" of >>> the call X(Y). >>> >>>> It's a very important technique, because it's not always practical or even >>>> possible to run a debugger. Even where a debugger is available, often >>>> dry-running will reveal bugs in a fraction of the time. >>> >>> In this case, we have the undisputed fact that P(P) halts, so there's >>> really no value in a "dry run" from a debugging perspective. >>> >>>> In this case, PO has dry run P(P). >>> >>> And, if that is indeed what he's done (and I don't think it is) he knows >>> he's made some mistake in his "dry run". >>> >>>> That is, he has looked at the source, and >>>> worked out what it will do. >>> >>> But, I hope you agree, he's made some mistake or he's been lying when re >>> reports that P(P) halts. >>> >>>> Which is to run an infinite sequence of nested >>>> emulations. So it won't halt. >>> >>> The execution of P(P) does not represent an infinite sequence of nested >>> simulations. We know that because P(P) halts. >>> >>>> H(P,P) also reports "non-halting". So this is >>>> powerful evidence that H is correct. >>> >>> Eh? How is some code eyeballing more compelling evidence than the 100% >>> undisputed fact that P(P) halts? How is the opinion of someone who >>> can't write a parity checking TM powerful evidence of anything? >>> >>>> However when he actually executes P(P) on hardware, it terminates. >>>> Something isn't right. >>> >>> Yes. >>> >>>> PO's explanation is that P(P) has different correct behaviour when run and >>>> when emulated by H. >>> >>> That can't be an explanation of anything because, according to you, he >>> is wrong about the dry run of P(P) and an actual run of P(P). Both the >>> dry run and the actual run must take account of the fact that H is >>> (partially) emulating P(P). >>> >>>> I can think of an obvious alternative explanation which is much >>>> simpler and much less far-reaching in its implications. However >>>> despite a lot of coaxing, no-one else seems to have arrived at it. >>> >>> There is nothing here with any far-reaching implications and since I've >>> never shared your explanation, I'm not going to look for an alternative. >>> >>> I don't think he's done a "dry run" at all. He knows P(P) halts so he's >>> relying on sophistry. H "aborts" so P never reaches its "ret" >>> instruction. That's why P(P) and "the simulation of the inputs to >>> H(P,P)" are different. 18 years of work for what? An H that, on the >>> basis of his own words, obviously gets the wrong answer. >>> >> The ordinary semantics of standard C and the conventional x86 language >> are the entire semantics required to conclusively prove that H(P,P) does >> correctly determine that its correct and complete x86 emulation of its >> input would never reach the "ret" instruction (final state) of this >> input thus never halts. >> That your understanding of the semantics of the x86 language is >> insufficient to directly confirm this is less than no rebuttal at all. > > I assume the semantics of C are defined by the 1989 Standard. The > semantics of x86 assembly language are described (not actually > authoritatively defined) in other documents. The mapping of C onto > the assembly language is far from unique (every compiler could be > different) PO appears to using a version of Microsoft's C# compiler. > The COFF object file generated by most any Microsoft C compiler. I used Visual Studio 2017 Community Edition. x86 Instruction Set Reference: https://c9x.me/x86/ > Then we must define how a Turing machine is emulated by a C > program. All that is needed of C is the struct concept and > assignment. In that case using C seems unadvisable. > No we don't need this at all. We only need to know that a C function that is a pure function of its inputs is Turing equivalent. https://en.wikipedia.org/wiki/Pure_function By not using C my five page halt decider becomes hundreds of thousands of indecipherable pages of TM description. -- 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 21:56 -0400 |
| Message-ID | <lXttK.317386$5fVf.143079@fx09.iad> |
| In reply to | #52919 |
On 6/24/22 8:12 PM, olcott wrote: > On 6/24/2022 6:58 PM, dklei...@gmail.com wrote: >> On Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote: >>> On 6/24/2022 5:16 PM, Ben Bacarisse wrote: >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>> >>>>> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote: >>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>>> >>>>>>> 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. >>>>>> Then I don't know what you mean by "dry-run" and what needs an >>>>>> explanation (for me) is your description of what he's doing. >>>>>> Nothing in >>>>>> what PO is doing needs to be explained as far as I can see. >>>>>> >>>>> "Dry run" means that a human programmer looks at the code, and >>>>> determines >>>>> what it does, without actually executing it. >>>> >>>> OK. So what value does it have in this case? Do you think PO is >>>> competent to "dry run" any code at all? >>>> >>>> Going back, now, to what you think needs to be resolved: >>>> >>>> | He's dry-run P(P) and established that it doesn't halt. He's >>>> invoked H >>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts. >>>> >>>> The obvious conclusion is that PO's dry run (if he has indeed done such >>>> a thing) is incorrect. Anyone who eyeballs some case and concludes that >>>> it does not do what it down when actually run has just made a mistake. >>>> Do you think it's interesting to find out what mistake PO has made when >>>> guessing what the code does? If so have fun trying to get the code from >>>> him... >>>> >>>> The more interesting (at least at one time) is fact that H is not >>>> correct since, by definition, H(X,Y) should report on the "halting" of >>>> the call X(Y). >>>> >>>>> It's a very important technique, because it's not always practical >>>>> or even >>>>> possible to run a debugger. Even where a debugger is available, often >>>>> dry-running will reveal bugs in a fraction of the time. >>>> >>>> In this case, we have the undisputed fact that P(P) halts, so there's >>>> really no value in a "dry run" from a debugging perspective. >>>> >>>>> In this case, PO has dry run P(P). >>>> >>>> And, if that is indeed what he's done (and I don't think it is) he >>>> knows >>>> he's made some mistake in his "dry run". >>>> >>>>> That is, he has looked at the source, and >>>>> worked out what it will do. >>>> >>>> But, I hope you agree, he's made some mistake or he's been lying >>>> when re >>>> reports that P(P) halts. >>>> >>>>> Which is to run an infinite sequence of nested >>>>> emulations. So it won't halt. >>>> >>>> The execution of P(P) does not represent an infinite sequence of nested >>>> simulations. We know that because P(P) halts. >>>> >>>>> H(P,P) also reports "non-halting". So this is >>>>> powerful evidence that H is correct. >>>> >>>> Eh? How is some code eyeballing more compelling evidence than the 100% >>>> undisputed fact that P(P) halts? How is the opinion of someone who >>>> can't write a parity checking TM powerful evidence of anything? >>>> >>>>> However when he actually executes P(P) on hardware, it terminates. >>>>> Something isn't right. >>>> >>>> Yes. >>>> >>>>> PO's explanation is that P(P) has different correct behaviour when >>>>> run and >>>>> when emulated by H. >>>> >>>> That can't be an explanation of anything because, according to you, he >>>> is wrong about the dry run of P(P) and an actual run of P(P). Both the >>>> dry run and the actual run must take account of the fact that H is >>>> (partially) emulating P(P). >>>> >>>>> I can think of an obvious alternative explanation which is much >>>>> simpler and much less far-reaching in its implications. However >>>>> despite a lot of coaxing, no-one else seems to have arrived at it. >>>> >>>> There is nothing here with any far-reaching implications and since I've >>>> never shared your explanation, I'm not going to look for an >>>> alternative. >>>> >>>> I don't think he's done a "dry run" at all. He knows P(P) halts so he's >>>> relying on sophistry. H "aborts" so P never reaches its "ret" >>>> instruction. That's why P(P) and "the simulation of the inputs to >>>> H(P,P)" are different. 18 years of work for what? An H that, on the >>>> basis of his own words, obviously gets the wrong answer. >>>> >>> The ordinary semantics of standard C and the conventional x86 language >>> are the entire semantics required to conclusively prove that H(P,P) does >>> correctly determine that its correct and complete x86 emulation of its >>> input would never reach the "ret" instruction (final state) of this >>> input thus never halts. >>> That your understanding of the semantics of the x86 language is >>> insufficient to directly confirm this is less than no rebuttal at all. >> >> I assume the semantics of C are defined by the 1989 Standard. The >> semantics of x86 assembly language are described (not actually >> authoritatively defined) in other documents. The mapping of C onto >> the assembly language is far from unique (every compiler could be >> different) PO appears to using a version of Microsoft's C# compiler. >> > > The COFF object file generated by most any Microsoft C compiler. > I used Visual Studio 2017 Community Edition. > > x86 Instruction Set Reference: https://c9x.me/x86/ > >> Then we must define how a Turing machine is emulated by a C >> program. All that is needed of C is the struct concept and >> assignment. In that case using C seems unadvisable. > > No we don't need this at all. We only need to know that a C function > that is a pure function of its inputs is Turing equivalent. > > https://en.wikipedia.org/wiki/Pure_function > > By not using C my five page halt decider becomes hundreds of thousands > of indecipherable pages of TM description. > It needs bit more, because function, as defined by C, that are not "leaf" functions are not, in themselves, complete definitions of a computation, and need to include the code (at least at the abstract machine level) of any function they call. THus, P needs to include an ACCURATE model of H to be able to be converted into a Turing Machine, which means you need to fix which version of H it is calling. Does C call the H that IS a complete and correct emulator, and tus gets P(P) into non-halting behavior, but also doesn't answer, so fails to be a Halting Decider, or does C call the H that DOES abort its emulaton and return 0, making P(P) a Halting Computation and H return the wrong answer. Your arguement has H being both of these at the same time, which is impossible.
[toc] | [prev] | [next] | [standalone]
| From | "dklei...@gmail.com" <dkleinecke@gmail.com> |
|---|---|
| Date | 2022-06-24 21:50 -0700 |
| Message-ID | <fab45955-7bf3-48db-9b97-dc68eb3eb884n@googlegroups.com> |
| In reply to | #52919 |
On Friday, June 24, 2022 at 5:12:57 PM UTC-7, olcott wrote: > On 6/24/2022 6:58 PM, dklei...@gmail.com wrote: > > On Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote: > >> On 6/24/2022 5:16 PM, Ben Bacarisse wrote: > >>> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >>> > >>>> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote: > >>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >>>>> > >>>>>> 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. > >>>>> Then I don't know what you mean by "dry-run" and what needs an > >>>>> explanation (for me) is your description of what he's doing. Nothing in > >>>>> what PO is doing needs to be explained as far as I can see. > >>>>> > >>>> "Dry run" means that a human programmer looks at the code, and determines > >>>> what it does, without actually executing it. > >>> > >>> OK. So what value does it have in this case? Do you think PO is > >>> competent to "dry run" any code at all? > >>> > >>> Going back, now, to what you think needs to be resolved: > >>> > >>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H > >>> | on it and H reports that it doesn't halt. He's run P(P) and it halts. > >>> > >>> The obvious conclusion is that PO's dry run (if he has indeed done such > >>> a thing) is incorrect. Anyone who eyeballs some case and concludes that > >>> it does not do what it down when actually run has just made a mistake. > >>> Do you think it's interesting to find out what mistake PO has made when > >>> guessing what the code does? If so have fun trying to get the code from > >>> him... > >>> > >>> The more interesting (at least at one time) is fact that H is not > >>> correct since, by definition, H(X,Y) should report on the "halting" of > >>> the call X(Y). > >>> > >>>> It's a very important technique, because it's not always practical or even > >>>> possible to run a debugger. Even where a debugger is available, often > >>>> dry-running will reveal bugs in a fraction of the time. > >>> > >>> In this case, we have the undisputed fact that P(P) halts, so there's > >>> really no value in a "dry run" from a debugging perspective. > >>> > >>>> In this case, PO has dry run P(P). > >>> > >>> And, if that is indeed what he's done (and I don't think it is) he knows > >>> he's made some mistake in his "dry run". > >>> > >>>> That is, he has looked at the source, and > >>>> worked out what it will do. > >>> > >>> But, I hope you agree, he's made some mistake or he's been lying when re > >>> reports that P(P) halts. > >>> > >>>> Which is to run an infinite sequence of nested > >>>> emulations. So it won't halt. > >>> > >>> The execution of P(P) does not represent an infinite sequence of nested > >>> simulations. We know that because P(P) halts. > >>> > >>>> H(P,P) also reports "non-halting". So this is > >>>> powerful evidence that H is correct. > >>> > >>> Eh? How is some code eyeballing more compelling evidence than the 100% > >>> undisputed fact that P(P) halts? How is the opinion of someone who > >>> can't write a parity checking TM powerful evidence of anything? > >>> > >>>> However when he actually executes P(P) on hardware, it terminates. > >>>> Something isn't right. > >>> > >>> Yes. > >>> > >>>> PO's explanation is that P(P) has different correct behaviour when run and > >>>> when emulated by H. > >>> > >>> That can't be an explanation of anything because, according to you, he > >>> is wrong about the dry run of P(P) and an actual run of P(P). Both the > >>> dry run and the actual run must take account of the fact that H is > >>> (partially) emulating P(P). > >>> > >>>> I can think of an obvious alternative explanation which is much > >>>> simpler and much less far-reaching in its implications. However > >>>> despite a lot of coaxing, no-one else seems to have arrived at it. > >>> > >>> There is nothing here with any far-reaching implications and since I've > >>> never shared your explanation, I'm not going to look for an alternative. > >>> > >>> I don't think he's done a "dry run" at all. He knows P(P) halts so he's > >>> relying on sophistry. H "aborts" so P never reaches its "ret" > >>> instruction. That's why P(P) and "the simulation of the inputs to > >>> H(P,P)" are different. 18 years of work for what? An H that, on the > >>> basis of his own words, obviously gets the wrong answer. > >>> > >> The ordinary semantics of standard C and the conventional x86 language > >> are the entire semantics required to conclusively prove that H(P,P) does > >> correctly determine that its correct and complete x86 emulation of its > >> input would never reach the "ret" instruction (final state) of this > >> input thus never halts. > >> That your understanding of the semantics of the x86 language is > >> insufficient to directly confirm this is less than no rebuttal at all. > > > > I assume the semantics of C are defined by the 1989 Standard. The > > semantics of x86 assembly language are described (not actually > > authoritatively defined) in other documents. The mapping of C onto > > the assembly language is far from unique (every compiler could be > > different) PO appears to using a version of Microsoft's C# compiler. > > > The COFF object file generated by most any Microsoft C compiler. > I used Visual Studio 2017 Community Edition. > > x86 Instruction Set Reference: https://c9x.me/x86/ > > Then we must define how a Turing machine is emulated by a C > > program. All that is needed of C is the struct concept and > > assignment. In that case using C seems unadvisable. > > > No we don't need this at all. We only need to know that a C function > that is a pure function of its inputs is Turing equivalent. > > https://en.wikipedia.org/wiki/Pure_function You are jumping too far in one step. What I am asking is equivalent to: Given a Turing Machine how do its steps map into C and thence into x86? No C functions are involved. > By not using C my five page halt decider becomes hundreds of thousands > of indecipherable pages of TM description. That would depend on the answer to my question.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-24 23:59 -0500 |
| Message-ID | <frudnQE7VPOLCyv_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52928 |
On 6/24/2022 11:50 PM, dklei...@gmail.com wrote: > On Friday, June 24, 2022 at 5:12:57 PM UTC-7, olcott wrote: >> On 6/24/2022 6:58 PM, dklei...@gmail.com wrote: >>> On Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote: >>>> On 6/24/2022 5:16 PM, Ben Bacarisse wrote: >>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>> >>>>>> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote: >>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>>>> >>>>>>>> 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. >>>>>>> Then I don't know what you mean by "dry-run" and what needs an >>>>>>> explanation (for me) is your description of what he's doing. Nothing in >>>>>>> what PO is doing needs to be explained as far as I can see. >>>>>>> >>>>>> "Dry run" means that a human programmer looks at the code, and determines >>>>>> what it does, without actually executing it. >>>>> >>>>> OK. So what value does it have in this case? Do you think PO is >>>>> competent to "dry run" any code at all? >>>>> >>>>> Going back, now, to what you think needs to be resolved: >>>>> >>>>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H >>>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts. >>>>> >>>>> The obvious conclusion is that PO's dry run (if he has indeed done such >>>>> a thing) is incorrect. Anyone who eyeballs some case and concludes that >>>>> it does not do what it down when actually run has just made a mistake. >>>>> Do you think it's interesting to find out what mistake PO has made when >>>>> guessing what the code does? If so have fun trying to get the code from >>>>> him... >>>>> >>>>> The more interesting (at least at one time) is fact that H is not >>>>> correct since, by definition, H(X,Y) should report on the "halting" of >>>>> the call X(Y). >>>>> >>>>>> It's a very important technique, because it's not always practical or even >>>>>> possible to run a debugger. Even where a debugger is available, often >>>>>> dry-running will reveal bugs in a fraction of the time. >>>>> >>>>> In this case, we have the undisputed fact that P(P) halts, so there's >>>>> really no value in a "dry run" from a debugging perspective. >>>>> >>>>>> In this case, PO has dry run P(P). >>>>> >>>>> And, if that is indeed what he's done (and I don't think it is) he knows >>>>> he's made some mistake in his "dry run". >>>>> >>>>>> That is, he has looked at the source, and >>>>>> worked out what it will do. >>>>> >>>>> But, I hope you agree, he's made some mistake or he's been lying when re >>>>> reports that P(P) halts. >>>>> >>>>>> Which is to run an infinite sequence of nested >>>>>> emulations. So it won't halt. >>>>> >>>>> The execution of P(P) does not represent an infinite sequence of nested >>>>> simulations. We know that because P(P) halts. >>>>> >>>>>> H(P,P) also reports "non-halting". So this is >>>>>> powerful evidence that H is correct. >>>>> >>>>> Eh? How is some code eyeballing more compelling evidence than the 100% >>>>> undisputed fact that P(P) halts? How is the opinion of someone who >>>>> can't write a parity checking TM powerful evidence of anything? >>>>> >>>>>> However when he actually executes P(P) on hardware, it terminates. >>>>>> Something isn't right. >>>>> >>>>> Yes. >>>>> >>>>>> PO's explanation is that P(P) has different correct behaviour when run and >>>>>> when emulated by H. >>>>> >>>>> That can't be an explanation of anything because, according to you, he >>>>> is wrong about the dry run of P(P) and an actual run of P(P). Both the >>>>> dry run and the actual run must take account of the fact that H is >>>>> (partially) emulating P(P). >>>>> >>>>>> I can think of an obvious alternative explanation which is much >>>>>> simpler and much less far-reaching in its implications. However >>>>>> despite a lot of coaxing, no-one else seems to have arrived at it. >>>>> >>>>> There is nothing here with any far-reaching implications and since I've >>>>> never shared your explanation, I'm not going to look for an alternative. >>>>> >>>>> I don't think he's done a "dry run" at all. He knows P(P) halts so he's >>>>> relying on sophistry. H "aborts" so P never reaches its "ret" >>>>> instruction. That's why P(P) and "the simulation of the inputs to >>>>> H(P,P)" are different. 18 years of work for what? An H that, on the >>>>> basis of his own words, obviously gets the wrong answer. >>>>> >>>> The ordinary semantics of standard C and the conventional x86 language >>>> are the entire semantics required to conclusively prove that H(P,P) does >>>> correctly determine that its correct and complete x86 emulation of its >>>> input would never reach the "ret" instruction (final state) of this >>>> input thus never halts. >>>> That your understanding of the semantics of the x86 language is >>>> insufficient to directly confirm this is less than no rebuttal at all. >>> >>> I assume the semantics of C are defined by the 1989 Standard. The >>> semantics of x86 assembly language are described (not actually >>> authoritatively defined) in other documents. The mapping of C onto >>> the assembly language is far from unique (every compiler could be >>> different) PO appears to using a version of Microsoft's C# compiler. >>> >> The COFF object file generated by most any Microsoft C compiler. >> I used Visual Studio 2017 Community Edition. >> >> x86 Instruction Set Reference: https://c9x.me/x86/ >>> Then we must define how a Turing machine is emulated by a C >>> program. All that is needed of C is the struct concept and >>> assignment. In that case using C seems unadvisable. >>> >> No we don't need this at all. We only need to know that a C function >> that is a pure function of its inputs is Turing equivalent. >> >> https://en.wikipedia.org/wiki/Pure_function > > You are jumping too far in one step. What I am asking is equivalent to: > Given a Turing Machine how do its steps map into C and thence into x86? > No C functions are involved. > I have written this up several ways that boil down to C maps to a RASP machine that maps to a TM. https://en.wikipedia.org/wiki/Random-access_stored-program_machine The bottom line is that when a C function is a pure function of its inputs then it is TM equivalent computation. >> By not using C my five page halt decider becomes hundreds of thousands >> of indecipherable pages of TM description. > > That would depend on the answer to my question. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.theory
csiph-web