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 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-25 11:40 -0500 |
| Message-ID | <M_idneTbv7rvpyr_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52954 |
On 6/25/2022 11:31 AM, Python wrote: > Demented bigot, Peter Olcott wrote: > ... >> In other words you are saying that a halt decider is simply not >> allowed to report when it correctly detects that it is being called in >> infinitely recursive simulation. >> >> We could also "prove" that a correct halt decider is impossible by >> making another similar rule that halt deciders are simply not allowed >> to report on infinite loops. > > You can also "prove" that a natural number that is both even and odd > is even. It doesn't mean that such a number exists. > > Publish your code for H. We do have a proof (mutiple proofs) that it > cannot exist as you specify it. To fully understand this a software engineer must be an expert in: (a) The C programming language. (b) The x86 programming language. (c) Exactly how C translates into x86 (how C function calls are implemented in x86). (d) 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 (final state) of this input thus never halts. THIS IS ALL THAT IS NEEDED TO VERIFY THAT: On 6/25/2022 10:03 AM, olcott wrote: [Technically competent Software engineers can verify this halting problem proof refutation] > You know that we could, then, prove > that it doesn't work. This is why you are not publishing it. You are > a LIAR, a DELUSIONAL CRANK, a DESPICABLE FRAUD, Olcott. > > > [AGAIN: STOP MULTI-POSTING WITHOUT FOLLOW-UP, YOU ASSHOLE!!!] > Multi-posting without followup to four relevant groups does not not seem to breach netiquette guidelines and does get more reviewers of my work. -- 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-25 12:59 -0400 |
| Message-ID | <N9HtK.236183$70j.16465@fx16.iad> |
| In reply to | #52946 |
On 6/25/22 11:19 AM, olcott wrote:
> On 6/25/2022 10:09 AM, Mr Flibble wrote:
>> On Sat, 25 Jun 2022 10:03:17 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/25/2022 9:28 AM, olcott wrote:
>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
>>>>>>>>> wrote:
>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>> "Dry run" means that a human programmer looks at the code,
>>>>>>>>>>> and determines
>>>>>>>>>>> what it does, without actually executing it.
>>>>>>>>>>
>>>>>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt.
>>>>>>>>>> He's invoked H
>>>>>>>>>> | on it and H reports that it doesn't halt. He's run P(P) and
>>>>>>>>>> it halts.
>>>>>>>>>> The obvious conclusion is that PO's dry run (if he has indeed
>>>>>>>>>> done such
>>>>>>>>>> a thing) is incorrect.
>>>>>>>>> Exactly.
>>>>>>>>> We do our little energy budget on tigers, and find that tigers
>>>>>>>>> spend more energy
>>>>>>>>> than they take in. Well potentially this is dynamite. One
>>>>>>>>> explanation is that the
>>>>>>>>> law of conservation of energy is wrong.
>>>>>>>>> Except, before we countenance that explanation, we need to
>>>>>>>>> rule out a much
>>>>>>>>> simpler explanation. Which is that our measurements are wrong.
>>>>>>>>>
>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should be
>>>>>>>>> doing, by dry-running
>>>>>>>>> it, and then actually run P(P) and obtained a different
>>>>>>>>> result. He also found that H
>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
>>>>>>>>> conclusion, but it is extensive
>>>>>>>>> and far-reaching in its implications. The behaviour of code
>>>>>>>>> when run is different
>>>>>>>>> from the correct behaviour of the code when simulated. If
>>>>>>>>> that's true, then it has
>>>>>>>>> similar implications for computer science that disproving the
>>>>>>>>> conservation law
>>>>>>>>> has for physics.
>>>>>>>>>
>>>>>>>>> But the obvious explanation is that the dry-run was incorrect.
>>>>>>>>> Lots of people have
>>>>>>>>> suggested why it is incorrect. But they can't actually see the
>>>>>>>>> code. PO needs to
>>>>>>>>> understand that no-one will accept the complicated,
>>>>>>>>> far-reaching explanation,
>>>>>>>>> until the simple explanation has been ruled out.
>>>>>>>>
>>>>>>>> I already proved that the dry run is correct.
>>>>>>> Someone reports that tigers use more energy than they take in,
>>>>>>> and concludes that
>>>>>>> the energy conservation law is incorrect.
>>>>>>> Naturally, everyone is going to say "There must be some mistake.
>>>>>>> How were your
>>>>>>> measurements taken? Show us your calculations, maybe you've got
>>>>>>> your sums wrong."
>>>>>>>
>>>>>>> Now if they are also uncooperative about sharing the details of
>>>>>>> the investigation,
>>>>>>> those reservations will be magnified. There can be legitimate
>>>>>>> reasons. Tigers are
>>>>>>> rare and need to be conserved, you can't let anyone who wants
>>>>>>> have access to the
>>>>>>> tigers to try to repeat the measurements. But there's also a
>>>>>>> common illegitimate
>>>>>>> reason put forwards by people who make extraordinary claims. If
>>>>>>> the claims were
>>>>>>> unexceptional, such as that tigers have a similar energy budget
>>>>>>> to lions, then no-one
>>>>>>> would be saying "Show me your notebooks. How do you know that
>>>>>>> calorimeter was
>>>>>>> calibrated accurately? What's the name of the person who took
>>>>>>> that measurement
>>>>>>> and can I interview them?" Extraordinary claims are put through
>>>>>>> the wringer in a way
>>>>>>> that ordinary ones are not. I've seen complaints about this from
>>>>>>> parapsychologists.
>>>>>>> But if you're going to claim to have discovered a new physical
>>>>>>> principle, you need
>>>>>>> to present rock solid evidence.
>>>>>>>
>>>>>>> In this case, we can't see H. We can only suggest explanations
>>>>>>> for its behaviour.
>>>>>> It seems that you simply lack the technical competence.
>>>>>> Go back and look at my proof again.
>>>>> Sorry no. I've been programming since I was a boy and I have a PhD
>>>>> in a computational-
>>>>> related subject. I'm confident of my technical abilities. What I
>>>>> can't do of course
>>>>> is tell you exactly what is going on in code I cannot see. I've
>>>>> got a pretty good idea,
>>>>> but I can only reconstruct on the basis of what you tell me. Ben
>>>>> thinks that I've
>>>>> got it wrong and in fact there are no nested emulations at all.
>>>>> I've no way of actually
>>>>> disproving that idea without seeing H.
>>>>
>>>> To fully understand this a software engineer must be an expert in:
>>>> (a) The C programming language,
>>>> (b) The x86 programming language,
>>>> (c) Exactly how C translates into x86 and,
>>>> (d) The ability to recognize infinite recursion at the x86 assembly
>>>> language level.
>>>>
>>>> Anyone having the above credentials can validate my work, if you
>>>> cannot validate my work then you do not sufficiently have the above
>>>> credentials.
>>>>
>>>> Exactly how C translates into x86 is mandatory. If you don't know
>>>> how the C calling conventions are implemented in x86 you cannot
>>>> validate my work.
>>>>
>>>> From a purely software engineering perspective H(P,P) is required
>>>> to to correctly determine that its correct and complete x86
>>>> emulation of its input would never reach the "ret" instruction of
>>>> this input and H must do this in a finite number of steps.
>>>>
>>>> The ordinary semantics of standard C and the conventional x86
>>>> language are the entire semantics required to conclusively prove
>>>> that H(P,P) does correctly determine that its correct and complete
>>>> x86 emulation of its input would never reach the "ret" instruction
>>>> (final state) of this input thus never halts.
>>>>
>>>> The correct and complete x86 emulation of its input by H(P,P) would
>>>> never reach the "ret" instruction of P because both H and P would
>>>> remain stuck in infinitely nested emulation.
>>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> _P()
>>>> [00001202](01) 55 push ebp
>>>> [00001203](02) 8bec mov ebp,esp
>>>> [00001205](03) 8b4508 mov eax,[ebp+08]
>>>> [00001208](01) 50 push eax
>>>> [00001209](03) 8b4d08 mov ecx,[ebp+08]
>>>> [0000120c](01) 51 push ecx
>>>> [0000120d](05) e820feffff call 00001032
>>>> [00001212](03) 83c408 add esp,+08
>>>> [00001215](02) 85c0 test eax,eax
>>>> [00001217](02) 7402 jz 0000121b
>>>> [00001219](02) ebfe jmp 00001219
>>>> [0000121b](01) 5d pop ebp
>>>> [0000121c](01) c3 ret
>>>> Size in bytes:(0027) [0000121c]
>>>>
>>>> _main()
>>>> [00001222](01) 55 push ebp
>>>> [00001223](02) 8bec mov ebp,esp
>>>> [00001225](05) 6802120000 push 00001202
>>>> [0000122a](05) 6802120000 push 00001202
>>>> [0000122f](05) e8fefdffff call 00001032
>>>> [00001234](03) 83c408 add esp,+08
>>>> [00001237](01) 50 push eax
>>>> [00001238](05) 68b3030000 push 000003b3
>>>> [0000123d](05) e8c0f1ffff call 00000402
>>>> [00001242](03) 83c408 add esp,+08
>>>> [00001245](02) 33c0 xor eax,eax
>>>> [00001247](01) 5d pop ebp
>>>> [00001248](01) c3 ret
>>>> Size in bytes:(0039) [00001248]
>>>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> [00001222][0010200f][00000000] 55 push ebp
>>>> [00001223][0010200f][00000000] 8bec mov ebp,esp
>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 // push P
>>>> [0000122a][00102007][00001202] 6802120000 push 00001202 // push P
>>>> [0000122f][00102003][00001234] e8fefdffff call 00001032 // call
>>>> executed H
>>>>
>>>> Begin Simulation Execution Trace Stored at:2120c3
>>>> Address_of_H:1032
>>>> [00001202][002120af][002120b3] 55 push ebp
>>>> [00001203][002120af][002120b3] 8bec mov ebp,esp
>>>> [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
>>>> [00001208][002120ab][00001202] 50 push eax // push P
>>>> [00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08]
>>>> [0000120c][002120a7][00001202] 51 push ecx // push P
>>>> [0000120d][002120a3][00001212] e820feffff call 00001032 // call
>>>> emulated H Infinitely Recursive Simulation Detected Simulation
>>>> Stopped
>>>>
>>>> H knows its own machine address and on this basis it can easily
>>>> examine its stored execution_trace of P (see above) to determine:
>>>> (a) P is calling H with the same arguments that H was called with.
>>>> (b) No instructions in P could possibly escape this otherwise
>>>> infinitely recursive emulation.
>>>> (c) H aborts its emulation of P before its call to H is emulated.
>>>
>>> When you know that H simply implements the above algorithm there is
>>> no need to see its source code. I am reserving the publication of the
>>> 5 pages of the source code of the halt decider for journal
>>> publication.
>>
>> Your H is not a pure function as it behaves differently depending on
>> what is invoking it (it returns a decision answer to main() but not
>> to P()) and it has side effects (aborting a simulation).
>>
>> /Flibble
>>
>
> Finally a critique that has a reasonable basis.
>
> When I transformed H into a pure function of its inputs it always has
> the same behavior no matter how it is invoked.
>
> The x86 emulation of P is aborted before P invokes H.
>
Teny why doesn't it return the answer to P when P(P) is emulated?
Proof you LIE.
One H(P,P) return 0
One H(P,P) doesn't return.
DIFFERENT BEHAVIOR, BY DEFINITION not a pure function, or the emulation
isn't correct.
We need the code of H to tell you in which way your H is wrong.
Without it, all we can do is show you it is wrong.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-25 09:39 -0400 |
| Message-ID | <oeEtK.5560$Ae2.2515@fx35.iad> |
| In reply to | #52927 |
On 6/25/22 12:33 AM, olcott wrote: > On 6/24/2022 11:01 PM, Malcolm McLean wrote: >> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote: >>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>> >>>> "Dry run" means that a human programmer looks at the code, and >>>> determines >>>> what it does, without actually executing it. >>> >>> Going back, now, to what you think needs to be resolved: >>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H >>> | on it and H reports that it doesn't halt. He's run P(P) and it halts. >>> The obvious conclusion is that PO's dry run (if he has indeed done such >>> a thing) is incorrect. >>> >> Exactly. >> We do our little energy budget on tigers, and find that tigers spend >> more energy >> than they take in. Well potentially this is dynamite. One explanation >> is that the >> law of conservation of energy is wrong. >> Except, before we countenance that explanation, we need to rule out a >> much >> simpler explanation. Which is that our measurements are wrong. >> >> Similarly, PO has worked out what he thinks P(P) should be doing, by >> dry-running >> it, and then actually run P(P) and obtained a different result. He >> also found that H >> agreed with the dry run. It's hard to paraphrase his conclusion, but >> it is extensive >> and far-reaching in its implications. The behaviour of code when run >> is different >> from the correct behaviour of the code when simulated. If that's true, >> then it has >> similar implications for computer science that disproving the >> conservation law >> has for physics. >> >> But the obvious explanation is that the dry-run was incorrect. Lots of >> people have >> suggested why it is incorrect. But they can't actually see the code. >> PO needs to >> understand that no-one will accept the complicated, far-reaching >> explanation, >> until the simple explanation has been ruled out. > > I already proved that the dry run is correct. > > No, becasue the H in the dry run isn't the H in the final, thus your P's are different computations (even if they have the same partial source code). As you have said, the behavior of P(p) is dependent on the behavior of the behavior of H(P,P), so if you change the latter, you have changed the former, and thus your dry run was looking at the WRONG P.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-06-26 00:55 +0100 |
| Message-ID | <87k094uwkw.fsf@bsb.me.uk> |
| In reply to | #52926 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >> > "Dry run" means that a human programmer looks at the code, and determines >> > what it does, without actually executing it. >> >> Going back, now, to what you think needs to be resolved: >> | He's dry-run P(P) and established that it doesn't halt. He's invoked H >> | on it and H reports that it doesn't halt. He's run P(P) and it halts. >> The obvious conclusion is that PO's dry run (if he has indeed done such >> a thing) is incorrect. >> > Exactly. > We do our little energy budget on tigers, and find that tigers spend > more energy than they take in. Well potentially this is dynamite. One > explanation is that the law of conservation of energy is wrong. > Except, before we countenance that explanation, we need to rule out a > much simpler explanation. Which is that our measurements are wrong. Obviously. > Similarly, PO has worked out what he thinks P(P) should be doing, by > dry-running it, and then actually run P(P) and obtained a different > result. He also found that H agreed with the dry run. It's hard to > paraphrase his conclusion, but it is extensive and far-reaching in its > implications. He is just waffling. There is no conclusion, just a constant twisting and turning to find some why to persuade people that the wrong answer is the right one. He's being doing this for years with various degrees of obfuscation. H does not report the correct result for P(P) and PO is putting up anything he can think of to keep the discussion going. It should simply have stopped once he'd been clear that H(P,P) == 0 is correct "even though P(P) halts" but the traces and the verbiage is keeping people keen. > The behaviour of code when run is different from the > correct behaviour of the code when simulated. If that's true, then it > has similar implications for computer science that disproving the > conservation law has for physics. When a student comes to me and says that her program to add 5 and 6 gives 12, I don't, even for a moment, imagine that the laws of logic and mathematics are in doubt. > But the obvious explanation is that the dry-run was incorrect. Lots of > people have suggested why it is incorrect. But they can't actually see > the code. PO needs to understand that no-one will accept the > complicated, far-reaching explanation, until the simple explanation > has been ruled out. For what it's worth, I don't think there is any "dry run" going on here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0 because he knew (correctly) that H could spot what would happen if H did not "intervene". Everything since then -- the "it only halt because...", the "it wouldn't halt if line 15 were commented out" and the rather less explicitly stated "H_Hat does not get to its ret instruction because a non top-level H aborts" are just the various attempt at after-the-fact justification. I agree it's never quite so simple because PO is usually fractally wrong, so he's not correct about almost everything he says at almost every level. For example, at one level he now admits that a halt decider is impossible because H(X,Y) must report "on its input" and the call X(Y) is not an input! He did this to explain why H(P,P) is permitted to return 0 "even though P(P) halts", but it also makes it clear that what he one thought was that halting problem is not solvable. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-25 20:07 -0500 |
| Message-ID | <IfWdnReH1e6kLCr_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52984 |
On 6/25/2022 6:55 PM, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote: >>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>> >>>> "Dry run" means that a human programmer looks at the code, and determines >>>> what it does, without actually executing it. >>> >>> Going back, now, to what you think needs to be resolved: >>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H >>> | on it and H reports that it doesn't halt. He's run P(P) and it halts. >>> The obvious conclusion is that PO's dry run (if he has indeed done such >>> a thing) is incorrect. >>> >> Exactly. >> We do our little energy budget on tigers, and find that tigers spend >> more energy than they take in. Well potentially this is dynamite. One >> explanation is that the law of conservation of energy is wrong. >> Except, before we countenance that explanation, we need to rule out a >> much simpler explanation. Which is that our measurements are wrong. > > Obviously. > >> Similarly, PO has worked out what he thinks P(P) should be doing, by >> dry-running it, and then actually run P(P) and obtained a different >> result. He also found that H agreed with the dry run. It's hard to >> paraphrase his conclusion, but it is extensive and far-reaching in its >> implications. > > He is just waffling. There is no conclusion, just a constant twisting > and turning to find some why to persuade people that the wrong answer is > the right one. He's being doing this for years with various degrees of > obfuscation. > > H does not report the correct result for P(P) and PO is putting up > anything he can think of to keep the discussion going. It should simply > have stopped once he'd been clear that H(P,P) == 0 is correct "even > though P(P) halts" but the traces and the verbiage is keeping people keen. > >> The behaviour of code when run is different from the >> correct behaviour of the code when simulated. If that's true, then it >> has similar implications for computer science that disproving the >> conservation law has for physics. > > When a student comes to me and says that her program to add 5 and 6 > gives 12, I don't, even for a moment, imagine that the laws of logic and > mathematics are in doubt. > >> But the obvious explanation is that the dry-run was incorrect. Lots of >> people have suggested why it is incorrect. But they can't actually see >> the code. PO needs to understand that no-one will accept the >> complicated, far-reaching explanation, until the simple explanation >> has been ruled out. > > For what it's worth, I don't think there is any "dry run" going on here > at all. PO decide years ago that H(H_Hat, H_Hat) would be 0 because he > knew (correctly) that H could spot what would happen if H did not > "intervene". Everything since then -- the "it only halt because...", > the "it wouldn't halt if line 15 were commented out" and the rather less > explicitly stated "H_Hat does not get to its ret instruction because a > non top-level H aborts" are just the various attempt at after-the-fact > justification. > > I agree it's never quite so simple because PO is usually fractally > wrong, so he's not correct about almost everything he says at almost > every level. For example, at one level he now admits that a halt > decider is impossible because H(X,Y) must report "on its input" and the > call X(Y) is not an input! He did this to explain why H(P,P) is > permitted to return 0 "even though P(P) halts", but it also makes it > clear that what he one thought was that halting problem is not solvable. > (a) and (b) are proven to be verified facts entirely on the basis of the semantics of the x86 language. (Most people here do not seem to "believe in" the semantics of the x86 language otherwise they would have no basis to disagree). (a) The complete and correct x86 emulation of the input to H(P,P) by H never reaches the "ret" instruction of P. (b) The direct execution of P(P) does reach its "ret" instruction. 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. P(P) is provably not the actual behavior of the actual input. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-26 02:16 +0100 |
| Message-ID | <20220626021629.0000783c@reddwarf.jmc> |
| In reply to | #52994 |
On Sat, 25 Jun 2022 20:07:04 -0500 olcott <NoOne@NoWhere.com> wrote: > On 6/25/2022 6:55 PM, Ben Bacarisse wrote: > > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > >> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote: > >>> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >>> > >>>> "Dry run" means that a human programmer looks at the code, and > >>>> determines what it does, without actually executing it. > >>> > >>> Going back, now, to what you think needs to be resolved: > >>> | He's dry-run P(P) and established that it doesn't halt. He's > >>> invoked H | on it and H reports that it doesn't halt. He's run > >>> P(P) and it halts. The obvious conclusion is that PO's dry run > >>> (if he has indeed done such a thing) is incorrect. > >>> > >> Exactly. > >> We do our little energy budget on tigers, and find that tigers > >> spend more energy than they take in. Well potentially this is > >> dynamite. One explanation is that the law of conservation of > >> energy is wrong. Except, before we countenance that explanation, > >> we need to rule out a much simpler explanation. Which is that our > >> measurements are wrong. > > > > Obviously. > > > >> Similarly, PO has worked out what he thinks P(P) should be doing, > >> by dry-running it, and then actually run P(P) and obtained a > >> different result. He also found that H agreed with the dry run. > >> It's hard to paraphrase his conclusion, but it is extensive and > >> far-reaching in its implications. > > > > He is just waffling. There is no conclusion, just a constant > > twisting and turning to find some why to persuade people that the > > wrong answer is the right one. He's being doing this for years > > with various degrees of obfuscation. > > > > H does not report the correct result for P(P) and PO is putting up > > anything he can think of to keep the discussion going. It should > > simply have stopped once he'd been clear that H(P,P) == 0 is > > correct "even though P(P) halts" but the traces and the verbiage is > > keeping people keen. > >> The behaviour of code when run is different from the > >> correct behaviour of the code when simulated. If that's true, then > >> it has similar implications for computer science that disproving > >> the conservation law has for physics. > > > > When a student comes to me and says that her program to add 5 and 6 > > gives 12, I don't, even for a moment, imagine that the laws of > > logic and mathematics are in doubt. > > > >> But the obvious explanation is that the dry-run was incorrect. > >> Lots of people have suggested why it is incorrect. But they can't > >> actually see the code. PO needs to understand that no-one will > >> accept the complicated, far-reaching explanation, until the simple > >> explanation has been ruled out. > > > > For what it's worth, I don't think there is any "dry run" going on > > here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0 > > because he knew (correctly) that H could spot what would happen if > > H did not "intervene". Everything since then -- the "it only halt > > because...", the "it wouldn't halt if line 15 were commented out" > > and the rather less explicitly stated "H_Hat does not get to its > > ret instruction because a non top-level H aborts" are just the > > various attempt at after-the-fact justification. > > > > I agree it's never quite so simple because PO is usually fractally > > wrong, so he's not correct about almost everything he says at almost > > every level. For example, at one level he now admits that a halt > > decider is impossible because H(X,Y) must report "on its input" and > > the call X(Y) is not an input! He did this to explain why H(P,P) is > > permitted to return 0 "even though P(P) halts", but it also makes it > > clear that what he one thought was that halting problem is not > > solvable. > > (a) and (b) are proven to be verified facts entirely on the basis of > the semantics of the x86 language. (Most people here do not seem to > "believe in" the semantics of the x86 language otherwise they would > have no basis to disagree). > > (a) The complete and correct x86 emulation of the input to H(P,P) by > H never reaches the "ret" instruction of P. > > (b) The direct execution of P(P) does reach its "ret" instruction. > > 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. > > P(P) is provably not the actual behavior of the actual input. (a) is false as the reason the ret instruction is not reached is incorrect: the ret instruction should not be reached due to the infinite loop in P and not because you abort the simulation before the infinite loop is reached. Your H is incorrect in its assumption that P is pathological because it calls H. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-25 20:36 -0500 |
| Message-ID | <z4Kdne4xZrmHJSr_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52995 |
On 6/25/2022 8:16 PM, Mr Flibble wrote:
> On Sat, 25 Jun 2022 20:07:04 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> "Dry run" means that a human programmer looks at the code, and
>>>>>> determines what it does, without actually executing it.
>>>>>
>>>>> Going back, now, to what you think needs to be resolved:
>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
>>>>> invoked H | on it and H reports that it doesn't halt. He's run
>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
>>>>> (if he has indeed done such a thing) is incorrect.
>>>>>
>>>> Exactly.
>>>> We do our little energy budget on tigers, and find that tigers
>>>> spend more energy than they take in. Well potentially this is
>>>> dynamite. One explanation is that the law of conservation of
>>>> energy is wrong. Except, before we countenance that explanation,
>>>> we need to rule out a much simpler explanation. Which is that our
>>>> measurements are wrong.
>>>
>>> Obviously.
>>>
>>>> Similarly, PO has worked out what he thinks P(P) should be doing,
>>>> by dry-running it, and then actually run P(P) and obtained a
>>>> different result. He also found that H agreed with the dry run.
>>>> It's hard to paraphrase his conclusion, but it is extensive and
>>>> far-reaching in its implications.
>>>
>>> He is just waffling. There is no conclusion, just a constant
>>> twisting and turning to find some why to persuade people that the
>>> wrong answer is the right one. He's being doing this for years
>>> with various degrees of obfuscation.
>>>
>>> H does not report the correct result for P(P) and PO is putting up
>>> anything he can think of to keep the discussion going. It should
>>> simply have stopped once he'd been clear that H(P,P) == 0 is
>>> correct "even though P(P) halts" but the traces and the verbiage is
>>> keeping people keen.
>>>> The behaviour of code when run is different from the
>>>> correct behaviour of the code when simulated. If that's true, then
>>>> it has similar implications for computer science that disproving
>>>> the conservation law has for physics.
>>>
>>> When a student comes to me and says that her program to add 5 and 6
>>> gives 12, I don't, even for a moment, imagine that the laws of
>>> logic and mathematics are in doubt.
>>>
>>>> But the obvious explanation is that the dry-run was incorrect.
>>>> Lots of people have suggested why it is incorrect. But they can't
>>>> actually see the code. PO needs to understand that no-one will
>>>> accept the complicated, far-reaching explanation, until the simple
>>>> explanation has been ruled out.
>>>
>>> For what it's worth, I don't think there is any "dry run" going on
>>> here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
>>> because he knew (correctly) that H could spot what would happen if
>>> H did not "intervene". Everything since then -- the "it only halt
>>> because...", the "it wouldn't halt if line 15 were commented out"
>>> and the rather less explicitly stated "H_Hat does not get to its
>>> ret instruction because a non top-level H aborts" are just the
>>> various attempt at after-the-fact justification.
>>>
>>> I agree it's never quite so simple because PO is usually fractally
>>> wrong, so he's not correct about almost everything he says at almost
>>> every level. For example, at one level he now admits that a halt
>>> decider is impossible because H(X,Y) must report "on its input" and
>>> the call X(Y) is not an input! He did this to explain why H(P,P) is
>>> permitted to return 0 "even though P(P) halts", but it also makes it
>>> clear that what he one thought was that halting problem is not
>>> solvable.
>>
>> (a) and (b) are proven to be verified facts entirely on the basis of
>> the semantics of the x86 language. (Most people here do not seem to
>> "believe in" the semantics of the x86 language otherwise they would
>> have no basis to disagree).
>>
>> (a) The complete and correct x86 emulation of the input to H(P,P) by
>> H never reaches the "ret" instruction of P.
>>
>> (b) The direct execution of P(P) does reach its "ret" instruction.
>>
>> 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.
>>
>> P(P) is provably not the actual behavior of the actual input.
>
> (a) is false as the reason the ret instruction is not reached is
> incorrect: the ret instruction should not be reached due to the
> infinite loop in P and not because you abort the simulation before the
> infinite loop is reached. Your H is incorrect in its assumption that P
> is pathological because it calls H.
>
> /Flibble
>
For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-26 14:40 -0400 |
| Message-ID | <zK1uK.20102$Me2.11411@fx47.iad> |
| In reply to | #52996 |
On 6/25/22 9:36 PM, olcott wrote:
> On 6/25/2022 8:16 PM, Mr Flibble wrote:
>> On Sat, 25 Jun 2022 20:07:04 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>> "Dry run" means that a human programmer looks at the code, and
>>>>>>> determines what it does, without actually executing it.
>>>>>>
>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
>>>>>> invoked H | on it and H reports that it doesn't halt. He's run
>>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
>>>>>> (if he has indeed done such a thing) is incorrect.
>>>>> Exactly.
>>>>> We do our little energy budget on tigers, and find that tigers
>>>>> spend more energy than they take in. Well potentially this is
>>>>> dynamite. One explanation is that the law of conservation of
>>>>> energy is wrong. Except, before we countenance that explanation,
>>>>> we need to rule out a much simpler explanation. Which is that our
>>>>> measurements are wrong.
>>>>
>>>> Obviously.
>>>>> Similarly, PO has worked out what he thinks P(P) should be doing,
>>>>> by dry-running it, and then actually run P(P) and obtained a
>>>>> different result. He also found that H agreed with the dry run.
>>>>> It's hard to paraphrase his conclusion, but it is extensive and
>>>>> far-reaching in its implications.
>>>>
>>>> He is just waffling. There is no conclusion, just a constant
>>>> twisting and turning to find some why to persuade people that the
>>>> wrong answer is the right one. He's being doing this for years
>>>> with various degrees of obfuscation.
>>>>
>>>> H does not report the correct result for P(P) and PO is putting up
>>>> anything he can think of to keep the discussion going. It should
>>>> simply have stopped once he'd been clear that H(P,P) == 0 is
>>>> correct "even though P(P) halts" but the traces and the verbiage is
>>>> keeping people keen.
>>>>> The behaviour of code when run is different from the
>>>>> correct behaviour of the code when simulated. If that's true, then
>>>>> it has similar implications for computer science that disproving
>>>>> the conservation law has for physics.
>>>>
>>>> When a student comes to me and says that her program to add 5 and 6
>>>> gives 12, I don't, even for a moment, imagine that the laws of
>>>> logic and mathematics are in doubt.
>>>>> But the obvious explanation is that the dry-run was incorrect.
>>>>> Lots of people have suggested why it is incorrect. But they can't
>>>>> actually see the code. PO needs to understand that no-one will
>>>>> accept the complicated, far-reaching explanation, until the simple
>>>>> explanation has been ruled out.
>>>>
>>>> For what it's worth, I don't think there is any "dry run" going on
>>>> here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
>>>> because he knew (correctly) that H could spot what would happen if
>>>> H did not "intervene". Everything since then -- the "it only halt
>>>> because...", the "it wouldn't halt if line 15 were commented out"
>>>> and the rather less explicitly stated "H_Hat does not get to its
>>>> ret instruction because a non top-level H aborts" are just the
>>>> various attempt at after-the-fact justification.
>>>>
>>>> I agree it's never quite so simple because PO is usually fractally
>>>> wrong, so he's not correct about almost everything he says at almost
>>>> every level. For example, at one level he now admits that a halt
>>>> decider is impossible because H(X,Y) must report "on its input" and
>>>> the call X(Y) is not an input! He did this to explain why H(P,P) is
>>>> permitted to return 0 "even though P(P) halts", but it also makes it
>>>> clear that what he one thought was that halting problem is not
>>>> solvable.
>>>
>>> (a) and (b) are proven to be verified facts entirely on the basis of
>>> the semantics of the x86 language. (Most people here do not seem to
>>> "believe in" the semantics of the x86 language otherwise they would
>>> have no basis to disagree).
>>>
>>> (a) The complete and correct x86 emulation of the input to H(P,P) by
>>> H never reaches the "ret" instruction of P.
>>>
>>> (b) The direct execution of P(P) does reach its "ret" instruction.
>>>
>>> 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.
>>>
>>> P(P) is provably not the actual behavior of the actual input.
>> (a) is false as the reason the ret instruction is not reached is
>> incorrect: the ret instruction should not be reached due to the
>> infinite loop in P and not because you abort the simulation before the
>> infinite loop is reached. Your H is incorrect in its assumption that P
>> is pathological because it calls H.
>>
>> /Flibble
>>
>
> For any program H that might determine if programs halt, a
> "pathological"
> program P, called with some input, can pass its own source and its
> input to
> H and then specifically do the opposite of what H predicts P will
> do. No H
> can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
>
The problem is that your "proof" of (a) is based on an "H" that ONLY
does a complete and correct emulation of its input, before making a
halting decision.
Yes, for such an H, the P built on it will be non-halting, that that H
can't report that fact, and in fact, NEVER reports that ANY non-halting
input is non-halting. That makes it not a decider.
When you fix that problem, by having your new H abort its processing, it
is a DIFFERENT H than the one above. That difference matter, and you new
H is incorrect to consider that its input P, built on it is the same as
the P that was built on the other input H. You seem to be confused
becaue they are both called H.
You claim to be working under the intrepretaton of the C languge. The C
language PROHIBITS the presence of two functions by the same name in one
translation unit, or with global scope in the same program, sine there
is no "H with static scope listed in the file for P, it MUST be a
global scope H, and thus the only H that P can call is the one deciding
on it, which if you claim your H (P,P) is returning 0, must be the one
that aborts, and thus NOT the one that does the complete and correct
emulation and gets stuck in the infinite recursion.
It is also clear that you are lying about H doing a correct x86
emulation of its input, because at the x86 level, the call to H should
create an emulation of the x86 CODE of H, not reverting to some
"functional equivalent" converting it to a notation that it is emulating
P again. Maybe that just shows that YOU don't understand what x86
assembly code actually does. "Call H" does NOT do a emulataion at the
x86 level, it runs an emulator that it should be tracing.
THe fact that (b) shows the x86 assembly code actually does reach its
"ret" instruction means you need to point out where the emulation of the
input and the direct execution diverge, which is at the call H
instruction, which the emulation DOES'T correctly process as pointed
above, and thus your claim of a is shown to be a LIE.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-26 19:57 +0100 |
| Message-ID | <20220626195755.00003d10@reddwarf.jmc> |
| In reply to | #53011 |
On Sun, 26 Jun 2022 14:40:26 -0400
Richard Damon <Richard@Damon-Family.org> wrote:
> On 6/25/22 9:36 PM, olcott wrote:
> > On 6/25/2022 8:16 PM, Mr Flibble wrote:
> >> On Sat, 25 Jun 2022 20:07:04 -0500
> >> olcott <NoOne@NoWhere.com> wrote:
> >>
> >>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> >>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
> >>>>>
> >>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>> "Dry run" means that a human programmer looks at the code, and
> >>>>>>> determines what it does, without actually executing it.
> >>>>>>
> >>>>>> Going back, now, to what you think needs to be resolved:
> >>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
> >>>>>> invoked H | on it and H reports that it doesn't halt. He's run
> >>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
> >>>>>> (if he has indeed done such a thing) is incorrect.
> >>>>> Exactly.
> >>>>> We do our little energy budget on tigers, and find that tigers
> >>>>> spend more energy than they take in. Well potentially this is
> >>>>> dynamite. One explanation is that the law of conservation of
> >>>>> energy is wrong. Except, before we countenance that explanation,
> >>>>> we need to rule out a much simpler explanation. Which is that
> >>>>> our measurements are wrong.
> >>>>
> >>>> Obviously.
> >>>>> Similarly, PO has worked out what he thinks P(P) should be
> >>>>> doing, by dry-running it, and then actually run P(P) and
> >>>>> obtained a different result. He also found that H agreed with
> >>>>> the dry run. It's hard to paraphrase his conclusion, but it is
> >>>>> extensive and far-reaching in its implications.
> >>>>
> >>>> He is just waffling. There is no conclusion, just a constant
> >>>> twisting and turning to find some why to persuade people that the
> >>>> wrong answer is the right one. He's being doing this for years
> >>>> with various degrees of obfuscation.
> >>>>
> >>>> H does not report the correct result for P(P) and PO is putting
> >>>> up anything he can think of to keep the discussion going. It
> >>>> should simply have stopped once he'd been clear that H(P,P) == 0
> >>>> is correct "even though P(P) halts" but the traces and the
> >>>> verbiage is keeping people keen.
> >>>>> The behaviour of code when run is different from the
> >>>>> correct behaviour of the code when simulated. If that's true,
> >>>>> then it has similar implications for computer science that
> >>>>> disproving the conservation law has for physics.
> >>>>
> >>>> When a student comes to me and says that her program to add 5
> >>>> and 6 gives 12, I don't, even for a moment, imagine that the
> >>>> laws of logic and mathematics are in doubt.
> >>>>> But the obvious explanation is that the dry-run was incorrect.
> >>>>> Lots of people have suggested why it is incorrect. But they
> >>>>> can't actually see the code. PO needs to understand that no-one
> >>>>> will accept the complicated, far-reaching explanation, until
> >>>>> the simple explanation has been ruled out.
> >>>>
> >>>> For what it's worth, I don't think there is any "dry run" going
> >>>> on here at all. PO decide years ago that H(H_Hat, H_Hat) would
> >>>> be 0 because he knew (correctly) that H could spot what would
> >>>> happen if H did not "intervene". Everything since then -- the
> >>>> "it only halt because...", the "it wouldn't halt if line 15 were
> >>>> commented out" and the rather less explicitly stated "H_Hat does
> >>>> not get to its ret instruction because a non top-level H aborts"
> >>>> are just the various attempt at after-the-fact justification.
> >>>>
> >>>> I agree it's never quite so simple because PO is usually
> >>>> fractally wrong, so he's not correct about almost everything he
> >>>> says at almost every level. For example, at one level he now
> >>>> admits that a halt decider is impossible because H(X,Y) must
> >>>> report "on its input" and the call X(Y) is not an input! He did
> >>>> this to explain why H(P,P) is permitted to return 0 "even though
> >>>> P(P) halts", but it also makes it clear that what he one thought
> >>>> was that halting problem is not solvable.
> >>>
> >>> (a) and (b) are proven to be verified facts entirely on the basis
> >>> of the semantics of the x86 language. (Most people here do not
> >>> seem to "believe in" the semantics of the x86 language otherwise
> >>> they would have no basis to disagree).
> >>>
> >>> (a) The complete and correct x86 emulation of the input to H(P,P)
> >>> by H never reaches the "ret" instruction of P.
> >>>
> >>> (b) The direct execution of P(P) does reach its "ret" instruction.
> >>>
> >>> 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.
> >>>
> >>> P(P) is provably not the actual behavior of the actual input.
> >> (a) is false as the reason the ret instruction is not reached is
> >> incorrect: the ret instruction should not be reached due to the
> >> infinite loop in P and not because you abort the simulation before
> >> the infinite loop is reached. Your H is incorrect in its
> >> assumption that P is pathological because it calls H.
> >>
> >> /Flibble
> >>
> >
> > For any program H that might determine if programs halt, a
> > "pathological"
> > program P, called with some input, can pass its own source
> > and its input to
> > H and then specifically do the opposite of what H predicts P
> > will do. No H
> > can exist that handles this case.
> > https://en.wikipedia.org/wiki/Halting_problem
> >
> >
> > void P(u32 x)
> > {
> > if (H(x, x))
> > HERE: goto HERE;
> > return;
> > }
> >
> > int main()
> > {
> > Output("Input_Halts = ", H((u32)P, (u32)P));
> > }
> >
> >
>
> The problem is that your "proof" of (a) is based on an "H" that ONLY
> does a complete and correct emulation of its input, before making a
> halting decision.
>
> Yes, for such an H, the P built on it will be non-halting, that that
> H can't report that fact, and in fact, NEVER reports that ANY
> non-halting input is non-halting. That makes it not a decider.
>
> When you fix that problem, by having your new H abort its processing,
> it is a DIFFERENT H than the one above. That difference matter, and
> you new H is incorrect to consider that its input P, built on it is
> the same as the P that was built on the other input H. You seem to be
> confused becaue they are both called H.
>
> You claim to be working under the intrepretaton of the C languge. The
> C language PROHIBITS the presence of two functions by the same name
> in one translation unit, or with global scope in the same program,
> sine there is no "H with static scope listed in the file for P, it
> MUST be a global scope H, and thus the only H that P can call is the
> one deciding on it, which if you claim your H (P,P) is returning 0,
> must be the one that aborts, and thus NOT the one that does the
> complete and correct emulation and gets stuck in the infinite
> recursion.
>
> It is also clear that you are lying about H doing a correct x86
> emulation of its input, because at the x86 level, the call to H
> should create an emulation of the x86 CODE of H, not reverting to
> some "functional equivalent" converting it to a notation that it is
> emulating P again. Maybe that just shows that YOU don't understand
> what x86 assembly code actually does. "Call H" does NOT do a
> emulataion at the x86 level, it runs an emulator that it should be
> tracing.
>
> THe fact that (b) shows the x86 assembly code actually does reach its
> "ret" instruction means you need to point out where the emulation of
> the input and the direct execution diverge, which is at the call H
> instruction, which the emulation DOES'T correctly process as pointed
> above, and thus your claim of a is shown to be a LIE.
If I reply to you Olcott will see your post. :)
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-06-26 21:42 +0100 |
| Message-ID | <87r13btavb.fsf@bsb.me.uk> |
| In reply to | #53013 |
Mr Flibble <flibble@reddwarf.jmc> writes: > On Sun, 26 Jun 2022 14:40:26 -0400 > Richard Damon <Richard@Damon-Family.org> wrote: <a typically accurate refutation> > If I reply to you Olcott will see your post. :) Why would you do that?!! Being ignored by PO is blessing bestowed on very few. He's said he'll ignore me a few times but, alas, he has not yet done so. Imagine a world in which he never replies to anything you post! Of course he will never ignore every critic because talking down to people who know the subject is how he feeds his fragile sense of self-worth, but a few of us can live in hope. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-26 15:53 -0500 |
| Message-ID | <mP2dnVXLk5vDWiX_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #53026 |
On 6/26/2022 3:42 PM, Ben Bacarisse wrote: > Mr Flibble <flibble@reddwarf.jmc> writes: > >> On Sun, 26 Jun 2022 14:40:26 -0400 >> Richard Damon <Richard@Damon-Family.org> wrote: > <a typically accurate refutation> > >> If I reply to you Olcott will see your post. :) > > Why would you do that?!! Being ignored by PO is blessing bestowed on > very few. He's said he'll ignore me a few times but, alas, he has not > yet done so. Imagine a world in which he never replies to anything you > post! > > Of course he will never ignore every critic because talking down to > people who know the subject is how he feeds his fragile sense of > self-worth, but a few of us can live in hope. > Mere rhetoric is the only form of rebuttal available to those not technically qualified to provide a basis in reasoning. I don't say this as any put down, I merely want other reviewers to understand the actual truth. *This is the outline of the complete refutation* *of the only rebuttal that anyone has left* (a) and (b) are proven to be verified facts entirely on the basis of the semantics of the x86 language. (Most people here do not seem to "believe in" the semantics of the x86 language otherwise they would have no basis to disagree). (a) The complete and correct x86 emulation of the input to H(P,P) by H never reaches the "ret" instruction of P. (b) The direct execution of P(P) does reach its "ret" instruction. 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. P(P) is provably not the actual behavior of the actual input. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-25 20:58 -0500 |
| Message-ID | <SbudnW2JfoTdICr_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52984 |
On 6/25/2022 6:55 PM, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote: >>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>> >>>> "Dry run" means that a human programmer looks at the code, and determines >>>> what it does, without actually executing it. >>> >>> Going back, now, to what you think needs to be resolved: >>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H >>> | on it and H reports that it doesn't halt. He's run P(P) and it halts. >>> The obvious conclusion is that PO's dry run (if he has indeed done such >>> a thing) is incorrect. >>> >> Exactly. >> We do our little energy budget on tigers, and find that tigers spend >> more energy than they take in. Well potentially this is dynamite. One >> explanation is that the law of conservation of energy is wrong. >> Except, before we countenance that explanation, we need to rule out a >> much simpler explanation. Which is that our measurements are wrong. > > Obviously. > >> Similarly, PO has worked out what he thinks P(P) should be doing, by >> dry-running it, and then actually run P(P) and obtained a different >> result. He also found that H agreed with the dry run. It's hard to >> paraphrase his conclusion, but it is extensive and far-reaching in its >> implications. > > He is just waffling. There is no conclusion, just a constant twisting > and turning to find some why to persuade people that the wrong answer is > the right one. He's being doing this for years with various degrees of > obfuscation. > > H does not report the correct result for P(P) and PO is putting up > anything he can think of to keep the discussion going. It should simply > have stopped once he'd been clear that H(P,P) == 0 is correct "even > though P(P) halts" but the traces and the verbiage is keeping people keen. > >> The behaviour of code when run is different from the >> correct behaviour of the code when simulated. If that's true, then it >> has similar implications for computer science that disproving the >> conservation law has for physics. > > When a student comes to me and says that her program to add 5 and 6 > gives 12, I don't, even for a moment, imagine that the laws of logic and > mathematics are in doubt. > >> But the obvious explanation is that the dry-run was incorrect. Lots of >> people have suggested why it is incorrect. But they can't actually see >> the code. PO needs to understand that no-one will accept the >> complicated, far-reaching explanation, until the simple explanation >> has been ruled out. > > For what it's worth, I don't think there is any "dry run" going on here > at all. PO decide years ago that H(H_Hat, H_Hat) would be 0 because he > knew (correctly) that H could spot what would happen if H did not > "intervene". Everything since then -- the "it only halt because...", > the "it wouldn't halt if line 15 were commented out" and the rather less > explicitly stated "H_Hat does not get to its ret instruction because a > non top-level H aborts" are just the various attempt at after-the-fact > justification. > > I agree it's never quite so simple because PO is usually fractally > wrong, so he's not correct about almost everything he says at almost > every level. For example, at one level he now admits that a halt > decider is impossible because H(X,Y) must report "on its input" and the > call X(Y) is not an input! He did this to explain why H(P,P) is > permitted to return 0 "even though P(P) halts", but it also makes it > clear that what he one thought was that halting problem is not solvable. > YOU KNOW THAT THIS IS TRUE 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. BECAUSE THIS IS PROVABLY TRUE P(P) is provably not the actual behavior of the actual input. YOU ARE THE ONE FUDGING WITH THE TRUTH -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-26 03:03 +0100 |
| Message-ID | <20220626030328.00007922@reddwarf.jmc> |
| In reply to | #52998 |
On Sat, 25 Jun 2022 20:58:23 -0500 olcott <NoOne@NoWhere.com> wrote: > On 6/25/2022 6:55 PM, Ben Bacarisse wrote: > > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > >> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote: > >>> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >>> > >>>> "Dry run" means that a human programmer looks at the code, and > >>>> determines what it does, without actually executing it. > >>> > >>> Going back, now, to what you think needs to be resolved: > >>> | He's dry-run P(P) and established that it doesn't halt. He's > >>> invoked H | on it and H reports that it doesn't halt. He's run > >>> P(P) and it halts. The obvious conclusion is that PO's dry run > >>> (if he has indeed done such a thing) is incorrect. > >>> > >> Exactly. > >> We do our little energy budget on tigers, and find that tigers > >> spend more energy than they take in. Well potentially this is > >> dynamite. One explanation is that the law of conservation of > >> energy is wrong. Except, before we countenance that explanation, > >> we need to rule out a much simpler explanation. Which is that our > >> measurements are wrong. > > > > Obviously. > > > >> Similarly, PO has worked out what he thinks P(P) should be doing, > >> by dry-running it, and then actually run P(P) and obtained a > >> different result. He also found that H agreed with the dry run. > >> It's hard to paraphrase his conclusion, but it is extensive and > >> far-reaching in its implications. > > > > He is just waffling. There is no conclusion, just a constant > > twisting and turning to find some why to persuade people that the > > wrong answer is the right one. He's being doing this for years > > with various degrees of obfuscation. > > > > H does not report the correct result for P(P) and PO is putting up > > anything he can think of to keep the discussion going. It should > > simply have stopped once he'd been clear that H(P,P) == 0 is > > correct "even though P(P) halts" but the traces and the verbiage is > > keeping people keen. > >> The behaviour of code when run is different from the > >> correct behaviour of the code when simulated. If that's true, then > >> it has similar implications for computer science that disproving > >> the conservation law has for physics. > > > > When a student comes to me and says that her program to add 5 and 6 > > gives 12, I don't, even for a moment, imagine that the laws of > > logic and mathematics are in doubt. > > > >> But the obvious explanation is that the dry-run was incorrect. > >> Lots of people have suggested why it is incorrect. But they can't > >> actually see the code. PO needs to understand that no-one will > >> accept the complicated, far-reaching explanation, until the simple > >> explanation has been ruled out. > > > > For what it's worth, I don't think there is any "dry run" going on > > here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0 > > because he knew (correctly) that H could spot what would happen if > > H did not "intervene". Everything since then -- the "it only halt > > because...", the "it wouldn't halt if line 15 were commented out" > > and the rather less explicitly stated "H_Hat does not get to its > > ret instruction because a non top-level H aborts" are just the > > various attempt at after-the-fact justification. > > > > I agree it's never quite so simple because PO is usually fractally > > wrong, so he's not correct about almost everything he says at almost > > every level. For example, at one level he now admits that a halt > > decider is impossible because H(X,Y) must report "on its input" and > > the call X(Y) is not an input! He did this to explain why H(P,P) is > > permitted to return 0 "even though P(P) halts", but it also makes it > > clear that what he one thought was that halting problem is not > > solvable. > > YOU KNOW THAT THIS IS TRUE > 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. > > BECAUSE THIS IS PROVABLY TRUE > P(P) is provably not the actual behavior of the actual input. > > YOU ARE THE ONE FUDGING WITH THE TRUTH The issue is what constitutes a pathological input: the pathological input at issue here are YOUR PATHOLOGICAL LIES, Olcott. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-26 05:31 -0500 |
| Message-ID | <R8WdnXqc7LIHqCX_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52999 |
On 6/25/2022 9:03 PM, Mr Flibble wrote:
> On Sat, 25 Jun 2022 20:58:23 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> "Dry run" means that a human programmer looks at the code, and
>>>>>> determines what it does, without actually executing it.
>>>>>
>>>>> Going back, now, to what you think needs to be resolved:
>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
>>>>> invoked H | on it and H reports that it doesn't halt. He's run
>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
>>>>> (if he has indeed done such a thing) is incorrect.
>>>>>
>>>> Exactly.
>>>> We do our little energy budget on tigers, and find that tigers
>>>> spend more energy than they take in. Well potentially this is
>>>> dynamite. One explanation is that the law of conservation of
>>>> energy is wrong. Except, before we countenance that explanation,
>>>> we need to rule out a much simpler explanation. Which is that our
>>>> measurements are wrong.
>>>
>>> Obviously.
>>>
>>>> Similarly, PO has worked out what he thinks P(P) should be doing,
>>>> by dry-running it, and then actually run P(P) and obtained a
>>>> different result. He also found that H agreed with the dry run.
>>>> It's hard to paraphrase his conclusion, but it is extensive and
>>>> far-reaching in its implications.
>>>
>>> He is just waffling. There is no conclusion, just a constant
>>> twisting and turning to find some why to persuade people that the
>>> wrong answer is the right one. He's being doing this for years
>>> with various degrees of obfuscation.
>>>
>>> H does not report the correct result for P(P) and PO is putting up
>>> anything he can think of to keep the discussion going. It should
>>> simply have stopped once he'd been clear that H(P,P) == 0 is
>>> correct "even though P(P) halts" but the traces and the verbiage is
>>> keeping people keen.
>>>> The behaviour of code when run is different from the
>>>> correct behaviour of the code when simulated. If that's true, then
>>>> it has similar implications for computer science that disproving
>>>> the conservation law has for physics.
>>>
>>> When a student comes to me and says that her program to add 5 and 6
>>> gives 12, I don't, even for a moment, imagine that the laws of
>>> logic and mathematics are in doubt.
>>>
>>>> But the obvious explanation is that the dry-run was incorrect.
>>>> Lots of people have suggested why it is incorrect. But they can't
>>>> actually see the code. PO needs to understand that no-one will
>>>> accept the complicated, far-reaching explanation, until the simple
>>>> explanation has been ruled out.
>>>
>>> For what it's worth, I don't think there is any "dry run" going on
>>> here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
>>> because he knew (correctly) that H could spot what would happen if
>>> H did not "intervene". Everything since then -- the "it only halt
>>> because...", the "it wouldn't halt if line 15 were commented out"
>>> and the rather less explicitly stated "H_Hat does not get to its
>>> ret instruction because a non top-level H aborts" are just the
>>> various attempt at after-the-fact justification.
>>>
>>> I agree it's never quite so simple because PO is usually fractally
>>> wrong, so he's not correct about almost everything he says at almost
>>> every level. For example, at one level he now admits that a halt
>>> decider is impossible because H(X,Y) must report "on its input" and
>>> the call X(Y) is not an input! He did this to explain why H(P,P) is
>>> permitted to return 0 "even though P(P) halts", but it also makes it
>>> clear that what he one thought was that halting problem is not
>>> solvable.
>>
>> YOU KNOW THAT THIS IS TRUE
>> 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.
>>
>> BECAUSE THIS IS PROVABLY TRUE
>> P(P) is provably not the actual behavior of the actual input.
>>
>> YOU ARE THE ONE FUDGING WITH THE TRUTH
>
> The issue is what constitutes a pathological input: the pathological
> input at issue here are YOUR PATHOLOGICAL LIES, Olcott.
>
> /Flibble
>
Computable functions are the basic objects of study in
computability theory.
Computable functions are the formalized analogue of the intuitive
notion of
algorithms, in the sense that a function is computable if there
exists an algorithm
that can do the job of the function, i.e. given an input of the
function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
That you reject that the above proves that H and P have a pathological
relationship to each other seem to be your lack of technical competence
rather than dishonesty.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-26 12:15 +0100 |
| Message-ID | <20220626121534.00007e30@reddwarf.jmc> |
| In reply to | #53003 |
On Sun, 26 Jun 2022 05:31:53 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 6/25/2022 9:03 PM, Mr Flibble wrote:
> > On Sat, 25 Jun 2022 20:58:23 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>>
> >>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
> >>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>
> >>>>>> "Dry run" means that a human programmer looks at the code, and
> >>>>>> determines what it does, without actually executing it.
> >>>>>
> >>>>> Going back, now, to what you think needs to be resolved:
> >>>>> | He's dry-run P(P) and established that it doesn't halt. He's
> >>>>> invoked H | on it and H reports that it doesn't halt. He's run
> >>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
> >>>>> (if he has indeed done such a thing) is incorrect.
> >>>>>
> >>>> Exactly.
> >>>> We do our little energy budget on tigers, and find that tigers
> >>>> spend more energy than they take in. Well potentially this is
> >>>> dynamite. One explanation is that the law of conservation of
> >>>> energy is wrong. Except, before we countenance that explanation,
> >>>> we need to rule out a much simpler explanation. Which is that our
> >>>> measurements are wrong.
> >>>
> >>> Obviously.
> >>>
> >>>> Similarly, PO has worked out what he thinks P(P) should be doing,
> >>>> by dry-running it, and then actually run P(P) and obtained a
> >>>> different result. He also found that H agreed with the dry run.
> >>>> It's hard to paraphrase his conclusion, but it is extensive and
> >>>> far-reaching in its implications.
> >>>
> >>> He is just waffling. There is no conclusion, just a constant
> >>> twisting and turning to find some why to persuade people that the
> >>> wrong answer is the right one. He's being doing this for years
> >>> with various degrees of obfuscation.
> >>>
> >>> H does not report the correct result for P(P) and PO is putting up
> >>> anything he can think of to keep the discussion going. It should
> >>> simply have stopped once he'd been clear that H(P,P) == 0 is
> >>> correct "even though P(P) halts" but the traces and the verbiage
> >>> is keeping people keen.
> >>>> The behaviour of code when run is different from the
> >>>> correct behaviour of the code when simulated. If that's true,
> >>>> then it has similar implications for computer science that
> >>>> disproving the conservation law has for physics.
> >>>
> >>> When a student comes to me and says that her program to add 5 and
> >>> 6 gives 12, I don't, even for a moment, imagine that the laws of
> >>> logic and mathematics are in doubt.
> >>>
> >>>> But the obvious explanation is that the dry-run was incorrect.
> >>>> Lots of people have suggested why it is incorrect. But they can't
> >>>> actually see the code. PO needs to understand that no-one will
> >>>> accept the complicated, far-reaching explanation, until the
> >>>> simple explanation has been ruled out.
> >>>
> >>> For what it's worth, I don't think there is any "dry run" going on
> >>> here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
> >>> because he knew (correctly) that H could spot what would happen if
> >>> H did not "intervene". Everything since then -- the "it only halt
> >>> because...", the "it wouldn't halt if line 15 were commented out"
> >>> and the rather less explicitly stated "H_Hat does not get to its
> >>> ret instruction because a non top-level H aborts" are just the
> >>> various attempt at after-the-fact justification.
> >>>
> >>> I agree it's never quite so simple because PO is usually fractally
> >>> wrong, so he's not correct about almost everything he says at
> >>> almost every level. For example, at one level he now admits that
> >>> a halt decider is impossible because H(X,Y) must report "on its
> >>> input" and the call X(Y) is not an input! He did this to explain
> >>> why H(P,P) is permitted to return 0 "even though P(P) halts", but
> >>> it also makes it clear that what he one thought was that halting
> >>> problem is not solvable.
> >>
> >> YOU KNOW THAT THIS IS TRUE
> >> 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.
> >>
> >> BECAUSE THIS IS PROVABLY TRUE
> >> P(P) is provably not the actual behavior of the actual input.
> >>
> >> YOU ARE THE ONE FUDGING WITH THE TRUTH
> >
> > The issue is what constitutes a pathological input: the pathological
> > input at issue here are YOUR PATHOLOGICAL LIES, Olcott.
> >
> > /Flibble
> >
>
> Computable functions are the basic objects of study in
> computability theory.
> Computable functions are the formalized analogue of the
> intuitive notion of
> algorithms, in the sense that a function is computable if there
> exists an algorithm
> that can do the job of the function, i.e. given an input of the
> function domain it
> can return the corresponding output.
> https://en.wikipedia.org/wiki/Computable_function
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> That you reject that the above proves that H and P have a
> pathological relationship to each other seem to be your lack of
> technical competence rather than dishonesty.
There is nothing wrong with my technical competence however yours *is*
suspect.
Nobody is denying that P is pathological input as its comes
from [Strachey, 1965]'s "Impossible Program"; the problem is you
are redefining what H means such that P no longer calls H as you prevent
that call which is equivalent to H behaving differently depending on
what is calling it: valid halt deciders don't do that. Your H is
erroneous and certainly *not* a pure function as you claim.
Your basic error (which you keep repeating) is your assumption that a
program that calls H is always pathological.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-26 11:27 -0500 |
| Message-ID | <xridnT9kGf5GFSX_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #53005 |
On 6/26/2022 6:15 AM, Mr Flibble wrote:
> On Sun, 26 Jun 2022 05:31:53 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 9:03 PM, Mr Flibble wrote:
>>> On Sat, 25 Jun 2022 20:58:23 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>
>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> "Dry run" means that a human programmer looks at the code, and
>>>>>>>> determines what it does, without actually executing it.
>>>>>>>
>>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
>>>>>>> invoked H | on it and H reports that it doesn't halt. He's run
>>>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
>>>>>>> (if he has indeed done such a thing) is incorrect.
>>>>>>>
>>>>>> Exactly.
>>>>>> We do our little energy budget on tigers, and find that tigers
>>>>>> spend more energy than they take in. Well potentially this is
>>>>>> dynamite. One explanation is that the law of conservation of
>>>>>> energy is wrong. Except, before we countenance that explanation,
>>>>>> we need to rule out a much simpler explanation. Which is that our
>>>>>> measurements are wrong.
>>>>>
>>>>> Obviously.
>>>>>
>>>>>> Similarly, PO has worked out what he thinks P(P) should be doing,
>>>>>> by dry-running it, and then actually run P(P) and obtained a
>>>>>> different result. He also found that H agreed with the dry run.
>>>>>> It's hard to paraphrase his conclusion, but it is extensive and
>>>>>> far-reaching in its implications.
>>>>>
>>>>> He is just waffling. There is no conclusion, just a constant
>>>>> twisting and turning to find some why to persuade people that the
>>>>> wrong answer is the right one. He's being doing this for years
>>>>> with various degrees of obfuscation.
>>>>>
>>>>> H does not report the correct result for P(P) and PO is putting up
>>>>> anything he can think of to keep the discussion going. It should
>>>>> simply have stopped once he'd been clear that H(P,P) == 0 is
>>>>> correct "even though P(P) halts" but the traces and the verbiage
>>>>> is keeping people keen.
>>>>>> The behaviour of code when run is different from the
>>>>>> correct behaviour of the code when simulated. If that's true,
>>>>>> then it has similar implications for computer science that
>>>>>> disproving the conservation law has for physics.
>>>>>
>>>>> When a student comes to me and says that her program to add 5 and
>>>>> 6 gives 12, I don't, even for a moment, imagine that the laws of
>>>>> logic and mathematics are in doubt.
>>>>>
>>>>>> But the obvious explanation is that the dry-run was incorrect.
>>>>>> Lots of people have suggested why it is incorrect. But they can't
>>>>>> actually see the code. PO needs to understand that no-one will
>>>>>> accept the complicated, far-reaching explanation, until the
>>>>>> simple explanation has been ruled out.
>>>>>
>>>>> For what it's worth, I don't think there is any "dry run" going on
>>>>> here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
>>>>> because he knew (correctly) that H could spot what would happen if
>>>>> H did not "intervene". Everything since then -- the "it only halt
>>>>> because...", the "it wouldn't halt if line 15 were commented out"
>>>>> and the rather less explicitly stated "H_Hat does not get to its
>>>>> ret instruction because a non top-level H aborts" are just the
>>>>> various attempt at after-the-fact justification.
>>>>>
>>>>> I agree it's never quite so simple because PO is usually fractally
>>>>> wrong, so he's not correct about almost everything he says at
>>>>> almost every level. For example, at one level he now admits that
>>>>> a halt decider is impossible because H(X,Y) must report "on its
>>>>> input" and the call X(Y) is not an input! He did this to explain
>>>>> why H(P,P) is permitted to return 0 "even though P(P) halts", but
>>>>> it also makes it clear that what he one thought was that halting
>>>>> problem is not solvable.
>>>>
>>>> YOU KNOW THAT THIS IS TRUE
>>>> 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.
>>>>
>>>> BECAUSE THIS IS PROVABLY TRUE
>>>> P(P) is provably not the actual behavior of the actual input.
>>>>
>>>> YOU ARE THE ONE FUDGING WITH THE TRUTH
>>>
>>> The issue is what constitutes a pathological input: the pathological
>>> input at issue here are YOUR PATHOLOGICAL LIES, Olcott.
>>>
>>> /Flibble
>>>
>>
>> Computable functions are the basic objects of study in
>> computability theory.
>> Computable functions are the formalized analogue of the
>> intuitive notion of
>> algorithms, in the sense that a function is computable if there
>> exists an algorithm
>> that can do the job of the function, i.e. given an input of the
>> function domain it
>> can return the corresponding output.
>> https://en.wikipedia.org/wiki/Computable_function
>>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>>
>> That you reject that the above proves that H and P have a
>> pathological relationship to each other seem to be your lack of
>> technical competence rather than dishonesty.
>
> There is nothing wrong with my technical competence however yours *is*
> suspect.
>
> Nobody is denying that P is pathological input as its comes
> from [Strachey, 1965]'s "Impossible Program";
// rec routine P
// §L :if T[P] go to L
// Return §
// https://academic.oup.com/comjnl/article/7/4/313/354243
void Strachey_P()
{
L:if (T(Strachey_P))
goto L;
return;
}
int main()
{
Output("Input_Halts = ", T(Strachey_P));
}
_Strachey_P()
[000015b2](01) 55 push ebp
[000015b3](02) 8bec mov ebp,esp
[000015b5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015ba](05) e813fdffff call 000012d2 // call T
[000015bf](03) 83c404 add esp,+04
[000015c2](02) 85c0 test eax,eax
[000015c4](02) 7402 jz 000015c8
[000015c6](02) ebed jmp 000015b5
[000015c8](01) 5d pop ebp
[000015c9](01) c3 ret
Size in bytes:(0024) [000015c9]
_main()
[000015d2](01) 55 push ebp
[000015d3](02) 8bec mov ebp,esp
[000015d5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015da](05) e8f3fcffff call 000012d2 // call T
[000015df](03) 83c404 add esp,+04
[000015e2](01) 50 push eax
[000015e3](05) 6833040000 push 00000433
[000015e8](05) e895eeffff call 00000482
[000015ed](03) 83c408 add esp,+08
[000015f0](02) 33c0 xor eax,eax
[000015f2](01) 5d pop ebp
[000015f3](01) c3 ret
Size in bytes:(0034) [000015f3]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000015d2][001025c6][00000000] 55 push ebp
[000015d3][001025c6][00000000] 8bec mov ebp,esp
[000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push Strachey_P
[000015da][001025be][000015df] e8f3fcffff call 000012d2 // call T
Begin Simulation Execution Trace Stored at:21267a
Address_of_T:12d2
[000015b2][0021266a][0021266e] 55 push ebp
[000015b3][0021266a][0021266e] 8bec mov ebp,esp
[000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push Strachey_P
[000015ba][00212662][000015bf] e813fdffff call 000012d2 // call T
Infinitely Recursive Simulation Detected Simulation Stopped
T knows its own machine address and on this basis it can easily
examine its stored execution_trace of Strachey_P (see above) to determine:
(a) Strachey_P is calling T with the same arguments that T was called with.
(b) No instructions in Strachey_P could possibly escape this otherwise
infinitely recursive emulation.
(c) T aborts its emulation of Strachey_P before its call to T is emulated.
[000015df][001025c6][00000000] 83c404 add esp,+04
[000015e2][001025c2][00000000] 50 push eax
[000015e3][001025be][00000433] 6833040000 push 00000433
[000015e8][001025be][00000433] e895eeffff call 00000482
Input_Halts = 0
[000015ed][001025c6][00000000] 83c408 add esp,+08
[000015f0][001025c6][00000000] 33c0 xor eax,eax
[000015f2][001025ca][00100000] 5d pop ebp
[000015f3][001025ce][00000004] c3 ret
Number of Instructions Executed(528) == 8 Pages
> the problem is you
> are redefining what H means such that P no longer calls H as you prevent
> that call which is equivalent to H behaving differently depending on
> what is calling it: valid halt deciders don't do that. Your H is
> erroneous and certainly *not* a pure function as you claim.
>
Simulating halt deciders must abort their simulation of their input at
some point after they have correctly determined that the simulation
would not otherwise stop running.
Only simulating halt deciders can correctly determine the halt status of
pathological inputs.
Pure function
In computer programming, a pure function is a function that has the
following properties:
(1) the function return values are identical for identical arguments
(no variation with local static variables, non-local variables,
mutable reference arguments or input streams), and
[Meaning that the return values do not vary on the
basis of local static variables, non-local variables,
mutable reference arguments or input streams].
(2) the function application has no side effects (no mutation of
local static variables, non-local variables, mutable reference
arguments or input/output streams).
[Meaning that function application does not mutate
local static variables, non-local variables,
mutable reference arguments or input/output streams].
https://en.wikipedia.org/wiki/Pure_function
> Your basic error (which you keep repeating) is your assumption that a
> program that calls H is always pathological.
>
> /Flibble
>
I make no assumptions.
You fail to correctly recognize pathological self-reference.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-26 20:00 +0100 |
| Message-ID | <20220626200003.00005a2f@reddwarf.jmc> |
| In reply to | #53010 |
On Sun, 26 Jun 2022 11:27:06 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 6/26/2022 6:15 AM, Mr Flibble wrote:
> > On Sun, 26 Jun 2022 05:31:53 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/25/2022 9:03 PM, Mr Flibble wrote:
> >>> On Sat, 25 Jun 2022 20:58:23 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> >>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>>>>
> >>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
> >>>>>> wrote:
> >>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>
> >>>>>>>> "Dry run" means that a human programmer looks at the code,
> >>>>>>>> and determines what it does, without actually executing it.
> >>>>>>>
> >>>>>>> Going back, now, to what you think needs to be resolved:
> >>>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
> >>>>>>> invoked H | on it and H reports that it doesn't halt. He's run
> >>>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
> >>>>>>> (if he has indeed done such a thing) is incorrect.
> >>>>>>>
> >>>>>> Exactly.
> >>>>>> We do our little energy budget on tigers, and find that tigers
> >>>>>> spend more energy than they take in. Well potentially this is
> >>>>>> dynamite. One explanation is that the law of conservation of
> >>>>>> energy is wrong. Except, before we countenance that
> >>>>>> explanation, we need to rule out a much simpler explanation.
> >>>>>> Which is that our measurements are wrong.
> >>>>>
> >>>>> Obviously.
> >>>>>
> >>>>>> Similarly, PO has worked out what he thinks P(P) should be
> >>>>>> doing, by dry-running it, and then actually run P(P) and
> >>>>>> obtained a different result. He also found that H agreed with
> >>>>>> the dry run. It's hard to paraphrase his conclusion, but it is
> >>>>>> extensive and far-reaching in its implications.
> >>>>>
> >>>>> He is just waffling. There is no conclusion, just a constant
> >>>>> twisting and turning to find some why to persuade people that
> >>>>> the wrong answer is the right one. He's being doing this for
> >>>>> years with various degrees of obfuscation.
> >>>>>
> >>>>> H does not report the correct result for P(P) and PO is putting
> >>>>> up anything he can think of to keep the discussion going. It
> >>>>> should simply have stopped once he'd been clear that H(P,P) ==
> >>>>> 0 is correct "even though P(P) halts" but the traces and the
> >>>>> verbiage is keeping people keen.
> >>>>>> The behaviour of code when run is different from the
> >>>>>> correct behaviour of the code when simulated. If that's true,
> >>>>>> then it has similar implications for computer science that
> >>>>>> disproving the conservation law has for physics.
> >>>>>
> >>>>> When a student comes to me and says that her program to add 5
> >>>>> and 6 gives 12, I don't, even for a moment, imagine that the
> >>>>> laws of logic and mathematics are in doubt.
> >>>>>
> >>>>>> But the obvious explanation is that the dry-run was incorrect.
> >>>>>> Lots of people have suggested why it is incorrect. But they
> >>>>>> can't actually see the code. PO needs to understand that
> >>>>>> no-one will accept the complicated, far-reaching explanation,
> >>>>>> until the simple explanation has been ruled out.
> >>>>>
> >>>>> For what it's worth, I don't think there is any "dry run" going
> >>>>> on here at all. PO decide years ago that H(H_Hat, H_Hat) would
> >>>>> be 0 because he knew (correctly) that H could spot what would
> >>>>> happen if H did not "intervene". Everything since then -- the
> >>>>> "it only halt because...", the "it wouldn't halt if line 15
> >>>>> were commented out" and the rather less explicitly stated
> >>>>> "H_Hat does not get to its ret instruction because a non
> >>>>> top-level H aborts" are just the various attempt at
> >>>>> after-the-fact justification.
> >>>>>
> >>>>> I agree it's never quite so simple because PO is usually
> >>>>> fractally wrong, so he's not correct about almost everything he
> >>>>> says at almost every level. For example, at one level he now
> >>>>> admits that a halt decider is impossible because H(X,Y) must
> >>>>> report "on its input" and the call X(Y) is not an input! He
> >>>>> did this to explain why H(P,P) is permitted to return 0 "even
> >>>>> though P(P) halts", but it also makes it clear that what he one
> >>>>> thought was that halting problem is not solvable.
> >>>>
> >>>> YOU KNOW THAT THIS IS TRUE
> >>>> 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.
> >>>>
> >>>> BECAUSE THIS IS PROVABLY TRUE
> >>>> P(P) is provably not the actual behavior of the actual input.
> >>>>
> >>>> YOU ARE THE ONE FUDGING WITH THE TRUTH
> >>>
> >>> The issue is what constitutes a pathological input: the
> >>> pathological input at issue here are YOUR PATHOLOGICAL LIES,
> >>> Olcott.
> >>>
> >>> /Flibble
> >>>
> >>
> >> Computable functions are the basic objects of study in
> >> computability theory.
> >> Computable functions are the formalized analogue of the
> >> intuitive notion of
> >> algorithms, in the sense that a function is computable if
> >> there exists an algorithm
> >> that can do the job of the function, i.e. given an input of
> >> the function domain it
> >> can return the corresponding output.
> >> https://en.wikipedia.org/wiki/Computable_function
> >>
> >> void P(u32 x)
> >> {
> >> if (H(x, x))
> >> HERE: goto HERE;
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H((u32)P, (u32)P));
> >> }
> >>
> >> That you reject that the above proves that H and P have a
> >> pathological relationship to each other seem to be your lack of
> >> technical competence rather than dishonesty.
> >
> > There is nothing wrong with my technical competence however yours
> > *is* suspect.
> >
> > Nobody is denying that P is pathological input as its comes
> > from [Strachey, 1965]'s "Impossible Program";
>
> // rec routine P
> // §L :if T[P] go to L
> // Return §
> // https://academic.oup.com/comjnl/article/7/4/313/354243
> void Strachey_P()
> {
> L:if (T(Strachey_P))
> goto L;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", T(Strachey_P));
> }
>
> _Strachey_P()
> [000015b2](01) 55 push ebp
> [000015b3](02) 8bec mov ebp,esp
> [000015b5](05) 68b2150000 push 000015b2 // push Strachey_P
> [000015ba](05) e813fdffff call 000012d2 // call T
> [000015bf](03) 83c404 add esp,+04
> [000015c2](02) 85c0 test eax,eax
> [000015c4](02) 7402 jz 000015c8
> [000015c6](02) ebed jmp 000015b5
> [000015c8](01) 5d pop ebp
> [000015c9](01) c3 ret
> Size in bytes:(0024) [000015c9]
>
> _main()
> [000015d2](01) 55 push ebp
> [000015d3](02) 8bec mov ebp,esp
> [000015d5](05) 68b2150000 push 000015b2 // push Strachey_P
> [000015da](05) e8f3fcffff call 000012d2 // call T
> [000015df](03) 83c404 add esp,+04
> [000015e2](01) 50 push eax
> [000015e3](05) 6833040000 push 00000433
> [000015e8](05) e895eeffff call 00000482
> [000015ed](03) 83c408 add esp,+08
> [000015f0](02) 33c0 xor eax,eax
> [000015f2](01) 5d pop ebp
> [000015f3](01) c3 ret
> Size in bytes:(0034) [000015f3]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [000015d2][001025c6][00000000] 55 push ebp
> [000015d3][001025c6][00000000] 8bec mov ebp,esp
> [000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push
> Strachey_P [000015da][001025be][000015df] e8f3fcffff call 000012d2 //
> call T
>
> Begin Simulation Execution Trace Stored at:21267a
> Address_of_T:12d2
> [000015b2][0021266a][0021266e] 55 push ebp
> [000015b3][0021266a][0021266e] 8bec mov ebp,esp
> [000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push
> Strachey_P [000015ba][00212662][000015bf] e813fdffff call 000012d2 //
> call T Infinitely Recursive Simulation Detected Simulation Stopped
>
> T knows its own machine address and on this basis it can easily
> examine its stored execution_trace of Strachey_P (see above) to
> determine: (a) Strachey_P is calling T with the same arguments that T
> was called with. (b) No instructions in Strachey_P could possibly
> escape this otherwise infinitely recursive emulation.
There is no recursion in [Strachey, 1965] or the proofs based on it
that you are attempting to refute. Fail.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-26 14:11 -0500 |
| Message-ID | <g66dneEaUuTaMiX_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #53014 |
On 6/26/2022 2:00 PM, Mr Flibble wrote:
> On Sun, 26 Jun 2022 11:27:06 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/26/2022 6:15 AM, Mr Flibble wrote:
>>> On Sun, 26 Jun 2022 05:31:53 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/25/2022 9:03 PM, Mr Flibble wrote:
>>>>> On Sat, 25 Jun 2022 20:58:23 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>>
>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
>>>>>>>> wrote:
>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> "Dry run" means that a human programmer looks at the code,
>>>>>>>>>> and determines what it does, without actually executing it.
>>>>>>>>>
>>>>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
>>>>>>>>> invoked H | on it and H reports that it doesn't halt. He's run
>>>>>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
>>>>>>>>> (if he has indeed done such a thing) is incorrect.
>>>>>>>>>
>>>>>>>> Exactly.
>>>>>>>> We do our little energy budget on tigers, and find that tigers
>>>>>>>> spend more energy than they take in. Well potentially this is
>>>>>>>> dynamite. One explanation is that the law of conservation of
>>>>>>>> energy is wrong. Except, before we countenance that
>>>>>>>> explanation, we need to rule out a much simpler explanation.
>>>>>>>> Which is that our measurements are wrong.
>>>>>>>
>>>>>>> Obviously.
>>>>>>>
>>>>>>>> Similarly, PO has worked out what he thinks P(P) should be
>>>>>>>> doing, by dry-running it, and then actually run P(P) and
>>>>>>>> obtained a different result. He also found that H agreed with
>>>>>>>> the dry run. It's hard to paraphrase his conclusion, but it is
>>>>>>>> extensive and far-reaching in its implications.
>>>>>>>
>>>>>>> He is just waffling. There is no conclusion, just a constant
>>>>>>> twisting and turning to find some why to persuade people that
>>>>>>> the wrong answer is the right one. He's being doing this for
>>>>>>> years with various degrees of obfuscation.
>>>>>>>
>>>>>>> H does not report the correct result for P(P) and PO is putting
>>>>>>> up anything he can think of to keep the discussion going. It
>>>>>>> should simply have stopped once he'd been clear that H(P,P) ==
>>>>>>> 0 is correct "even though P(P) halts" but the traces and the
>>>>>>> verbiage is keeping people keen.
>>>>>>>> The behaviour of code when run is different from the
>>>>>>>> correct behaviour of the code when simulated. If that's true,
>>>>>>>> then it has similar implications for computer science that
>>>>>>>> disproving the conservation law has for physics.
>>>>>>>
>>>>>>> When a student comes to me and says that her program to add 5
>>>>>>> and 6 gives 12, I don't, even for a moment, imagine that the
>>>>>>> laws of logic and mathematics are in doubt.
>>>>>>>
>>>>>>>> But the obvious explanation is that the dry-run was incorrect.
>>>>>>>> Lots of people have suggested why it is incorrect. But they
>>>>>>>> can't actually see the code. PO needs to understand that
>>>>>>>> no-one will accept the complicated, far-reaching explanation,
>>>>>>>> until the simple explanation has been ruled out.
>>>>>>>
>>>>>>> For what it's worth, I don't think there is any "dry run" going
>>>>>>> on here at all. PO decide years ago that H(H_Hat, H_Hat) would
>>>>>>> be 0 because he knew (correctly) that H could spot what would
>>>>>>> happen if H did not "intervene". Everything since then -- the
>>>>>>> "it only halt because...", the "it wouldn't halt if line 15
>>>>>>> were commented out" and the rather less explicitly stated
>>>>>>> "H_Hat does not get to its ret instruction because a non
>>>>>>> top-level H aborts" are just the various attempt at
>>>>>>> after-the-fact justification.
>>>>>>>
>>>>>>> I agree it's never quite so simple because PO is usually
>>>>>>> fractally wrong, so he's not correct about almost everything he
>>>>>>> says at almost every level. For example, at one level he now
>>>>>>> admits that a halt decider is impossible because H(X,Y) must
>>>>>>> report "on its input" and the call X(Y) is not an input! He
>>>>>>> did this to explain why H(P,P) is permitted to return 0 "even
>>>>>>> though P(P) halts", but it also makes it clear that what he one
>>>>>>> thought was that halting problem is not solvable.
>>>>>>
>>>>>> YOU KNOW THAT THIS IS TRUE
>>>>>> 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.
>>>>>>
>>>>>> BECAUSE THIS IS PROVABLY TRUE
>>>>>> P(P) is provably not the actual behavior of the actual input.
>>>>>>
>>>>>> YOU ARE THE ONE FUDGING WITH THE TRUTH
>>>>>
>>>>> The issue is what constitutes a pathological input: the
>>>>> pathological input at issue here are YOUR PATHOLOGICAL LIES,
>>>>> Olcott.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> Computable functions are the basic objects of study in
>>>> computability theory.
>>>> Computable functions are the formalized analogue of the
>>>> intuitive notion of
>>>> algorithms, in the sense that a function is computable if
>>>> there exists an algorithm
>>>> that can do the job of the function, i.e. given an input of
>>>> the function domain it
>>>> can return the corresponding output.
>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> That you reject that the above proves that H and P have a
>>>> pathological relationship to each other seem to be your lack of
>>>> technical competence rather than dishonesty.
>>>
>>> There is nothing wrong with my technical competence however yours
>>> *is* suspect.
>>>
>>> Nobody is denying that P is pathological input as its comes
>>> from [Strachey, 1965]'s "Impossible Program";
>>
>> // rec routine P
>> // §L :if T[P] go to L
>> // Return §
>> // https://academic.oup.com/comjnl/article/7/4/313/354243
>> void Strachey_P()
>> {
>> L:if (T(Strachey_P))
>> goto L;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", T(Strachey_P));
>> }
>>
>> _Strachey_P()
>> [000015b2](01) 55 push ebp
>> [000015b3](02) 8bec mov ebp,esp
>> [000015b5](05) 68b2150000 push 000015b2 // push Strachey_P
>> [000015ba](05) e813fdffff call 000012d2 // call T
>> [000015bf](03) 83c404 add esp,+04
>> [000015c2](02) 85c0 test eax,eax
>> [000015c4](02) 7402 jz 000015c8
>> [000015c6](02) ebed jmp 000015b5
>> [000015c8](01) 5d pop ebp
>> [000015c9](01) c3 ret
>> Size in bytes:(0024) [000015c9]
>>
>> _main()
>> [000015d2](01) 55 push ebp
>> [000015d3](02) 8bec mov ebp,esp
>> [000015d5](05) 68b2150000 push 000015b2 // push Strachey_P
>> [000015da](05) e8f3fcffff call 000012d2 // call T
>> [000015df](03) 83c404 add esp,+04
>> [000015e2](01) 50 push eax
>> [000015e3](05) 6833040000 push 00000433
>> [000015e8](05) e895eeffff call 00000482
>> [000015ed](03) 83c408 add esp,+08
>> [000015f0](02) 33c0 xor eax,eax
>> [000015f2](01) 5d pop ebp
>> [000015f3](01) c3 ret
>> Size in bytes:(0034) [000015f3]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [000015d2][001025c6][00000000] 55 push ebp
>> [000015d3][001025c6][00000000] 8bec mov ebp,esp
>> [000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push
>> Strachey_P [000015da][001025be][000015df] e8f3fcffff call 000012d2 //
>> call T
>>
>> Begin Simulation Execution Trace Stored at:21267a
>> Address_of_T:12d2
>> [000015b2][0021266a][0021266e] 55 push ebp
>> [000015b3][0021266a][0021266e] 8bec mov ebp,esp
>> [000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push
>> Strachey_P [000015ba][00212662][000015bf] e813fdffff call 000012d2 //
>> call T Infinitely Recursive Simulation Detected Simulation Stopped
>>
>> T knows its own machine address and on this basis it can easily
>> examine its stored execution_trace of Strachey_P (see above) to
>> determine: (a) Strachey_P is calling T with the same arguments that T
>> was called with. (b) No instructions in Strachey_P could possibly
>> escape this otherwise infinitely recursive emulation.
>
> There is no recursion in [Strachey, 1965] or the proofs based on it
> that you are attempting to refute. Fail.
>
> /Flibble
>
In other words you are saying that because a non-simulating halt decider
(that has no recursive emulation) cannot correctly determine the halt
status of its input that a simulating halt decider (that has recursive
emulation) cannot correctly determine the halt status of its input.
In other words if there are no black dogs in the kitchen this proves
that there are no white cats in the living room.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-26 20:26 +0100 |
| Message-ID | <20220626202610.000048d3@reddwarf.jmc> |
| In reply to | #53017 |
On Sun, 26 Jun 2022 14:11:02 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 6/26/2022 2:00 PM, Mr Flibble wrote:
> > On Sun, 26 Jun 2022 11:27:06 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/26/2022 6:15 AM, Mr Flibble wrote:
> >>> On Sun, 26 Jun 2022 05:31:53 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/25/2022 9:03 PM, Mr Flibble wrote:
> >>>>> On Sat, 25 Jun 2022 20:58:23 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> >>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>>>>>>
> >>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
> >>>>>>>> wrote:
> >>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>>>
> >>>>>>>>>> "Dry run" means that a human programmer looks at the code,
> >>>>>>>>>> and determines what it does, without actually executing
> >>>>>>>>>> it.
> >>>>>>>>>
> >>>>>>>>> Going back, now, to what you think needs to be resolved:
> >>>>>>>>> | He's dry-run P(P) and established that it doesn't halt.
> >>>>>>>>> He's invoked H | on it and H reports that it doesn't halt.
> >>>>>>>>> He's run P(P) and it halts. The obvious conclusion is that
> >>>>>>>>> PO's dry run (if he has indeed done such a thing) is
> >>>>>>>>> incorrect.
> >>>>>>>> Exactly.
> >>>>>>>> We do our little energy budget on tigers, and find that
> >>>>>>>> tigers spend more energy than they take in. Well potentially
> >>>>>>>> this is dynamite. One explanation is that the law of
> >>>>>>>> conservation of energy is wrong. Except, before we
> >>>>>>>> countenance that explanation, we need to rule out a much
> >>>>>>>> simpler explanation. Which is that our measurements are
> >>>>>>>> wrong.
> >>>>>>>
> >>>>>>> Obviously.
> >>>>>>>
> >>>>>>>> Similarly, PO has worked out what he thinks P(P) should be
> >>>>>>>> doing, by dry-running it, and then actually run P(P) and
> >>>>>>>> obtained a different result. He also found that H agreed with
> >>>>>>>> the dry run. It's hard to paraphrase his conclusion, but it
> >>>>>>>> is extensive and far-reaching in its implications.
> >>>>>>>
> >>>>>>> He is just waffling. There is no conclusion, just a constant
> >>>>>>> twisting and turning to find some why to persuade people that
> >>>>>>> the wrong answer is the right one. He's being doing this for
> >>>>>>> years with various degrees of obfuscation.
> >>>>>>>
> >>>>>>> H does not report the correct result for P(P) and PO is
> >>>>>>> putting up anything he can think of to keep the discussion
> >>>>>>> going. It should simply have stopped once he'd been clear
> >>>>>>> that H(P,P) == 0 is correct "even though P(P) halts" but the
> >>>>>>> traces and the verbiage is keeping people keen.
> >>>>>>>> The behaviour of code when run is different from the
> >>>>>>>> correct behaviour of the code when simulated. If that's true,
> >>>>>>>> then it has similar implications for computer science that
> >>>>>>>> disproving the conservation law has for physics.
> >>>>>>>
> >>>>>>> When a student comes to me and says that her program to add 5
> >>>>>>> and 6 gives 12, I don't, even for a moment, imagine that the
> >>>>>>> laws of logic and mathematics are in doubt.
> >>>>>>>
> >>>>>>>> But the obvious explanation is that the dry-run was
> >>>>>>>> incorrect. Lots of people have suggested why it is
> >>>>>>>> incorrect. But they can't actually see the code. PO needs to
> >>>>>>>> understand that no-one will accept the complicated,
> >>>>>>>> far-reaching explanation, until the simple explanation has
> >>>>>>>> been ruled out.
> >>>>>>>
> >>>>>>> For what it's worth, I don't think there is any "dry run"
> >>>>>>> going on here at all. PO decide years ago that H(H_Hat,
> >>>>>>> H_Hat) would be 0 because he knew (correctly) that H could
> >>>>>>> spot what would happen if H did not "intervene". Everything
> >>>>>>> since then -- the "it only halt because...", the "it wouldn't
> >>>>>>> halt if line 15 were commented out" and the rather less
> >>>>>>> explicitly stated "H_Hat does not get to its ret instruction
> >>>>>>> because a non top-level H aborts" are just the various
> >>>>>>> attempt at after-the-fact justification.
> >>>>>>>
> >>>>>>> I agree it's never quite so simple because PO is usually
> >>>>>>> fractally wrong, so he's not correct about almost everything
> >>>>>>> he says at almost every level. For example, at one level he
> >>>>>>> now admits that a halt decider is impossible because H(X,Y)
> >>>>>>> must report "on its input" and the call X(Y) is not an input!
> >>>>>>> He did this to explain why H(P,P) is permitted to return 0
> >>>>>>> "even though P(P) halts", but it also makes it clear that
> >>>>>>> what he one thought was that halting problem is not solvable.
> >>>>>>>
> >>>>>>
> >>>>>> YOU KNOW THAT THIS IS TRUE
> >>>>>> 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.
> >>>>>>
> >>>>>> BECAUSE THIS IS PROVABLY TRUE
> >>>>>> P(P) is provably not the actual behavior of the actual input.
> >>>>>>
> >>>>>> YOU ARE THE ONE FUDGING WITH THE TRUTH
> >>>>>
> >>>>> The issue is what constitutes a pathological input: the
> >>>>> pathological input at issue here are YOUR PATHOLOGICAL LIES,
> >>>>> Olcott.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> Computable functions are the basic objects of study in
> >>>> computability theory.
> >>>> Computable functions are the formalized analogue of the
> >>>> intuitive notion of
> >>>> algorithms, in the sense that a function is computable if
> >>>> there exists an algorithm
> >>>> that can do the job of the function, i.e. given an input
> >>>> of the function domain it
> >>>> can return the corresponding output.
> >>>> https://en.wikipedia.org/wiki/Computable_function
> >>>>
> >>>> void P(u32 x)
> >>>> {
> >>>> if (H(x, x))
> >>>> HERE: goto HERE;
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>> }
> >>>>
> >>>> That you reject that the above proves that H and P have a
> >>>> pathological relationship to each other seem to be your lack of
> >>>> technical competence rather than dishonesty.
> >>>
> >>> There is nothing wrong with my technical competence however yours
> >>> *is* suspect.
> >>>
> >>> Nobody is denying that P is pathological input as its comes
> >>> from [Strachey, 1965]'s "Impossible Program";
> >>
> >> // rec routine P
> >> // §L :if T[P] go to L
> >> // Return §
> >> // https://academic.oup.com/comjnl/article/7/4/313/354243
> >> void Strachey_P()
> >> {
> >> L:if (T(Strachey_P))
> >> goto L;
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", T(Strachey_P));
> >> }
> >>
> >> _Strachey_P()
> >> [000015b2](01) 55 push ebp
> >> [000015b3](02) 8bec mov ebp,esp
> >> [000015b5](05) 68b2150000 push 000015b2 // push Strachey_P
> >> [000015ba](05) e813fdffff call 000012d2 // call T
> >> [000015bf](03) 83c404 add esp,+04
> >> [000015c2](02) 85c0 test eax,eax
> >> [000015c4](02) 7402 jz 000015c8
> >> [000015c6](02) ebed jmp 000015b5
> >> [000015c8](01) 5d pop ebp
> >> [000015c9](01) c3 ret
> >> Size in bytes:(0024) [000015c9]
> >>
> >> _main()
> >> [000015d2](01) 55 push ebp
> >> [000015d3](02) 8bec mov ebp,esp
> >> [000015d5](05) 68b2150000 push 000015b2 // push Strachey_P
> >> [000015da](05) e8f3fcffff call 000012d2 // call T
> >> [000015df](03) 83c404 add esp,+04
> >> [000015e2](01) 50 push eax
> >> [000015e3](05) 6833040000 push 00000433
> >> [000015e8](05) e895eeffff call 00000482
> >> [000015ed](03) 83c408 add esp,+08
> >> [000015f0](02) 33c0 xor eax,eax
> >> [000015f2](01) 5d pop ebp
> >> [000015f3](01) c3 ret
> >> Size in bytes:(0034) [000015f3]
> >>
> >> machine stack stack machine assembly
> >> address address data code language
> >> ======== ======== ======== ========= =============
> >> [000015d2][001025c6][00000000] 55 push ebp
> >> [000015d3][001025c6][00000000] 8bec mov ebp,esp
> >> [000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push
> >> Strachey_P [000015da][001025be][000015df] e8f3fcffff call 000012d2
> >> // call T
> >>
> >> Begin Simulation Execution Trace Stored at:21267a
> >> Address_of_T:12d2
> >> [000015b2][0021266a][0021266e] 55 push ebp
> >> [000015b3][0021266a][0021266e] 8bec mov ebp,esp
> >> [000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push
> >> Strachey_P [000015ba][00212662][000015bf] e813fdffff call 000012d2
> >> // call T Infinitely Recursive Simulation Detected Simulation
> >> Stopped
> >>
> >> T knows its own machine address and on this basis it can easily
> >> examine its stored execution_trace of Strachey_P (see above) to
> >> determine: (a) Strachey_P is calling T with the same arguments
> >> that T was called with. (b) No instructions in Strachey_P could
> >> possibly escape this otherwise infinitely recursive emulation.
> >
> > There is no recursion in [Strachey, 1965] or the proofs based on it
> > that you are attempting to refute. Fail.
> >
> > /Flibble
> >
>
> In other words you are saying that because a non-simulating halt
> decider (that has no recursive emulation) cannot correctly determine
> the halt status of its input that a simulating halt decider (that has
> recursive emulation) cannot correctly determine the halt status of
> its input.
We have already established that your simulating halt decider gets the
answer wrong if P calls H but isn't pathological.
>
> In other words if there are no black dogs in the kitchen this proves
> that there are no white cats in the living room.
You are the one trying to redefine H to be something else.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-26 14:37 -0500 |
| Message-ID | <3cOdnZP4Ka8cKCX_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #53018 |
On 6/26/2022 2:26 PM, Mr Flibble wrote:
> On Sun, 26 Jun 2022 14:11:02 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/26/2022 2:00 PM, Mr Flibble wrote:
>>> On Sun, 26 Jun 2022 11:27:06 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/26/2022 6:15 AM, Mr Flibble wrote:
>>>>> On Sun, 26 Jun 2022 05:31:53 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/25/2022 9:03 PM, Mr Flibble wrote:
>>>>>>> On Sat, 25 Jun 2022 20:58:23 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
>>>>>>>>>> wrote:
>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> "Dry run" means that a human programmer looks at the code,
>>>>>>>>>>>> and determines what it does, without actually executing
>>>>>>>>>>>> it.
>>>>>>>>>>>
>>>>>>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt.
>>>>>>>>>>> He's invoked H | on it and H reports that it doesn't halt.
>>>>>>>>>>> He's run P(P) and it halts. The obvious conclusion is that
>>>>>>>>>>> PO's dry run (if he has indeed done such a thing) is
>>>>>>>>>>> incorrect.
>>>>>>>>>> Exactly.
>>>>>>>>>> We do our little energy budget on tigers, and find that
>>>>>>>>>> tigers spend more energy than they take in. Well potentially
>>>>>>>>>> this is dynamite. One explanation is that the law of
>>>>>>>>>> conservation of energy is wrong. Except, before we
>>>>>>>>>> countenance that explanation, we need to rule out a much
>>>>>>>>>> simpler explanation. Which is that our measurements are
>>>>>>>>>> wrong.
>>>>>>>>>
>>>>>>>>> Obviously.
>>>>>>>>>
>>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should be
>>>>>>>>>> doing, by dry-running it, and then actually run P(P) and
>>>>>>>>>> obtained a different result. He also found that H agreed with
>>>>>>>>>> the dry run. It's hard to paraphrase his conclusion, but it
>>>>>>>>>> is extensive and far-reaching in its implications.
>>>>>>>>>
>>>>>>>>> He is just waffling. There is no conclusion, just a constant
>>>>>>>>> twisting and turning to find some why to persuade people that
>>>>>>>>> the wrong answer is the right one. He's being doing this for
>>>>>>>>> years with various degrees of obfuscation.
>>>>>>>>>
>>>>>>>>> H does not report the correct result for P(P) and PO is
>>>>>>>>> putting up anything he can think of to keep the discussion
>>>>>>>>> going. It should simply have stopped once he'd been clear
>>>>>>>>> that H(P,P) == 0 is correct "even though P(P) halts" but the
>>>>>>>>> traces and the verbiage is keeping people keen.
>>>>>>>>>> The behaviour of code when run is different from the
>>>>>>>>>> correct behaviour of the code when simulated. If that's true,
>>>>>>>>>> then it has similar implications for computer science that
>>>>>>>>>> disproving the conservation law has for physics.
>>>>>>>>>
>>>>>>>>> When a student comes to me and says that her program to add 5
>>>>>>>>> and 6 gives 12, I don't, even for a moment, imagine that the
>>>>>>>>> laws of logic and mathematics are in doubt.
>>>>>>>>>
>>>>>>>>>> But the obvious explanation is that the dry-run was
>>>>>>>>>> incorrect. Lots of people have suggested why it is
>>>>>>>>>> incorrect. But they can't actually see the code. PO needs to
>>>>>>>>>> understand that no-one will accept the complicated,
>>>>>>>>>> far-reaching explanation, until the simple explanation has
>>>>>>>>>> been ruled out.
>>>>>>>>>
>>>>>>>>> For what it's worth, I don't think there is any "dry run"
>>>>>>>>> going on here at all. PO decide years ago that H(H_Hat,
>>>>>>>>> H_Hat) would be 0 because he knew (correctly) that H could
>>>>>>>>> spot what would happen if H did not "intervene". Everything
>>>>>>>>> since then -- the "it only halt because...", the "it wouldn't
>>>>>>>>> halt if line 15 were commented out" and the rather less
>>>>>>>>> explicitly stated "H_Hat does not get to its ret instruction
>>>>>>>>> because a non top-level H aborts" are just the various
>>>>>>>>> attempt at after-the-fact justification.
>>>>>>>>>
>>>>>>>>> I agree it's never quite so simple because PO is usually
>>>>>>>>> fractally wrong, so he's not correct about almost everything
>>>>>>>>> he says at almost every level. For example, at one level he
>>>>>>>>> now admits that a halt decider is impossible because H(X,Y)
>>>>>>>>> must report "on its input" and the call X(Y) is not an input!
>>>>>>>>> He did this to explain why H(P,P) is permitted to return 0
>>>>>>>>> "even though P(P) halts", but it also makes it clear that
>>>>>>>>> what he one thought was that halting problem is not solvable.
>>>>>>>>>
>>>>>>>>
>>>>>>>> YOU KNOW THAT THIS IS TRUE
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> BECAUSE THIS IS PROVABLY TRUE
>>>>>>>> P(P) is provably not the actual behavior of the actual input.
>>>>>>>>
>>>>>>>> YOU ARE THE ONE FUDGING WITH THE TRUTH
>>>>>>>
>>>>>>> The issue is what constitutes a pathological input: the
>>>>>>> pathological input at issue here are YOUR PATHOLOGICAL LIES,
>>>>>>> Olcott.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Computable functions are the basic objects of study in
>>>>>> computability theory.
>>>>>> Computable functions are the formalized analogue of the
>>>>>> intuitive notion of
>>>>>> algorithms, in the sense that a function is computable if
>>>>>> there exists an algorithm
>>>>>> that can do the job of the function, i.e. given an input
>>>>>> of the function domain it
>>>>>> can return the corresponding output.
>>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>> }
>>>>>>
>>>>>> That you reject that the above proves that H and P have a
>>>>>> pathological relationship to each other seem to be your lack of
>>>>>> technical competence rather than dishonesty.
>>>>>
>>>>> There is nothing wrong with my technical competence however yours
>>>>> *is* suspect.
>>>>>
>>>>> Nobody is denying that P is pathological input as its comes
>>>>> from [Strachey, 1965]'s "Impossible Program";
>>>>
>>>> // rec routine P
>>>> // §L :if T[P] go to L
>>>> // Return §
>>>> // https://academic.oup.com/comjnl/article/7/4/313/354243
>>>> void Strachey_P()
>>>> {
>>>> L:if (T(Strachey_P))
>>>> goto L;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", T(Strachey_P));
>>>> }
>>>>
>>>> _Strachey_P()
>>>> [000015b2](01) 55 push ebp
>>>> [000015b3](02) 8bec mov ebp,esp
>>>> [000015b5](05) 68b2150000 push 000015b2 // push Strachey_P
>>>> [000015ba](05) e813fdffff call 000012d2 // call T
>>>> [000015bf](03) 83c404 add esp,+04
>>>> [000015c2](02) 85c0 test eax,eax
>>>> [000015c4](02) 7402 jz 000015c8
>>>> [000015c6](02) ebed jmp 000015b5
>>>> [000015c8](01) 5d pop ebp
>>>> [000015c9](01) c3 ret
>>>> Size in bytes:(0024) [000015c9]
>>>>
>>>> _main()
>>>> [000015d2](01) 55 push ebp
>>>> [000015d3](02) 8bec mov ebp,esp
>>>> [000015d5](05) 68b2150000 push 000015b2 // push Strachey_P
>>>> [000015da](05) e8f3fcffff call 000012d2 // call T
>>>> [000015df](03) 83c404 add esp,+04
>>>> [000015e2](01) 50 push eax
>>>> [000015e3](05) 6833040000 push 00000433
>>>> [000015e8](05) e895eeffff call 00000482
>>>> [000015ed](03) 83c408 add esp,+08
>>>> [000015f0](02) 33c0 xor eax,eax
>>>> [000015f2](01) 5d pop ebp
>>>> [000015f3](01) c3 ret
>>>> Size in bytes:(0034) [000015f3]
>>>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> [000015d2][001025c6][00000000] 55 push ebp
>>>> [000015d3][001025c6][00000000] 8bec mov ebp,esp
>>>> [000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push
>>>> Strachey_P [000015da][001025be][000015df] e8f3fcffff call 000012d2
>>>> // call T
>>>>
>>>> Begin Simulation Execution Trace Stored at:21267a
>>>> Address_of_T:12d2
>>>> [000015b2][0021266a][0021266e] 55 push ebp
>>>> [000015b3][0021266a][0021266e] 8bec mov ebp,esp
>>>> [000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push
>>>> Strachey_P [000015ba][00212662][000015bf] e813fdffff call 000012d2
>>>> // call T Infinitely Recursive Simulation Detected Simulation
>>>> Stopped
>>>>
>>>> T knows its own machine address and on this basis it can easily
>>>> examine its stored execution_trace of Strachey_P (see above) to
>>>> determine: (a) Strachey_P is calling T with the same arguments
>>>> that T was called with. (b) No instructions in Strachey_P could
>>>> possibly escape this otherwise infinitely recursive emulation.
>>>
>>> There is no recursion in [Strachey, 1965] or the proofs based on it
>>> that you are attempting to refute. Fail.
>>>
>>> /Flibble
>>>
>>
>> In other words you are saying that because a non-simulating halt
>> decider (that has no recursive emulation) cannot correctly determine
>> the halt status of its input that a simulating halt decider (that has
>> recursive emulation) cannot correctly determine the halt status of
>> its input.
>
> We have already established that your simulating halt decider gets the
> answer wrong if P calls H but isn't pathological.
>
We have not established that at all.
H1(P,P)==1 is the non-pathological instance.
>>
>> In other words if there are no black dogs in the kitchen this proves
>> that there are no white cats in the living room.
>
> You are the one trying to redefine H to be something else.
>
> /Flibble
>
Not something else at all.
It is merely the case that no one besides me every bothered to fully
investigate the effects of applying a simulating halt decider to the
wide open (any pure function of its inputs will do) specification of the
halting problem proofs.
--
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 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.theory
csiph-web