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 1 of 11 [1] 2 3 … 11 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-21 21:38 -0500 |
| Subject | Technically competent Software engineers can verify this halting problem proof refutation |
| Message-ID | <EOydnaeszcdfHS__nZ2dnUU7_83NnZ2d@giganews.com> |
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H would
never reach the "ret" instruction of P because both H and P would remain
stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite number
of steps then H could reject its input on this basis. Here are the
details of exactly how H does this in a finite number of steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
&slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily examine
its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
--
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] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-21 22:52 -0400 |
| Message-ID | <PtvsK.300027$5fVf.158200@fx09.iad> |
| In reply to | #52749 |
On 6/21/22 10:38 PM, olcott wrote:
> #include <stdint.h>
> #define u32 uint32_t
>
> #include <stdint.h>
> typedef void (*ptr)();
>
> void P(ptr x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
>
> _P()
> [000010d2](01) 55 push ebp
> [000010d3](02) 8bec mov ebp,esp
> [000010d5](03) 8b4508 mov eax,[ebp+08]
> [000010d8](01) 50 push eax
> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
> [000010dc](01) 51 push ecx
> [000010dd](05) e820feffff call 00000f02
> [000010e2](03) 83c408 add esp,+08
> [000010e5](02) 85c0 test eax,eax
> [000010e7](02) 7402 jz 000010eb
> [000010e9](02) ebfe jmp 000010e9
> [000010eb](01) 5d pop ebp
> [000010ec](01) c3 ret
> Size in bytes:(0027) [000010ec]
>
> Every sufficiently competent software engineer can easily verify that
> the complete and correct x86 emulation of the input to H(P,P) by H would
> never reach the "ret" instruction of P because both H and P would remain
> stuck in infinitely recursive emulation.
>
> If H does correctly determine that this is the case in a finite number
> of steps then H could reject its input on this basis. Here are the
> details of exactly how H does this in a finite number of steps.
>
> typedef struct Decoded
> {
> u32 Address;
> u32 ESP; // Current value of ESP
> u32 TOS; // Current value of Top of Stack
> u32 NumBytes;
> u32 Simplified_Opcode;
> u32 Decode_Target;
> } Decoded_Line_Of_Code;
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [000010d2][00211e8a][00211e8e] 55 push ebp
> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
> [000010d8][00211e86][000010d2] 50 push eax // push P
> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
> [000010dc][00211e82][000010d2] 51 push ecx // push P
> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
> Infinitely Recursive Simulation Detected Simulation Stopped
>
> // actual fully operational code in the x86utm operating system
> u32 H(u32 P, u32 I)
> {
> HERE:
> u32 End_Of_Code;
> u32 Address_of_H; // 2022-06-17
> u32 code_end = get_code_end(P);
> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
> Allocate(sizeof(Decoded_Line_Of_Code));
> Registers* master_state = (Registers*)
> Allocate(sizeof(Registers));
> Registers* slave_state = (Registers*)
> Allocate(sizeof(Registers));
> u32* slave_stack = Allocate(0x10000); // 64k;
> u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
> 1000);
>
> __asm lea eax, HERE // 2022-06-18
> __asm sub eax, 6 // 2022-06-18
> __asm mov Address_of_H, eax // 2022-06-18
> __asm mov eax, END_OF_CODE
> __asm mov End_Of_Code, eax
>
> Output("Address_of_H:", Address_of_H); // 2022-06-11
> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
> Output("\nBegin Simulation Execution Trace Stored at:",
> execution_trace);
> if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
> &slave_state, &slave_stack, Address_of_H, P, I))
> goto END_OF_CODE;
> return 0; // Does not halt
> END_OF_CODE:
> return 1; // Input has normally terminated
> }
>
> H knows its own machine address and on this basis it can easily examine
> its stored execution_trace of P and determine:
> (a) P is calling H with the same arguments that H was called with.
> (b) No instructions in P could possibly escape this otherwise infinitely
> recursive emulation.
> (c) H aborts its emulation of P before its call to H is invoked.
>
>
>
>
> Technically competent software engineers may not know this computer
> science:
>
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)
>
> The "ret" instruction of P is its final state.
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
>
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the
DEFINITION of the behavior of H(P,P), especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H is wrong.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-21 22:10 -0500 |
| Message-ID | <CaWdnZEntLawFS__nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #52753 |
On 6/21/2022 9:52 PM, Richard Damon wrote:
> On 6/21/22 10:38 PM, olcott wrote:
>> #include <stdint.h>
>> #define u32 uint32_t
>>
>> #include <stdint.h>
>> typedef void (*ptr)();
>>
>> void P(ptr x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(P, P));
>> }
>>
>> _P()
>> [000010d2](01) 55 push ebp
>> [000010d3](02) 8bec mov ebp,esp
>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>> [000010d8](01) 50 push eax
>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>> [000010dc](01) 51 push ecx
>> [000010dd](05) e820feffff call 00000f02
>> [000010e2](03) 83c408 add esp,+08
>> [000010e5](02) 85c0 test eax,eax
>> [000010e7](02) 7402 jz 000010eb
>> [000010e9](02) ebfe jmp 000010e9
>> [000010eb](01) 5d pop ebp
>> [000010ec](01) c3 ret
>> Size in bytes:(0027) [000010ec]
>>
>> Every sufficiently competent software engineer can easily verify that
>> the complete and correct x86 emulation of the input to H(P,P) by H
>> would never reach the "ret" instruction of P because both H and P
>> would remain stuck in infinitely recursive emulation.
>>
>> If H does correctly determine that this is the case in a finite number
>> of steps then H could reject its input on this basis. Here are the
>> details of exactly how H does this in a finite number of steps.
>>
>> typedef struct Decoded
>> {
>> u32 Address;
>> u32 ESP; // Current value of ESP
>> u32 TOS; // Current value of Top of Stack
>> u32 NumBytes;
>> u32 Simplified_Opcode;
>> u32 Decode_Target;
>> } Decoded_Line_Of_Code;
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [000010d2][00211e8a][00211e8e] 55 push ebp
>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>> [000010d8][00211e86][000010d2] 50 push eax // push P
>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
>> [000010dc][00211e82][000010d2] 51 push ecx // push P
>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
>> Infinitely Recursive Simulation Detected Simulation Stopped
>>
>> // actual fully operational code in the x86utm operating system
>> u32 H(u32 P, u32 I)
>> {
>> HERE:
>> u32 End_Of_Code;
>> u32 Address_of_H; // 2022-06-17
>> u32 code_end = get_code_end(P);
>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>> Allocate(sizeof(Decoded_Line_Of_Code));
>> Registers* master_state = (Registers*)
>> Allocate(sizeof(Registers));
>> Registers* slave_state = (Registers*)
>> Allocate(sizeof(Registers));
>> u32* slave_stack = Allocate(0x10000); // 64k;
>> u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
>> 1000);
>>
>> __asm lea eax, HERE // 2022-06-18
>> __asm sub eax, 6 // 2022-06-18
>> __asm mov Address_of_H, eax // 2022-06-18
>> __asm mov eax, END_OF_CODE
>> __asm mov End_Of_Code, eax
>>
>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>> Output("\nBegin Simulation Execution Trace Stored at:",
>> execution_trace);
>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>> &master_state,
>> &slave_state, &slave_stack, Address_of_H, P, I))
>> goto END_OF_CODE;
>> return 0; // Does not halt
>> END_OF_CODE:
>> return 1; // Input has normally terminated
>> }
>>
>> H knows its own machine address and on this basis it can easily
>> examine its stored execution_trace of P and determine:
>> (a) P is calling H with the same arguments that H was called with.
>> (b) No instructions in P could possibly escape this otherwise
>> infinitely recursive emulation.
>> (c) H aborts its emulation of P before its call to H is invoked.
>>
>>
>>
>>
>> Technically competent software engineers may not know this computer
>> science:
>>
>> A halt decider must compute the mapping from its inputs to an accept
>> or reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>>
>> computation that halts … the Turing machine will halt whenever it
>> enters a final state. (Linz:1990:234)
>>
>> The "ret" instruction of P is its final state.
>>
>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>
>
> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
> was incorrect in its mapping, since the behavior of P(P) is the
> DEFINITION of the behavior of H(P,P),
Linz and others were aware that: A halt decider must compute the mapping
from its inputs to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual behavior that
is actually specified by the inputs to a simulating halt decider is not
the same as the direct execution of these inputs. They were unaware of
this because no one previously fully examined a simulating halt decider
ever before.
> especially if that is what P calls
> and P is claimed to be built by the Linz template.
>
> So, either P isn't built right, or H isn't built fight, or H is wrong.
--
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-21 23:28 -0400 |
| Message-ID | <P%vsK.312637$zgr9.40443@fx13.iad> |
| In reply to | #52754 |
On 6/21/22 11:10 PM, olcott wrote:
> On 6/21/2022 9:52 PM, Richard Damon wrote:
>> On 6/21/22 10:38 PM, olcott wrote:
>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> #include <stdint.h>
>>> typedef void (*ptr)();
>>>
>>> void P(ptr x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>> _P()
>>> [000010d2](01) 55 push ebp
>>> [000010d3](02) 8bec mov ebp,esp
>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>> [000010d8](01) 50 push eax
>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>> [000010dc](01) 51 push ecx
>>> [000010dd](05) e820feffff call 00000f02
>>> [000010e2](03) 83c408 add esp,+08
>>> [000010e5](02) 85c0 test eax,eax
>>> [000010e7](02) 7402 jz 000010eb
>>> [000010e9](02) ebfe jmp 000010e9
>>> [000010eb](01) 5d pop ebp
>>> [000010ec](01) c3 ret
>>> Size in bytes:(0027) [000010ec]
>>>
>>> Every sufficiently competent software engineer can easily verify that
>>> the complete and correct x86 emulation of the input to H(P,P) by H
>>> would never reach the "ret" instruction of P because both H and P
>>> would remain stuck in infinitely recursive emulation.
>>>
>>> If H does correctly determine that this is the case in a finite
>>> number of steps then H could reject its input on this basis. Here are
>>> the details of exactly how H does this in a finite number of steps.
>>>
>>> typedef struct Decoded
>>> {
>>> u32 Address;
>>> u32 ESP; // Current value of ESP
>>> u32 TOS; // Current value of Top of Stack
>>> u32 NumBytes;
>>> u32 Simplified_Opcode;
>>> u32 Decode_Target;
>>> } Decoded_Line_Of_Code;
>>>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> [000010d2][00211e8a][00211e8e] 55 push ebp
>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>>> [000010d8][00211e86][000010d2] 50 push eax // push P
>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>
>>> // actual fully operational code in the x86utm operating system
>>> u32 H(u32 P, u32 I)
>>> {
>>> HERE:
>>> u32 End_Of_Code;
>>> u32 Address_of_H; // 2022-06-17
>>> u32 code_end = get_code_end(P);
>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>> Registers* master_state = (Registers*)
>>> Allocate(sizeof(Registers));
>>> Registers* slave_state = (Registers*)
>>> Allocate(sizeof(Registers));
>>> u32* slave_stack = Allocate(0x10000); // 64k;
>>> u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>> * 1000);
>>>
>>> __asm lea eax, HERE // 2022-06-18
>>> __asm sub eax, 6 // 2022-06-18
>>> __asm mov Address_of_H, eax // 2022-06-18
>>> __asm mov eax, END_OF_CODE
>>> __asm mov End_Of_Code, eax
>>>
>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>> Output("\nBegin Simulation Execution Trace Stored at:",
>>> execution_trace);
>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>>> &master_state,
>>> &slave_state, &slave_stack, Address_of_H, P, I))
>>> goto END_OF_CODE;
>>> return 0; // Does not halt
>>> END_OF_CODE:
>>> return 1; // Input has normally terminated
>>> }
>>>
>>> H knows its own machine address and on this basis it can easily
>>> examine its stored execution_trace of P and determine:
>>> (a) P is calling H with the same arguments that H was called with.
>>> (b) No instructions in P could possibly escape this otherwise
>>> infinitely recursive emulation.
>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>
>>>
>>>
>>>
>>> Technically competent software engineers may not know this computer
>>> science:
>>>
>>> A halt decider must compute the mapping from its inputs to an accept
>>> or reject state on the basis of the actual behavior that is actually
>>> specified by these inputs.
>>>
>>> computation that halts … the Turing machine will halt whenever it
>>> enters a final state. (Linz:1990:234)
>>>
>>> The "ret" instruction of P is its final state.
>>>
>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>
>>
>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>> was incorrect in its mapping, since the behavior of P(P) is the
>> DEFINITION of the behavior of H(P,P),
>
>
> Linz and others were aware that: A halt decider must compute the mapping
> from its inputs to an accept or reject state on the basis of the actual
> behavior that is actually specified by these inputs.
"Inputs" don't have "behavior" except by what they represent.
>
> Linz and others made the false assumption that the actual behavior that
> is actually specified by the inputs to a simulating halt decider is not
> the same as the direct execution of these inputs. They were unaware of
> this because no one previously fully examined a simulating halt decider
> ever before.
>
Nope, YOU are the one making the stupid assumption that you get to
change the meaning of the definitions.
All you are doing is CONFIRMING that it is impossible to build a decider
to do the job of a Halt decider, because YOU are claiming you can't even
ask it the question.
If your system can't prhase the question, it can't answer it, so that
shows that there exists a machine that it can't give the corret answer two.
You are reversing the direction of requirements.
H doesn't need to be able to answer for every machine that can be
represented to it, it need to define how to represent every machine that
can exist, and then answer correctly for it.
The domain for H is the representation of ALL possible machines x
representation of ALL possible inputs for that machine.
Yes, if CAN only answer for machines you can represent for it, but if
there is a machine you can't represent, that makes H FAIL, not give H a
"psss" for that input.
You claim that you can't represent that input just PROVES that you
counter is incorrect.
>
>
>> especially if that is what P calls and P is claimed to be built by the
>> Linz template.
>>
>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Python <python@example.invalid> |
|---|---|
| Date | 2022-06-22 05:52 +0200 |
| Message-ID | <t8u3m9$6j0$1@gioia.aioe.org> |
| In reply to | #52754 |
Peter Olcott wrote: > [snip badly regurgitated boring bullshit] People feel embarrassed for you, Peter, you know? On the other hand, after all, you are a convicted liar, a blatant idiot, a pathetic bigot and an ass, Peter, so we don't care that much. (stop absusing Usenet by multi-posting without followup, this is rude)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-06-22 00:55 -0700 |
| Message-ID | <ccb8af3c-e497-4d6e-8040-826a4e87a6e7n@googlegroups.com> |
| In reply to | #52754 |
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: > On 6/21/2022 9:52 PM, Richard Damon wrote: > > > > Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H > > was incorrect in its mapping, since the behavior of P(P) is the > > DEFINITION of the behavior of H(P,P), > Linz and others were aware that: A halt decider must compute the mapping > from its inputs to an accept or reject state on the basis of the actual > behavior that is actually specified by these inputs. > Linz and others made the false assumption that the actual behavior that > is actually specified by the inputs to a simulating halt decider is not > the same as the direct execution of these inputs. They were unaware of > this because no one previously fully examined a simulating halt decider > ever before. > > especially if that is what P calls > > and P is claimed to be built by the Linz template. > > > > So, either P isn't built right, or H isn't built fight, or H is wrong. > You've dry-run P(P) and it doesn't halt. Additionally the halt decider H reports it as non-halting. So it's reasonable to assume that H is correct. However, when run, P(P) halts. So what are we to conclude? That "the actual behaviour that is actually specified by the inputs to a simulating halt decider is not the same as the direct execution of these inputs"? That would have far-reaching consequences. Before going there, maybe think up some simpler, alternative explanations and eliminate them.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 07:16 -0500 |
| Message-ID | <g9qdnRjZj9uBlS7_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52758 |
On 6/22/2022 2:55 AM, Malcolm McLean wrote: > On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >> On 6/21/2022 9:52 PM, Richard Damon wrote: >>> >>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H >>> was incorrect in its mapping, since the behavior of P(P) is the >>> DEFINITION of the behavior of H(P,P), >> Linz and others were aware that: A halt decider must compute the mapping >> from its inputs to an accept or reject state on the basis of the actual >> behavior that is actually specified by these inputs. >> Linz and others made the false assumption that the actual behavior that >> is actually specified by the inputs to a simulating halt decider is not >> the same as the direct execution of these inputs. They were unaware of >> this because no one previously fully examined a simulating halt decider >> ever before. >>> especially if that is what P calls >>> and P is claimed to be built by the Linz template. >>> >>> So, either P isn't built right, or H isn't built fight, or H is wrong. >> > You've dry-run P(P) and it doesn't halt. Additionally the halt decider H > reports it as non-halting. So it's reasonable to assume that H is correct. > > However, when run, P(P) halts. So what are we to conclude? That "the > actual behaviour that is actually specified by the inputs to a simulating > halt decider is not the same as the direct execution of these inputs"? That is an actual immutable verified fact. > That would have far-reaching consequences. Before going there, maybe > think up some simpler, alternative explanations and eliminate them. There are no alternatives to immutable verified facts. H(P,P) halts only because H(P,P) correctly determines that its input never halts. Technically competent software engineers would agree. On the basis of the much more complete details that I provided in my original post. When P(P) is called from main its behavior depends on the return value of H. When H is called from main P(P) cannot possibly depend on the return value of H because the correctly emulated input to H(P,P) continues to remain stuck in infinite emulation until H aborts it. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-06-22 05:45 -0700 |
| Message-ID | <0f7ed34c-5aaa-4858-885e-66e16777f599n@googlegroups.com> |
| In reply to | #52759 |
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: > On 6/22/2022 2:55 AM, Malcolm McLean wrote: > > On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: > >> On 6/21/2022 9:52 PM, Richard Damon wrote: > >>> > >>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H > >>> was incorrect in its mapping, since the behavior of P(P) is the > >>> DEFINITION of the behavior of H(P,P), > >> Linz and others were aware that: A halt decider must compute the mapping > >> from its inputs to an accept or reject state on the basis of the actual > >> behavior that is actually specified by these inputs. > >> Linz and others made the false assumption that the actual behavior that > >> is actually specified by the inputs to a simulating halt decider is not > >> the same as the direct execution of these inputs. They were unaware of > >> this because no one previously fully examined a simulating halt decider > >> ever before. > >>> especially if that is what P calls > >>> and P is claimed to be built by the Linz template. > >>> > >>> So, either P isn't built right, or H isn't built fight, or H is wrong. > >> > > You've dry-run P(P) and it doesn't halt. Additionally the halt decider H > > reports it as non-halting. So it's reasonable to assume that H is correct. > > > > However, when run, P(P) halts. So what are we to conclude? That "the > > actual behaviour that is actually specified by the inputs to a simulating > > halt decider is not the same as the direct execution of these inputs"? > That is an actual immutable verified fact. > That's your conclusion from your observations and reasoning. You've dry-run P(P), and it doesn't halt. You've run H on P(P), and it reports "non-halting". You've run P(P), and it halts. So one explanation is the one you've given but, as I said, that explanation has rather far-reaching consequences. In these circumstances, the sensible scientist (or I suppose mathematician, though I'm a scientist and not a mathematician) looks for alternative explanations which aren't quite as consequential. > > That would have far-reaching consequences. Before going there, maybe > > think up some simpler, alternative explanations and eliminate them. > There are no alternatives to immutable verified facts. H(P,P) halts only > because H(P,P) correctly determines that its input never halts. > > Technically competent software engineers would agree. On the basis of > the much more complete details that I provided in my original post. > > When P(P) is called from main its behavior depends on the return value > of H. When H is called from main P(P) cannot possibly depend on the > return value of H because the correctly emulated input to H(P,P) > continues to remain stuck in infinite emulation until H aborts it. > That would be one consequence of going with your explanation. We'd have to say the behaviour of P(P) differs depending on caller. As I said, try simpler, less far-reaching explanations first.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 07:53 -0500 |
| Message-ID | <HuGdnX9Dm5lXjS7_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52760 |
On 6/22/2022 7:45 AM, Malcolm McLean wrote:
> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>
>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>> DEFINITION of the behavior of H(P,P),
>>>> Linz and others were aware that: A halt decider must compute the mapping
>>>> from its inputs to an accept or reject state on the basis of the actual
>>>> behavior that is actually specified by these inputs.
>>>> Linz and others made the false assumption that the actual behavior that
>>>> is actually specified by the inputs to a simulating halt decider is not
>>>> the same as the direct execution of these inputs. They were unaware of
>>>> this because no one previously fully examined a simulating halt decider
>>>> ever before.
>>>>> especially if that is what P calls
>>>>> and P is claimed to be built by the Linz template.
>>>>>
>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>
>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>
>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>> actual behaviour that is actually specified by the inputs to a simulating
>>> halt decider is not the same as the direct execution of these inputs"?
>> That is an actual immutable verified fact.
>>
> That's your conclusion from your observations and reasoning. You've
> dry-run P(P), and it doesn't halt. You've run H on P(P), and it reports "non-halting".
> You've run P(P), and it halts.
> So one explanation is the one you've given but, as I said, that explanation has
> rather far-reaching consequences. In these circumstances, the sensible
> scientist (or I suppose mathematician, though I'm a scientist and not a
> mathematician) looks for alternative explanations which aren't quite as
> consequential.
That is like looking for alternatives to 5 > 3
5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>> That would have far-reaching consequences. Before going there, maybe
>>> think up some simpler, alternative explanations and eliminate them.
>> There are no alternatives to immutable verified facts. H(P,P) halts only
>> because H(P,P) correctly determines that its input never halts.
>>
>> Technically competent software engineers would agree. On the basis of
>> the much more complete details that I provided in my original post.
>>
>> When P(P) is called from main its behavior depends on the return value
>> of H. When H is called from main P(P) cannot possibly depend on the
>> return value of H because the correctly emulated input to H(P,P)
>> continues to remain stuck in infinite emulation until H aborts it.
>>
> That would be one consequence of going with your explanation. We'd have to
> say the behaviour of P(P) differs depending on caller. As I said, try simpler,
> less far-reaching explanations first.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
H(P,P)==0 is provably correct
H1(P,P)==1 is provably correct.
H1(P,P) reports on the behavior of P(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 | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 09:55 -0500 |
| Message-ID | <RrednV8YuePtsC7_nZ2dnUU7_8xh4p2d@giganews.com> |
| In reply to | #52761 |
On 6/22/2022 7:53 AM, olcott wrote:
> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>
>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>> DEFINITION of the behavior of H(P,P),
>>>>> Linz and others were aware that: A halt decider must compute the
>>>>> mapping
>>>>> from its inputs to an accept or reject state on the basis of the
>>>>> actual
>>>>> behavior that is actually specified by these inputs.
>>>>> Linz and others made the false assumption that the actual behavior
>>>>> that
>>>>> is actually specified by the inputs to a simulating halt decider is
>>>>> not
>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>> this because no one previously fully examined a simulating halt
>>>>> decider
>>>>> ever before.
>>>>>> especially if that is what P calls
>>>>>> and P is claimed to be built by the Linz template.
>>>>>>
>>>>>> So, either P isn't built right, or H isn't built fight, or H is
>>>>>> wrong.
>>>>>
>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt
>>>> decider H
>>>> reports it as non-halting. So it's reasonable to assume that H is
>>>> correct.
>>>>
>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>> actual behaviour that is actually specified by the inputs to a
>>>> simulating
>>>> halt decider is not the same as the direct execution of these inputs"?
>>> That is an actual immutable verified fact.
>>>
>> That's your conclusion from your observations and reasoning. You've
>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>> reports "non-halting".
>> You've run P(P), and it halts.
>> So one explanation is the one you've given but, as I said, that
>> explanation has
>> rather far-reaching consequences. In these circumstances, the sensible
>> scientist (or I suppose mathematician, though I'm a scientist and not a
>> mathematician) looks for alternative explanations which aren't quite as
>> consequential.
>
> That is like looking for alternatives to 5 > 3
> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>
>>>> That would have far-reaching consequences. Before going there, maybe
>>>> think up some simpler, alternative explanations and eliminate them.
>>> There are no alternatives to immutable verified facts. H(P,P) halts only
>>> because H(P,P) correctly determines that its input never halts.
>>>
>>> Technically competent software engineers would agree. On the basis of
>>> the much more complete details that I provided in my original post.
>>>
>>> When P(P) is called from main its behavior depends on the return value
>>> of H. When H is called from main P(P) cannot possibly depend on the
>>> return value of H because the correctly emulated input to H(P,P)
>>> continues to remain stuck in infinite emulation until H aborts it.
>>>
>> That would be one consequence of going with your explanation. We'd
>> have to
>> say the behaviour of P(P) differs depending on caller. As I said, try
>> simpler,
>> less far-reaching explanations first.
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> H(P,P)==0 is provably correct
> H1(P,P)==1 is provably correct.
> H1(P,P) reports on the behavior of P(P).
>
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. The actual behavior of the actual input to
H(P,P) is non halting thus rejecting its input is necessarily correct.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-22 19:05 -0400 |
| Message-ID | <7fNsK.15922$nZ1.12935@fx05.iad> |
| In reply to | #52762 |
On 6/22/22 10:55 AM, olcott wrote:
> On 6/22/2022 7:53 AM, olcott wrote:
>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0,
>>>>>>> so H
>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>> Linz and others were aware that: A halt decider must compute the
>>>>>> mapping
>>>>>> from its inputs to an accept or reject state on the basis of the
>>>>>> actual
>>>>>> behavior that is actually specified by these inputs.
>>>>>> Linz and others made the false assumption that the actual behavior
>>>>>> that
>>>>>> is actually specified by the inputs to a simulating halt decider
>>>>>> is not
>>>>>> the same as the direct execution of these inputs. They were
>>>>>> unaware of
>>>>>> this because no one previously fully examined a simulating halt
>>>>>> decider
>>>>>> ever before.
>>>>>>> especially if that is what P calls
>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>
>>>>>>> So, either P isn't built right, or H isn't built fight, or H is
>>>>>>> wrong.
>>>>>>
>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt
>>>>> decider H
>>>>> reports it as non-halting. So it's reasonable to assume that H is
>>>>> correct.
>>>>>
>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>> actual behaviour that is actually specified by the inputs to a
>>>>> simulating
>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>> That is an actual immutable verified fact.
>>>>
>>> That's your conclusion from your observations and reasoning. You've
>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>> reports "non-halting".
>>> You've run P(P), and it halts.
>>> So one explanation is the one you've given but, as I said, that
>>> explanation has
>>> rather far-reaching consequences. In these circumstances, the sensible
>>> scientist (or I suppose mathematician, though I'm a scientist and not a
>>> mathematician) looks for alternative explanations which aren't quite as
>>> consequential.
>>
>> That is like looking for alternatives to 5 > 3
>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>
>>>>> That would have far-reaching consequences. Before going there, maybe
>>>>> think up some simpler, alternative explanations and eliminate them.
>>>> There are no alternatives to immutable verified facts. H(P,P) halts
>>>> only
>>>> because H(P,P) correctly determines that its input never halts.
>>>>
>>>> Technically competent software engineers would agree. On the basis of
>>>> the much more complete details that I provided in my original post.
>>>>
>>>> When P(P) is called from main its behavior depends on the return value
>>>> of H. When H is called from main P(P) cannot possibly depend on the
>>>> return value of H because the correctly emulated input to H(P,P)
>>>> continues to remain stuck in infinite emulation until H aborts it.
>>>>
>>> That would be one consequence of going with your explanation. We'd
>>> have to
>>> say the behaviour of P(P) differs depending on caller. As I said, try
>>> simpler,
>>> less far-reaching explanations first.
>>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> H(P,P)==0 is provably correct
>> H1(P,P)==1 is provably correct.
>> H1(P,P) reports on the behavior of P(P).
>>
>
> 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. The actual behavior of the actual input to
> H(P,P) is non halting thus rejecting its input is necessarily correct.
>
>
You have this wrong.
A decider must compute the mapping that represents the FUNCTION it is
deciding, there is actually nothing about "behavior" in the definition.
For a HALTING decider, that mapping is based on the HALTING Behavior of
the machine the input REPRESENTS.
Inputs are just strings, and as such don't have behaviors in and of
themselves.
If the behavior the decider sees doesn't match the behavior of the
machine the input is supposed to represent, then either the decider is
misdefined and is generating the wrong behavior, or the input wasn't
constructed properly.
In H(P,P) vs P(P), you have provided both the H and the input
representation, so if the input doesn't represent P(P), it is YOUR mistake.
If H can't be given an input to represents P(P), then H is defective and
not a counter example. If P giving H the wrong parameters, then you P is
defined wrong and not a counter example.
In short, sonce P(P) Halts when H(P,P) returns 0, then H(P,P) returning
0 is NOT a counter example to the halting problem. If somehow you want
to call it a correct answer, it is to the wrong question so doesn't
actually provide the counter example you claim.
You repeating this claim over and over just shows that you have no
understand of what you are talking about.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 18:39 -0500 |
| Message-ID | <6KadnVr6RfWyNS7_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52789 |
On 6/22/2022 6:05 PM, Richard Damon wrote:
> On 6/22/22 10:55 AM, olcott wrote:
>> On 6/22/2022 7:53 AM, olcott wrote:
>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0,
>>>>>>>> so H
>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>> Linz and others were aware that: A halt decider must compute the
>>>>>>> mapping
>>>>>>> from its inputs to an accept or reject state on the basis of the
>>>>>>> actual
>>>>>>> behavior that is actually specified by these inputs.
>>>>>>> Linz and others made the false assumption that the actual
>>>>>>> behavior that
>>>>>>> is actually specified by the inputs to a simulating halt decider
>>>>>>> is not
>>>>>>> the same as the direct execution of these inputs. They were
>>>>>>> unaware of
>>>>>>> this because no one previously fully examined a simulating halt
>>>>>>> decider
>>>>>>> ever before.
>>>>>>>> especially if that is what P calls
>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>
>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is
>>>>>>>> wrong.
>>>>>>>
>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt
>>>>>> decider H
>>>>>> reports it as non-halting. So it's reasonable to assume that H is
>>>>>> correct.
>>>>>>
>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>> actual behaviour that is actually specified by the inputs to a
>>>>>> simulating
>>>>>> halt decider is not the same as the direct execution of these
>>>>>> inputs"?
>>>>> That is an actual immutable verified fact.
>>>>>
>>>> That's your conclusion from your observations and reasoning. You've
>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>> reports "non-halting".
>>>> You've run P(P), and it halts.
>>>> So one explanation is the one you've given but, as I said, that
>>>> explanation has
>>>> rather far-reaching consequences. In these circumstances, the sensible
>>>> scientist (or I suppose mathematician, though I'm a scientist and not a
>>>> mathematician) looks for alternative explanations which aren't quite as
>>>> consequential.
>>>
>>> That is like looking for alternatives to 5 > 3
>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>
>>>>>> That would have far-reaching consequences. Before going there, maybe
>>>>>> think up some simpler, alternative explanations and eliminate them.
>>>>> There are no alternatives to immutable verified facts. H(P,P) halts
>>>>> only
>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>
>>>>> Technically competent software engineers would agree. On the basis of
>>>>> the much more complete details that I provided in my original post.
>>>>>
>>>>> When P(P) is called from main its behavior depends on the return value
>>>>> of H. When H is called from main P(P) cannot possibly depend on the
>>>>> return value of H because the correctly emulated input to H(P,P)
>>>>> continues to remain stuck in infinite emulation until H aborts it.
>>>>>
>>>> That would be one consequence of going with your explanation. We'd
>>>> have to
>>>> say the behaviour of P(P) differs depending on caller. As I said,
>>>> try simpler,
>>>> less far-reaching explanations first.
>>>
>>> void P(u32 x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> H(P,P)==0 is provably correct
>>> H1(P,P)==1 is provably correct.
>>> H1(P,P) reports on the behavior of P(P).
>>>
>>
>> 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. The actual behavior of the actual input to
>> H(P,P) is non halting thus rejecting its input is necessarily correct.
>>
>>
>
> You have this wrong.
>
> A decider must compute the mapping that represents the FUNCTION it is
> deciding, there is actually nothing about "behavior" in the definition.
>
> For a HALTING decider, that mapping is based on the HALTING Behavior of
> the machine the input REPRESENTS.
If you construe this as the actual behavior that the actual input
specifies then this is correct otherwise this is incorrect.
People that actually understand these things deeply on the basis of all
of the deep connected meanings will agree. People that understand these
things only by the rote memorization of what textbooks say may get
confused.
This is computer science that I wrote that is verifiably correct and
clarifies the misconceptions of what a halt decider must do:
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. Copyright Olcott 2021
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-22 20:22 -0400 |
| Message-ID | <fnOsK.1651$Eh2.863@fx41.iad> |
| In reply to | #52793 |
On 6/22/22 7:39 PM, olcott wrote:
> On 6/22/2022 6:05 PM, Richard Damon wrote:
>> On 6/22/22 10:55 AM, olcott wrote:
>>> On 6/22/2022 7:53 AM, olcott wrote:
>>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns
>>>>>>>>> 0, so H
>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>> Linz and others were aware that: A halt decider must compute the
>>>>>>>> mapping
>>>>>>>> from its inputs to an accept or reject state on the basis of the
>>>>>>>> actual
>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>> Linz and others made the false assumption that the actual
>>>>>>>> behavior that
>>>>>>>> is actually specified by the inputs to a simulating halt decider
>>>>>>>> is not
>>>>>>>> the same as the direct execution of these inputs. They were
>>>>>>>> unaware of
>>>>>>>> this because no one previously fully examined a simulating halt
>>>>>>>> decider
>>>>>>>> ever before.
>>>>>>>>> especially if that is what P calls
>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>
>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is
>>>>>>>>> wrong.
>>>>>>>>
>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt
>>>>>>> decider H
>>>>>>> reports it as non-halting. So it's reasonable to assume that H is
>>>>>>> correct.
>>>>>>>
>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>>> actual behaviour that is actually specified by the inputs to a
>>>>>>> simulating
>>>>>>> halt decider is not the same as the direct execution of these
>>>>>>> inputs"?
>>>>>> That is an actual immutable verified fact.
>>>>>>
>>>>> That's your conclusion from your observations and reasoning. You've
>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>> reports "non-halting".
>>>>> You've run P(P), and it halts.
>>>>> So one explanation is the one you've given but, as I said, that
>>>>> explanation has
>>>>> rather far-reaching consequences. In these circumstances, the sensible
>>>>> scientist (or I suppose mathematician, though I'm a scientist and
>>>>> not a
>>>>> mathematician) looks for alternative explanations which aren't
>>>>> quite as
>>>>> consequential.
>>>>
>>>> That is like looking for alternatives to 5 > 3
>>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>>
>>>>>>> That would have far-reaching consequences. Before going there, maybe
>>>>>>> think up some simpler, alternative explanations and eliminate them.
>>>>>> There are no alternatives to immutable verified facts. H(P,P)
>>>>>> halts only
>>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>>
>>>>>> Technically competent software engineers would agree. On the basis of
>>>>>> the much more complete details that I provided in my original post.
>>>>>>
>>>>>> When P(P) is called from main its behavior depends on the return
>>>>>> value
>>>>>> of H. When H is called from main P(P) cannot possibly depend on the
>>>>>> return value of H because the correctly emulated input to H(P,P)
>>>>>> continues to remain stuck in infinite emulation until H aborts it.
>>>>>>
>>>>> That would be one consequence of going with your explanation. We'd
>>>>> have to
>>>>> say the behaviour of P(P) differs depending on caller. As I said,
>>>>> try simpler,
>>>>> less far-reaching explanations first.
>>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> H(P,P)==0 is provably correct
>>>> H1(P,P)==1 is provably correct.
>>>> H1(P,P) reports on the behavior of P(P).
>>>>
>>>
>>> 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. The actual behavior of the actual input to
>>> H(P,P) is non halting thus rejecting its input is necessarily correct.
>>>
>>>
>>
>> You have this wrong.
>>
>> A decider must compute the mapping that represents the FUNCTION it is
>> deciding, there is actually nothing about "behavior" in the definition.
>>
>> For a HALTING decider, that mapping is based on the HALTING Behavior
>> of the machine the input REPRESENTS.
>
> If you construe this as the actual behavior that the actual input
> specifies then this is correct otherwise this is incorrect.
If it isn't the acutual behavior, then it just isn't a Halt Decider, but
maybe your POOP decider.
DEFINITIONS, you know.
>
> People that actually understand these things deeply on the basis of all
> of the deep connected meanings will agree. People that understand these
> things only by the rote memorization of what textbooks say may get
> confused.
>
> This is computer science that I wrote that is verifiably correct and
> clarifies the misconceptions of what a halt decider must do:
>
> 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. Copyright Olcott 2021
>
Which isn't correct unless that actual behavior matches that defined by
the definition of an ACTUAL Halt Decider, which is the behavior of the
machine the input represents.
You don't get to change definitions.
Note, you also don't get to copyright definitions, just your artistic
representation of them.
I guess due to your degree of artistic license you take with
definitions, you might be able to claim copyright on your versions.
After all, they are a work of fiction. (maybe just semi-fiction).
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 19:30 -0500 |
| Message-ID | <4p6dnXAnR8quKS7_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52795 |
On 6/22/2022 7:22 PM, Richard Damon wrote:
> On 6/22/22 7:39 PM, olcott wrote:
>> On 6/22/2022 6:05 PM, Richard Damon wrote:
>>> On 6/22/22 10:55 AM, olcott wrote:
>>>> On 6/22/2022 7:53 AM, olcott wrote:
>>>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns
>>>>>>>>>> 0, so H
>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>> Linz and others were aware that: A halt decider must compute
>>>>>>>>> the mapping
>>>>>>>>> from its inputs to an accept or reject state on the basis of
>>>>>>>>> the actual
>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>> Linz and others made the false assumption that the actual
>>>>>>>>> behavior that
>>>>>>>>> is actually specified by the inputs to a simulating halt
>>>>>>>>> decider is not
>>>>>>>>> the same as the direct execution of these inputs. They were
>>>>>>>>> unaware of
>>>>>>>>> this because no one previously fully examined a simulating halt
>>>>>>>>> decider
>>>>>>>>> ever before.
>>>>>>>>>> especially if that is what P calls
>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>
>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H
>>>>>>>>>> is wrong.
>>>>>>>>>
>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt
>>>>>>>> decider H
>>>>>>>> reports it as non-halting. So it's reasonable to assume that H
>>>>>>>> is correct.
>>>>>>>>
>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That
>>>>>>>> "the
>>>>>>>> actual behaviour that is actually specified by the inputs to a
>>>>>>>> simulating
>>>>>>>> halt decider is not the same as the direct execution of these
>>>>>>>> inputs"?
>>>>>>> That is an actual immutable verified fact.
>>>>>>>
>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>> reports "non-halting".
>>>>>> You've run P(P), and it halts.
>>>>>> So one explanation is the one you've given but, as I said, that
>>>>>> explanation has
>>>>>> rather far-reaching consequences. In these circumstances, the
>>>>>> sensible
>>>>>> scientist (or I suppose mathematician, though I'm a scientist and
>>>>>> not a
>>>>>> mathematician) looks for alternative explanations which aren't
>>>>>> quite as
>>>>>> consequential.
>>>>>
>>>>> That is like looking for alternatives to 5 > 3
>>>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>>>
>>>>>>>> That would have far-reaching consequences. Before going there,
>>>>>>>> maybe
>>>>>>>> think up some simpler, alternative explanations and eliminate them.
>>>>>>> There are no alternatives to immutable verified facts. H(P,P)
>>>>>>> halts only
>>>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>>>
>>>>>>> Technically competent software engineers would agree. On the
>>>>>>> basis of
>>>>>>> the much more complete details that I provided in my original post.
>>>>>>>
>>>>>>> When P(P) is called from main its behavior depends on the return
>>>>>>> value
>>>>>>> of H. When H is called from main P(P) cannot possibly depend on the
>>>>>>> return value of H because the correctly emulated input to H(P,P)
>>>>>>> continues to remain stuck in infinite emulation until H aborts it.
>>>>>>>
>>>>>> That would be one consequence of going with your explanation. We'd
>>>>>> have to
>>>>>> say the behaviour of P(P) differs depending on caller. As I said,
>>>>>> try simpler,
>>>>>> less far-reaching explanations first.
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>>
>>>>> H(P,P)==0 is provably correct
>>>>> H1(P,P)==1 is provably correct.
>>>>> H1(P,P) reports on the behavior of P(P).
>>>>>
>>>>
>>>> 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. The actual behavior of the actual input
>>>> to H(P,P) is non halting thus rejecting its input is necessarily
>>>> correct.
>>>>
>>>>
>>>
>>> You have this wrong.
>>>
>>> A decider must compute the mapping that represents the FUNCTION it is
>>> deciding, there is actually nothing about "behavior" in the definition.
>>>
>>> For a HALTING decider, that mapping is based on the HALTING Behavior
>>> of the machine the input REPRESENTS.
>>
>> If you construe this as the actual behavior that the actual input
>> specifies then this is correct otherwise this is incorrect.
>
> If it isn't the acutual behavior, then it just isn't a Halt Decider, but
> maybe your POOP decider.
>
The behavior of P(P) is provably not the actual behavior of the actual
input to H(P,P). That you are insufficiently technically competent to
verify this is far less than no rebuttal at all.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-22 20:56 -0400 |
| Message-ID | <DSOsK.102530$ssF.37950@fx14.iad> |
| In reply to | #52797 |
On 6/22/22 8:30 PM, olcott wrote:
> On 6/22/2022 7:22 PM, Richard Damon wrote:
>> On 6/22/22 7:39 PM, olcott wrote:
>>> On 6/22/2022 6:05 PM, Richard Damon wrote:
>>>> On 6/22/22 10:55 AM, olcott wrote:
>>>>> On 6/22/2022 7:53 AM, olcott wrote:
>>>>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns
>>>>>>>>>>> 0, so H
>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>> Linz and others were aware that: A halt decider must compute
>>>>>>>>>> the mapping
>>>>>>>>>> from its inputs to an accept or reject state on the basis of
>>>>>>>>>> the actual
>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>> Linz and others made the false assumption that the actual
>>>>>>>>>> behavior that
>>>>>>>>>> is actually specified by the inputs to a simulating halt
>>>>>>>>>> decider is not
>>>>>>>>>> the same as the direct execution of these inputs. They were
>>>>>>>>>> unaware of
>>>>>>>>>> this because no one previously fully examined a simulating
>>>>>>>>>> halt decider
>>>>>>>>>> ever before.
>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>
>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H
>>>>>>>>>>> is wrong.
>>>>>>>>>>
>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt
>>>>>>>>> decider H
>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H
>>>>>>>>> is correct.
>>>>>>>>>
>>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That
>>>>>>>>> "the
>>>>>>>>> actual behaviour that is actually specified by the inputs to a
>>>>>>>>> simulating
>>>>>>>>> halt decider is not the same as the direct execution of these
>>>>>>>>> inputs"?
>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>
>>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>> reports "non-halting".
>>>>>>> You've run P(P), and it halts.
>>>>>>> So one explanation is the one you've given but, as I said, that
>>>>>>> explanation has
>>>>>>> rather far-reaching consequences. In these circumstances, the
>>>>>>> sensible
>>>>>>> scientist (or I suppose mathematician, though I'm a scientist and
>>>>>>> not a
>>>>>>> mathematician) looks for alternative explanations which aren't
>>>>>>> quite as
>>>>>>> consequential.
>>>>>>
>>>>>> That is like looking for alternatives to 5 > 3
>>>>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>>>>
>>>>>>>>> That would have far-reaching consequences. Before going there,
>>>>>>>>> maybe
>>>>>>>>> think up some simpler, alternative explanations and eliminate
>>>>>>>>> them.
>>>>>>>> There are no alternatives to immutable verified facts. H(P,P)
>>>>>>>> halts only
>>>>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>>>>
>>>>>>>> Technically competent software engineers would agree. On the
>>>>>>>> basis of
>>>>>>>> the much more complete details that I provided in my original post.
>>>>>>>>
>>>>>>>> When P(P) is called from main its behavior depends on the return
>>>>>>>> value
>>>>>>>> of H. When H is called from main P(P) cannot possibly depend on the
>>>>>>>> return value of H because the correctly emulated input to H(P,P)
>>>>>>>> continues to remain stuck in infinite emulation until H aborts it.
>>>>>>>>
>>>>>>> That would be one consequence of going with your explanation.
>>>>>>> We'd have to
>>>>>>> say the behaviour of P(P) differs depending on caller. As I said,
>>>>>>> try simpler,
>>>>>>> less far-reaching explanations first.
>>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> H(P,P)==0 is provably correct
>>>>>> H1(P,P)==1 is provably correct.
>>>>>> H1(P,P) reports on the behavior of P(P).
>>>>>>
>>>>>
>>>>> 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. The actual behavior of the
>>>>> actual input to H(P,P) is non halting thus rejecting its input is
>>>>> necessarily correct.
>>>>>
>>>>>
>>>>
>>>> You have this wrong.
>>>>
>>>> A decider must compute the mapping that represents the FUNCTION it
>>>> is deciding, there is actually nothing about "behavior" in the
>>>> definition.
>>>>
>>>> For a HALTING decider, that mapping is based on the HALTING Behavior
>>>> of the machine the input REPRESENTS.
>>>
>>> If you construe this as the actual behavior that the actual input
>>> specifies then this is correct otherwise this is incorrect.
>>
>> If it isn't the acutual behavior, then it just isn't a Halt Decider,
>> but maybe your POOP decider.
>>
> The behavior of P(P) is provably not the actual behavior of the actual
> input to H(P,P). That you are insufficiently technically competent to
> verify this is far less than no rebuttal at all.
>
THen prove it. You know state the established basis in the field that
you start your argument from, and the step by step logic to get to that
answer.
Be prepared to give sources for your claimed "established basises".
Since for the Halting Problem, it is definitional, this will be hard to do.
It may well be that YOUR H shows a different behavior, but that just
shows it isn't actually a Halt Decider.
Remember the Definition:
H applied to M, w must accept if M applied to x halts in a finite number
of steps, and reject if M applied to x will not halt even when taken to
an unbounded number of steps.
DEFINITION.
H^ / P is DEFINED in the Linz proof to be asking H about P applied to
its own input.
Thus if P uses H applied to P, P, then for P to have been built
correctly, that input must refer to P applied to P.
Thus if P(P) isn't what H(P,P) is actually asking about, then either H
or P has been not defined correctly.
YOU FAIL.
You can't claim conformance to the requirements of the proof you are
countering and have H(P,P) not be looking at the behavor of P(P).
Doesn't matter if it is impossible to ask H that, such an impossiblity
is just support for the Theorem you are trying to disprove.
You arguments are just showing you don't even understand that basics of
the problem you have worked on for decades, which shows how much you
have wasted your time.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 20:03 -0500 |
| Message-ID | <PqydnQ8hC5luJi7_nZ2dnUU7_8xh4p2d@giganews.com> |
| In reply to | #52802 |
On 6/22/2022 7:56 PM, Richard Damon wrote:
> On 6/22/22 8:30 PM, olcott wrote:
>> On 6/22/2022 7:22 PM, Richard Damon wrote:
>>> On 6/22/22 7:39 PM, olcott wrote:
>>>> On 6/22/2022 6:05 PM, Richard Damon wrote:
>>>>> On 6/22/22 10:55 AM, olcott wrote:
>>>>>> On 6/22/2022 7:53 AM, olcott wrote:
>>>>>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P)
>>>>>>>>>>>> returns 0, so H
>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>> Linz and others were aware that: A halt decider must compute
>>>>>>>>>>> the mapping
>>>>>>>>>>> from its inputs to an accept or reject state on the basis of
>>>>>>>>>>> the actual
>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>> Linz and others made the false assumption that the actual
>>>>>>>>>>> behavior that
>>>>>>>>>>> is actually specified by the inputs to a simulating halt
>>>>>>>>>>> decider is not
>>>>>>>>>>> the same as the direct execution of these inputs. They were
>>>>>>>>>>> unaware of
>>>>>>>>>>> this because no one previously fully examined a simulating
>>>>>>>>>>> halt decider
>>>>>>>>>>> ever before.
>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>
>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H
>>>>>>>>>>>> is wrong.
>>>>>>>>>>>
>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt
>>>>>>>>>> decider H
>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H
>>>>>>>>>> is correct.
>>>>>>>>>>
>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude?
>>>>>>>>>> That "the
>>>>>>>>>> actual behaviour that is actually specified by the inputs to a
>>>>>>>>>> simulating
>>>>>>>>>> halt decider is not the same as the direct execution of these
>>>>>>>>>> inputs"?
>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>
>>>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>> reports "non-halting".
>>>>>>>> You've run P(P), and it halts.
>>>>>>>> So one explanation is the one you've given but, as I said, that
>>>>>>>> explanation has
>>>>>>>> rather far-reaching consequences. In these circumstances, the
>>>>>>>> sensible
>>>>>>>> scientist (or I suppose mathematician, though I'm a scientist
>>>>>>>> and not a
>>>>>>>> mathematician) looks for alternative explanations which aren't
>>>>>>>> quite as
>>>>>>>> consequential.
>>>>>>>
>>>>>>> That is like looking for alternatives to 5 > 3
>>>>>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>>>>>
>>>>>>>>>> That would have far-reaching consequences. Before going there,
>>>>>>>>>> maybe
>>>>>>>>>> think up some simpler, alternative explanations and eliminate
>>>>>>>>>> them.
>>>>>>>>> There are no alternatives to immutable verified facts. H(P,P)
>>>>>>>>> halts only
>>>>>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>>>>>
>>>>>>>>> Technically competent software engineers would agree. On the
>>>>>>>>> basis of
>>>>>>>>> the much more complete details that I provided in my original
>>>>>>>>> post.
>>>>>>>>>
>>>>>>>>> When P(P) is called from main its behavior depends on the
>>>>>>>>> return value
>>>>>>>>> of H. When H is called from main P(P) cannot possibly depend on
>>>>>>>>> the
>>>>>>>>> return value of H because the correctly emulated input to H(P,P)
>>>>>>>>> continues to remain stuck in infinite emulation until H aborts it.
>>>>>>>>>
>>>>>>>> That would be one consequence of going with your explanation.
>>>>>>>> We'd have to
>>>>>>>> say the behaviour of P(P) differs depending on caller. As I
>>>>>>>> said, try simpler,
>>>>>>>> less far-reaching explanations first.
>>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>> if (H(x, x))
>>>>>>> HERE: goto HERE;
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> H(P,P)==0 is provably correct
>>>>>>> H1(P,P)==1 is provably correct.
>>>>>>> H1(P,P) reports on the behavior of P(P).
>>>>>>>
>>>>>>
>>>>>> 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. The actual behavior of the
>>>>>> actual input to H(P,P) is non halting thus rejecting its input is
>>>>>> necessarily correct.
>>>>>>
>>>>>>
>>>>>
>>>>> You have this wrong.
>>>>>
>>>>> A decider must compute the mapping that represents the FUNCTION it
>>>>> is deciding, there is actually nothing about "behavior" in the
>>>>> definition.
>>>>>
>>>>> For a HALTING decider, that mapping is based on the HALTING
>>>>> Behavior of the machine the input REPRESENTS.
>>>>
>>>> If you construe this as the actual behavior that the actual input
>>>> specifies then this is correct otherwise this is incorrect.
>>>
>>> If it isn't the acutual behavior, then it just isn't a Halt Decider,
>>> but maybe your POOP decider.
>>>
>> The behavior of P(P) is provably not the actual behavior of the actual
>> input to H(P,P). That you are insufficiently technically competent to
>> verify this is far less than no rebuttal at all.
>>
>
> THen prove it.
I have proved it dozens of times and every fake "rebuttal" simply
ignores the proof.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-22 21:19 -0400 |
| Message-ID | <icPsK.130557$ntj.119007@fx15.iad> |
| In reply to | #52805 |
On 6/22/22 9:03 PM, olcott wrote:
> On 6/22/2022 7:56 PM, Richard Damon wrote:
>> On 6/22/22 8:30 PM, olcott wrote:
>>> On 6/22/2022 7:22 PM, Richard Damon wrote:
>>>> On 6/22/22 7:39 PM, olcott wrote:
>>>>> On 6/22/2022 6:05 PM, Richard Damon wrote:
>>>>>> On 6/22/22 10:55 AM, olcott wrote:
>>>>>>> On 6/22/2022 7:53 AM, olcott wrote:
>>>>>>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P)
>>>>>>>>>>>>> returns 0, so H
>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is
>>>>>>>>>>>>> the
>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>> Linz and others were aware that: A halt decider must compute
>>>>>>>>>>>> the mapping
>>>>>>>>>>>> from its inputs to an accept or reject state on the basis of
>>>>>>>>>>>> the actual
>>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>>> Linz and others made the false assumption that the actual
>>>>>>>>>>>> behavior that
>>>>>>>>>>>> is actually specified by the inputs to a simulating halt
>>>>>>>>>>>> decider is not
>>>>>>>>>>>> the same as the direct execution of these inputs. They were
>>>>>>>>>>>> unaware of
>>>>>>>>>>>> this because no one previously fully examined a simulating
>>>>>>>>>>>> halt decider
>>>>>>>>>>>> ever before.
>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or
>>>>>>>>>>>>> H is wrong.
>>>>>>>>>>>>
>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the
>>>>>>>>>>> halt decider H
>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that
>>>>>>>>>>> H is correct.
>>>>>>>>>>>
>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude?
>>>>>>>>>>> That "the
>>>>>>>>>>> actual behaviour that is actually specified by the inputs to
>>>>>>>>>>> a simulating
>>>>>>>>>>> halt decider is not the same as the direct execution of these
>>>>>>>>>>> inputs"?
>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>
>>>>>>>>> That's your conclusion from your observations and reasoning.
>>>>>>>>> You've
>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>>> reports "non-halting".
>>>>>>>>> You've run P(P), and it halts.
>>>>>>>>> So one explanation is the one you've given but, as I said, that
>>>>>>>>> explanation has
>>>>>>>>> rather far-reaching consequences. In these circumstances, the
>>>>>>>>> sensible
>>>>>>>>> scientist (or I suppose mathematician, though I'm a scientist
>>>>>>>>> and not a
>>>>>>>>> mathematician) looks for alternative explanations which aren't
>>>>>>>>> quite as
>>>>>>>>> consequential.
>>>>>>>>
>>>>>>>> That is like looking for alternatives to 5 > 3
>>>>>>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>>>>>>
>>>>>>>>>>> That would have far-reaching consequences. Before going
>>>>>>>>>>> there, maybe
>>>>>>>>>>> think up some simpler, alternative explanations and eliminate
>>>>>>>>>>> them.
>>>>>>>>>> There are no alternatives to immutable verified facts. H(P,P)
>>>>>>>>>> halts only
>>>>>>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>>>>>>
>>>>>>>>>> Technically competent software engineers would agree. On the
>>>>>>>>>> basis of
>>>>>>>>>> the much more complete details that I provided in my original
>>>>>>>>>> post.
>>>>>>>>>>
>>>>>>>>>> When P(P) is called from main its behavior depends on the
>>>>>>>>>> return value
>>>>>>>>>> of H. When H is called from main P(P) cannot possibly depend
>>>>>>>>>> on the
>>>>>>>>>> return value of H because the correctly emulated input to H(P,P)
>>>>>>>>>> continues to remain stuck in infinite emulation until H aborts
>>>>>>>>>> it.
>>>>>>>>>>
>>>>>>>>> That would be one consequence of going with your explanation.
>>>>>>>>> We'd have to
>>>>>>>>> say the behaviour of P(P) differs depending on caller. As I
>>>>>>>>> said, try simpler,
>>>>>>>>> less far-reaching explanations first.
>>>>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>> if (H(x, x))
>>>>>>>> HERE: goto HERE;
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> H(P,P)==0 is provably correct
>>>>>>>> H1(P,P)==1 is provably correct.
>>>>>>>> H1(P,P) reports on the behavior of P(P).
>>>>>>>>
>>>>>>>
>>>>>>> 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. The actual behavior of the
>>>>>>> actual input to H(P,P) is non halting thus rejecting its input is
>>>>>>> necessarily correct.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> You have this wrong.
>>>>>>
>>>>>> A decider must compute the mapping that represents the FUNCTION it
>>>>>> is deciding, there is actually nothing about "behavior" in the
>>>>>> definition.
>>>>>>
>>>>>> For a HALTING decider, that mapping is based on the HALTING
>>>>>> Behavior of the machine the input REPRESENTS.
>>>>>
>>>>> If you construe this as the actual behavior that the actual input
>>>>> specifies then this is correct otherwise this is incorrect.
>>>>
>>>> If it isn't the acutual behavior, then it just isn't a Halt Decider,
>>>> but maybe your POOP decider.
>>>>
>>> The behavior of P(P) is provably not the actual behavior of the
>>> actual input to H(P,P). That you are insufficiently technically
>>> competent to verify this is far less than no rebuttal at all.
>>>
>>
>> THen prove it.
>
> I have proved it dozens of times and every fake "rebuttal" simply
> ignores the proof.
>
>
Nope, you have claimed it, and given rhetorical arguments.
You don't even seem to understand what a PROOF is, so that may be your
problem.
I haven't once seen you start with a list of ACCEPTED truths in the
field and progressed from there. You ALWAYS throw in something that is
"true by the meaning of the words" that actually isn't because you don't
know the actual meaning of the words, and can't actually quote tem as
they apply to the field.
You don't understand that Natural Language is NOT the source of Truth,
but is actually one of the traps of logic that leads the unwary into error.
Truth comes out of FORMAL meaning and agreement with reality.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-22 20:33 -0500 |
| Message-ID | <Rsedne9oy-tSXy7_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #52810 |
On 6/22/2022 8:19 PM, Richard Damon wrote:
> On 6/22/22 9:03 PM, olcott wrote:
>> On 6/22/2022 7:56 PM, Richard Damon wrote:
>>> On 6/22/22 8:30 PM, olcott wrote:
>>>> On 6/22/2022 7:22 PM, Richard Damon wrote:
>>>>> On 6/22/22 7:39 PM, olcott wrote:
>>>>>> On 6/22/2022 6:05 PM, Richard Damon wrote:
>>>>>>> On 6/22/22 10:55 AM, olcott wrote:
>>>>>>>> On 6/22/2022 7:53 AM, olcott wrote:
>>>>>>>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P)
>>>>>>>>>>>>>> returns 0, so H
>>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P)
>>>>>>>>>>>>>> is the
>>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>>> Linz and others were aware that: A halt decider must
>>>>>>>>>>>>> compute the mapping
>>>>>>>>>>>>> from its inputs to an accept or reject state on the basis
>>>>>>>>>>>>> of the actual
>>>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>>>> Linz and others made the false assumption that the actual
>>>>>>>>>>>>> behavior that
>>>>>>>>>>>>> is actually specified by the inputs to a simulating halt
>>>>>>>>>>>>> decider is not
>>>>>>>>>>>>> the same as the direct execution of these inputs. They were
>>>>>>>>>>>>> unaware of
>>>>>>>>>>>>> this because no one previously fully examined a simulating
>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>> ever before.
>>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or
>>>>>>>>>>>>>> H is wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the
>>>>>>>>>>>> halt decider H
>>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that
>>>>>>>>>>>> H is correct.
>>>>>>>>>>>>
>>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude?
>>>>>>>>>>>> That "the
>>>>>>>>>>>> actual behaviour that is actually specified by the inputs to
>>>>>>>>>>>> a simulating
>>>>>>>>>>>> halt decider is not the same as the direct execution of
>>>>>>>>>>>> these inputs"?
>>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>>
>>>>>>>>>> That's your conclusion from your observations and reasoning.
>>>>>>>>>> You've
>>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and
>>>>>>>>>> it reports "non-halting".
>>>>>>>>>> You've run P(P), and it halts.
>>>>>>>>>> So one explanation is the one you've given but, as I said,
>>>>>>>>>> that explanation has
>>>>>>>>>> rather far-reaching consequences. In these circumstances, the
>>>>>>>>>> sensible
>>>>>>>>>> scientist (or I suppose mathematician, though I'm a scientist
>>>>>>>>>> and not a
>>>>>>>>>> mathematician) looks for alternative explanations which aren't
>>>>>>>>>> quite as
>>>>>>>>>> consequential.
>>>>>>>>>
>>>>>>>>> That is like looking for alternatives to 5 > 3
>>>>>>>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>>>>>>>
>>>>>>>>>>>> That would have far-reaching consequences. Before going
>>>>>>>>>>>> there, maybe
>>>>>>>>>>>> think up some simpler, alternative explanations and
>>>>>>>>>>>> eliminate them.
>>>>>>>>>>> There are no alternatives to immutable verified facts. H(P,P)
>>>>>>>>>>> halts only
>>>>>>>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>>>>>>>
>>>>>>>>>>> Technically competent software engineers would agree. On the
>>>>>>>>>>> basis of
>>>>>>>>>>> the much more complete details that I provided in my original
>>>>>>>>>>> post.
>>>>>>>>>>>
>>>>>>>>>>> When P(P) is called from main its behavior depends on the
>>>>>>>>>>> return value
>>>>>>>>>>> of H. When H is called from main P(P) cannot possibly depend
>>>>>>>>>>> on the
>>>>>>>>>>> return value of H because the correctly emulated input to H(P,P)
>>>>>>>>>>> continues to remain stuck in infinite emulation until H
>>>>>>>>>>> aborts it.
>>>>>>>>>>>
>>>>>>>>>> That would be one consequence of going with your explanation.
>>>>>>>>>> We'd have to
>>>>>>>>>> say the behaviour of P(P) differs depending on caller. As I
>>>>>>>>>> said, try simpler,
>>>>>>>>>> less far-reaching explanations first.
>>>>>>>>>
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>> if (H(x, x))
>>>>>>>>> HERE: goto HERE;
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> H(P,P)==0 is provably correct
>>>>>>>>> H1(P,P)==1 is provably correct.
>>>>>>>>> H1(P,P) reports on the behavior of P(P).
>>>>>>>>>
>>>>>>>>
>>>>>>>> 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. The actual behavior of
>>>>>>>> the actual input to H(P,P) is non halting thus rejecting its
>>>>>>>> input is necessarily correct.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> You have this wrong.
>>>>>>>
>>>>>>> A decider must compute the mapping that represents the FUNCTION
>>>>>>> it is deciding, there is actually nothing about "behavior" in the
>>>>>>> definition.
>>>>>>>
>>>>>>> For a HALTING decider, that mapping is based on the HALTING
>>>>>>> Behavior of the machine the input REPRESENTS.
>>>>>>
>>>>>> If you construe this as the actual behavior that the actual input
>>>>>> specifies then this is correct otherwise this is incorrect.
>>>>>
>>>>> If it isn't the acutual behavior, then it just isn't a Halt
>>>>> Decider, but maybe your POOP decider.
>>>>>
>>>> The behavior of P(P) is provably not the actual behavior of the
>>>> actual input to H(P,P). That you are insufficiently technically
>>>> competent to verify this is far less than no rebuttal at all.
>>>>
>>>
>>> THen prove it.
>>
>> I have proved it dozens of times and every fake "rebuttal" simply
>> ignores the proof.
>>
>>
>
> Nope, you have claimed it, and given rhetorical arguments.
I have provided a complete provably correct execution traces of H(P,P)
and P(P) that conclusively proves that they really do have different
behavior yet people rejected it on the basis that they simply do not
"believe in" the x86 language. This is why I aptly called them
despicable liars.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-22 21:49 -0400 |
| Message-ID | <3FPsK.102532$ssF.35577@fx14.iad> |
| In reply to | #52815 |
On 6/22/22 9:33 PM, olcott wrote:
> On 6/22/2022 8:19 PM, Richard Damon wrote:
>> On 6/22/22 9:03 PM, olcott wrote:
>>> On 6/22/2022 7:56 PM, Richard Damon wrote:
>>>> On 6/22/22 8:30 PM, olcott wrote:
>>>>> On 6/22/2022 7:22 PM, Richard Damon wrote:
>>>>>> On 6/22/22 7:39 PM, olcott wrote:
>>>>>>> On 6/22/2022 6:05 PM, Richard Damon wrote:
>>>>>>>> On 6/22/22 10:55 AM, olcott wrote:
>>>>>>>>> On 6/22/2022 7:53 AM, olcott wrote:
>>>>>>>>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P)
>>>>>>>>>>>>>>> returns 0, so H
>>>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P)
>>>>>>>>>>>>>>> is the
>>>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>>>> Linz and others were aware that: A halt decider must
>>>>>>>>>>>>>> compute the mapping
>>>>>>>>>>>>>> from its inputs to an accept or reject state on the basis
>>>>>>>>>>>>>> of the actual
>>>>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>>>>> Linz and others made the false assumption that the actual
>>>>>>>>>>>>>> behavior that
>>>>>>>>>>>>>> is actually specified by the inputs to a simulating halt
>>>>>>>>>>>>>> decider is not
>>>>>>>>>>>>>> the same as the direct execution of these inputs. They
>>>>>>>>>>>>>> were unaware of
>>>>>>>>>>>>>> this because no one previously fully examined a simulating
>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>> ever before.
>>>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight,
>>>>>>>>>>>>>>> or H is wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the
>>>>>>>>>>>>> halt decider H
>>>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume
>>>>>>>>>>>>> that H is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude?
>>>>>>>>>>>>> That "the
>>>>>>>>>>>>> actual behaviour that is actually specified by the inputs
>>>>>>>>>>>>> to a simulating
>>>>>>>>>>>>> halt decider is not the same as the direct execution of
>>>>>>>>>>>>> these inputs"?
>>>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>>>
>>>>>>>>>>> That's your conclusion from your observations and reasoning.
>>>>>>>>>>> You've
>>>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and
>>>>>>>>>>> it reports "non-halting".
>>>>>>>>>>> You've run P(P), and it halts.
>>>>>>>>>>> So one explanation is the one you've given but, as I said,
>>>>>>>>>>> that explanation has
>>>>>>>>>>> rather far-reaching consequences. In these circumstances, the
>>>>>>>>>>> sensible
>>>>>>>>>>> scientist (or I suppose mathematician, though I'm a scientist
>>>>>>>>>>> and not a
>>>>>>>>>>> mathematician) looks for alternative explanations which
>>>>>>>>>>> aren't quite as
>>>>>>>>>>> consequential.
>>>>>>>>>>
>>>>>>>>>> That is like looking for alternatives to 5 > 3
>>>>>>>>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>>>>>>>>
>>>>>>>>>>>>> That would have far-reaching consequences. Before going
>>>>>>>>>>>>> there, maybe
>>>>>>>>>>>>> think up some simpler, alternative explanations and
>>>>>>>>>>>>> eliminate them.
>>>>>>>>>>>> There are no alternatives to immutable verified facts.
>>>>>>>>>>>> H(P,P) halts only
>>>>>>>>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>>>>>>>>
>>>>>>>>>>>> Technically competent software engineers would agree. On the
>>>>>>>>>>>> basis of
>>>>>>>>>>>> the much more complete details that I provided in my
>>>>>>>>>>>> original post.
>>>>>>>>>>>>
>>>>>>>>>>>> When P(P) is called from main its behavior depends on the
>>>>>>>>>>>> return value
>>>>>>>>>>>> of H. When H is called from main P(P) cannot possibly depend
>>>>>>>>>>>> on the
>>>>>>>>>>>> return value of H because the correctly emulated input to
>>>>>>>>>>>> H(P,P)
>>>>>>>>>>>> continues to remain stuck in infinite emulation until H
>>>>>>>>>>>> aborts it.
>>>>>>>>>>>>
>>>>>>>>>>> That would be one consequence of going with your explanation.
>>>>>>>>>>> We'd have to
>>>>>>>>>>> say the behaviour of P(P) differs depending on caller. As I
>>>>>>>>>>> said, try simpler,
>>>>>>>>>>> less far-reaching explanations first.
>>>>>>>>>>
>>>>>>>>>> void P(u32 x)
>>>>>>>>>> {
>>>>>>>>>> if (H(x, x))
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> H(P,P)==0 is provably correct
>>>>>>>>>> H1(P,P)==1 is provably correct.
>>>>>>>>>> H1(P,P) reports on the behavior of P(P).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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. The actual behavior of
>>>>>>>>> the actual input to H(P,P) is non halting thus rejecting its
>>>>>>>>> input is necessarily correct.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> You have this wrong.
>>>>>>>>
>>>>>>>> A decider must compute the mapping that represents the FUNCTION
>>>>>>>> it is deciding, there is actually nothing about "behavior" in
>>>>>>>> the definition.
>>>>>>>>
>>>>>>>> For a HALTING decider, that mapping is based on the HALTING
>>>>>>>> Behavior of the machine the input REPRESENTS.
>>>>>>>
>>>>>>> If you construe this as the actual behavior that the actual input
>>>>>>> specifies then this is correct otherwise this is incorrect.
>>>>>>
>>>>>> If it isn't the acutual behavior, then it just isn't a Halt
>>>>>> Decider, but maybe your POOP decider.
>>>>>>
>>>>> The behavior of P(P) is provably not the actual behavior of the
>>>>> actual input to H(P,P). That you are insufficiently technically
>>>>> competent to verify this is far less than no rebuttal at all.
>>>>>
>>>>
>>>> THen prove it.
>>>
>>> I have proved it dozens of times and every fake "rebuttal" simply
>>> ignores the proof.
>>>
>>>
>>
>> Nope, you have claimed it, and given rhetorical arguments.
>
> I have provided a complete provably correct execution traces of H(P,P)
> and P(P) that conclusively proves that they really do have different
> behavior yet people rejected it on the basis that they simply do not
> "believe in" the x86 language. This is why I aptly called them
> despicable liars.
>
Nope.
The trace you provide are NOT correct traces, as a CORRECT x86 trace of
the execution of P will show the instructions in H that get exectuted.
Thus, you are PROVEN to have just LIED.
it seems you wouldn't know what Truth was if it bit you, but it seems it
doesn't want to touch you with a 39 1/2 foot pole.
If you want to actually PROVE your claim, what is the FIRST x86
instruction in the execution sequence of the two that produces a
different result from the same input.
Since you have the program, that should be simple for you to find.
I have asked for this before, and you failure to provide it just shows
that you are lying.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-06-22 16:50 +0100 |
| Message-ID | <87a6a44s02.fsf@bsb.me.uk> |
| In reply to | #52760 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >> On 6/22/2022 2:55 AM, Malcolm McLean wrote: >> > On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >> >> On 6/21/2022 9:52 PM, Richard Damon wrote: >> >>> >> >>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H >> >>> was incorrect in its mapping, since the behavior of P(P) is the >> >>> DEFINITION of the behavior of H(P,P), >> >> Linz and others were aware that: A halt decider must compute the mapping >> >> from its inputs to an accept or reject state on the basis of the actual >> >> behavior that is actually specified by these inputs. >> >> Linz and others made the false assumption that the actual behavior that >> >> is actually specified by the inputs to a simulating halt decider is not >> >> the same as the direct execution of these inputs. They were unaware of >> >> this because no one previously fully examined a simulating halt decider >> >> ever before. >> >>> especially if that is what P calls >> >>> and P is claimed to be built by the Linz template. >> >>> >> >>> So, either P isn't built right, or H isn't built fight, or H is wrong. >> >> >> > You've dry-run P(P) and it doesn't halt. Additionally the halt decider H >> > reports it as non-halting. So it's reasonable to assume that H is correct. >> > >> > However, when run, P(P) halts. So what are we to conclude? That "the >> > actual behaviour that is actually specified by the inputs to a simulating >> > halt decider is not the same as the direct execution of these inputs"? >> >> That is an actual immutable verified fact. >> > That's your conclusion from your observations and reasoning. You've > dry-run P(P), and it doesn't halt. You've run H on P(P), and it > reports "non-halting". You've run P(P), and it halts. So one > explanation is the one you've given but, as I said, that explanation > has rather far-reaching consequences. There is only one explanation. What you call the "dry-run" is not that same as the P(P). We've known this since the "line 15 commented out" days. There are two computations -- one that is not stopped and one that is, the "dry-run" and the run, the "simulation of the input to H(P,P)" and P(P). All PO is doing is trying to find words that hide what's going on. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | comp.theory
csiph-web