Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #38464 > unrolled thread
| Started by | olcott <NoOne@NoWhere.com> |
|---|---|
| First post | 2021-08-28 11:47 -0500 |
| Last post | 2021-08-28 20:00 -0400 |
| Articles | 20 on this page of 733 — 10 participants |
Back to article view | Back to comp.theory
That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-28 11:47 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-28 14:52 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-28 14:12 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-28 16:24 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-28 15:33 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-28 16:46 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-28 16:55 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-28 18:29 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-28 17:38 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-28 17:38 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-28 19:32 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-28 18:46 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-28 18:51 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-28 20:07 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-28 23:00 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-29 07:00 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] olcott <NoOne@NoWhere.com> - 2021-08-29 08:28 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-29 16:20 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] olcott <NoOne@NoWhere.com> - 2021-08-29 10:30 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-29 17:19 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] olcott <NoOne@NoWhere.com> - 2021-08-29 11:36 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-30 01:00 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] olcott <NoOne@NoWhere.com> - 2021-08-29 20:42 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-31 03:17 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] olcott <NoOne@NoWhere.com> - 2021-08-30 21:35 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-31 04:04 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] olcott <NoOne@NoWhere.com> - 2021-08-30 22:20 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] André G. Isaak <agisaak@gm.invalid> - 2021-08-30 21:35 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] olcott <NoOne@NoWhere.com> - 2021-08-30 23:00 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] André G. Isaak <agisaak@gm.invalid> - 2021-08-30 22:19 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] olcott <NoOne@NoWhere.com> - 2021-08-30 23:31 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] André G. Isaak <agisaak@gm.invalid> - 2021-08-30 22:45 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] olcott <NoOne@NoWhere.com> - 2021-08-31 09:24 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] André G. Isaak <agisaak@gm.invalid> - 2021-08-31 09:07 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] olcott <NoOne@NoWhere.com> - 2021-08-31 11:08 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] olcott <NoOne@NoWhere.com> - 2021-08-31 11:11 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] André G. Isaak <agisaak@gm.invalid> - 2021-08-31 10:31 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] olcott <NoOne@NoWhere.com> - 2021-08-31 11:49 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] André G. Isaak <agisaak@gm.invalid> - 2021-08-31 11:00 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] olcott <NoOne@NoWhere.com> - 2021-08-31 12:55 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] André G. Isaak <agisaak@gm.invalid> - 2021-08-31 12:40 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] olcott <NoOne@NoWhere.com> - 2021-08-31 14:11 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] André G. Isaak <agisaak@gm.invalid> - 2021-08-31 14:08 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] olcott <NoOne@NoWhere.com> - 2021-08-31 16:34 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] André G. Isaak <agisaak@gm.invalid> - 2021-08-31 16:40 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] olcott <NoOne@NoWhere.com> - 2021-08-31 18:29 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] André G. Isaak <agisaak@gm.invalid> - 2021-08-31 17:39 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] olcott <NoOne@NoWhere.com> - 2021-08-31 19:16 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] Richard Damon <Richard@Damon-Family.org> - 2021-08-31 20:47 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] André G. Isaak <agisaak@gm.invalid> - 2021-08-31 18:52 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] Richard Damon <Richard@Damon-Family.org> - 2021-08-31 21:23 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-31 14:17 -0700
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] olcott <NoOne@NoWhere.com> - 2021-08-31 16:48 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] Richard Damon <Richard@Damon-Family.org> - 2021-08-31 19:26 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] Richard Damon <Richard@Damon-Family.org> - 2021-08-31 21:08 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ relative invocation order ] Richard Damon <Richard@Damon-Family.org> - 2021-08-31 19:23 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] Richard Damon <Richard@Damon-Family.org> - 2021-08-31 06:35 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-31 14:55 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] olcott <NoOne@NoWhere.com> - 2021-08-31 09:28 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] Richard Damon <Richard@Damon-Family.org> - 2021-08-31 20:59 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-01 03:28 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] olcott <NoOne@NoWhere.com> - 2021-08-31 21:42 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] Richard Damon <news.x.richarddamon@xoxy.net> - 2021-08-31 23:05 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] André G. Isaak <agisaak@gm.invalid> - 2021-08-29 11:22 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] olcott <NoOne@NoWhere.com> - 2021-08-29 12:43 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] André G. Isaak <agisaak@gm.invalid> - 2021-08-29 12:06 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ air tight proof ] Richard Damon <Richard@Damon-Family.org> - 2021-08-29 15:42 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] André G. Isaak <agisaak@gm.invalid> - 2021-08-28 18:42 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-28 22:52 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] André G. Isaak <agisaak@gm.invalid> - 2021-08-28 22:07 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-28 23:13 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] André G. Isaak <agisaak@gm.invalid> - 2021-08-28 22:32 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ dishonesty ? ] olcott <NoOne@NoWhere.com> - 2021-08-28 23:27 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ dishonesty ? ] André G. Isaak <agisaak@gm.invalid> - 2021-08-28 22:34 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ dishonesty ? ] olcott <NoOne@NoWhere.com> - 2021-08-28 23:50 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ dishonesty ? ] Richard Damon <Richard@Damon-Family.org> - 2021-08-29 08:20 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-29 13:53 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] André G. Isaak <agisaak@gm.invalid> - 2021-08-29 13:32 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-29 14:40 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] André G. Isaak <agisaak@gm.invalid> - 2021-08-29 13:48 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-29 14:57 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-29 16:42 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] André G. Isaak <agisaak@gm.invalid> - 2021-08-29 16:16 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-29 18:35 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-29 20:39 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-29 21:52 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] André G. Isaak <agisaak@gm.invalid> - 2021-08-29 19:54 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-29 21:14 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-29 22:35 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] André G. Isaak <agisaak@gm.invalid> - 2021-08-29 20:38 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-29 21:51 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] André G. Isaak <agisaak@gm.invalid> - 2021-08-29 21:00 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-29 22:17 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] André G. Isaak <agisaak@gm.invalid> - 2021-08-29 21:43 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-29 22:54 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-30 06:24 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-30 09:02 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-30 20:13 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-31 03:12 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-30 21:30 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-31 03:53 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-30 22:11 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-31 06:38 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-31 15:04 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-31 09:30 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-31 21:03 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-01 03:45 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-31 22:09 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-31 22:28 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <news.x.richarddamon@xoxy.net> - 2021-09-01 07:51 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] André G. Isaak <agisaak@gm.invalid> - 2021-08-31 21:47 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-31 23:10 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] André G. Isaak <agisaak@gm.invalid> - 2021-08-31 22:26 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-08-31 23:32 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] André G. Isaak <agisaak@gm.invalid> - 2021-08-31 22:52 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-09-01 08:25 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-09-01 08:54 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-09-01 09:13 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-09-01 19:04 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-09-01 02:19 -0700
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-09-01 08:27 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-09-01 19:06 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-09-02 02:40 -0700
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-09-02 09:15 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-02 16:19 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] olcott <NoOne@NoWhere.com> - 2021-09-02 10:34 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-02 22:02 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] olcott <NoOne@NoWhere.com> - 2021-09-02 18:12 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-04 22:00 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] olcott <NoOne@NoWhere.com> - 2021-09-04 16:46 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 18:41 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-04 17:54 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 19:02 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-09-04 16:25 -0700
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-04 22:55 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-09-05 13:02 -0700
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-05 15:13 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-05 17:36 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Mike <usenet@darjeeling.plus.com> - 2021-09-05 23:37 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <news.x.richarddamon@xoxy.net> - 2021-09-05 20:16 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-06 09:42 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <news.x.richarddamon@xoxy.net> - 2021-09-06 11:06 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-06 10:26 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 12:04 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-06 14:28 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 14:22 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-06 15:50 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 15:37 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] olcott <NoOne@NoWhere.com> - 2021-09-06 16:59 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 16:58 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] olcott <NoOne@NoWhere.com> - 2021-09-06 18:21 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 17:39 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] olcott <NoOne@NoWhere.com> - 2021-09-06 18:57 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 20:04 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 18:13 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] olcott <NoOne@NoWhere.com> - 2021-09-06 19:46 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 19:07 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] olcott <NoOne@NoWhere.com> - 2021-09-06 20:32 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 20:23 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] olcott <NoOne@NoWhere.com> - 2021-09-06 21:30 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 21:34 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] olcott <NoOne@NoWhere.com> - 2021-09-06 22:42 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 21:49 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] olcott <NoOne@NoWhere.com> - 2021-09-06 22:55 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 22:08 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] olcott <NoOne@NoWhere.com> - 2021-09-06 23:35 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 23:36 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] olcott <NoOne@NoWhere.com> - 2021-09-07 08:51 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] André G. Isaak <agisaak@gm.invalid> - 2021-09-07 08:14 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] olcott <NoOne@NoWhere.com> - 2021-09-07 09:26 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-09-07 08:18 -0700
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] olcott <NoOne@NoWhere.com> - 2021-09-07 10:34 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 19:04 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] André G. Isaak <agisaak@gm.invalid> - 2021-09-07 09:39 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ][ Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 11:02 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ][ Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-07 10:46 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ][ Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 12:01 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ][ Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-07 12:14 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ][ Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 13:17 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ][ Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-07 13:39 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ][ Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 14:49 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ][ Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-07 15:07 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ][ Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 19:06 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 19:16 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] olcott <NoOne@NoWhere.com> - 2021-09-07 18:46 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 20:49 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 05:59 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] olcott <NoOne@NoWhere.com> - 2021-09-07 09:13 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 19:09 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] olcott <NoOne@NoWhere.com> - 2021-09-07 18:38 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 20:52 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 06:40 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 06:30 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] Jeff Barnett <jbb@notatt.com> - 2021-09-06 21:47 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] Jeff Barnett <jbb@notatt.com> - 2021-09-06 21:31 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 22:32 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 21:31 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pure functions ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 19:56 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 19:39 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-06 19:57 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 21:38 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-06 20:50 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-06 20:53 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 22:52 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-06 21:57 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 23:37 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-06 22:46 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 06:04 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-07 11:10 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 09:00 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-07 16:30 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 10:45 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 19:11 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 18:44 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 20:55 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-08 01:25 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 19:39 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 21:01 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-08 03:58 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 19:09 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 18:42 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 21:03 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 22:48 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-06 21:55 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 23:06 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-06 22:14 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 23:45 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-06 22:51 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 06:10 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 09:26 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] olcott <NoOne@NoWhere.com> - 2021-09-06 09:57 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ refuted Rice's theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 11:21 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-05 00:09 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] olcott <NoOne@NoWhere.com> - 2021-09-04 23:27 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-05 16:33 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] olcott <NoOne@NoWhere.com> - 2021-09-05 10:52 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] Richard Damon <Richard@Damon-Family.org> - 2021-09-05 13:03 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-05 19:48 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] olcott <NoOne@NoWhere.com> - 2021-09-05 14:05 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-05 23:46 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] olcott <NoOne@NoWhere.com> - 2021-09-06 10:00 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 11:22 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-06 21:24 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] olcott <NoOne@NoWhere.com> - 2021-09-06 16:06 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 19:10 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] olcott <NoOne@NoWhere.com> - 2021-09-06 18:25 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 20:10 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-09-02 09:10 -0700
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ pathological inputs ] olcott <NoOne@NoWhere.com> - 2021-09-02 11:32 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-02 21:38 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-09-01 06:42 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-01 15:34 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] André G. Isaak <agisaak@gm.invalid> - 2021-09-01 08:45 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-09-01 09:52 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-09-01 19:09 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-09-01 06:38 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-09-01 06:21 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-01 15:44 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-09-01 10:05 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-09-01 19:43 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-02 01:58 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-09-01 20:34 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-02 02:42 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] olcott <NoOne@NoWhere.com> - 2021-09-01 21:18 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-09-01 22:34 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Pathological Input ] olcott <NoOne@NoWhere.com> - 2021-09-01 21:53 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Pathological Input ] André G. Isaak <agisaak@gm.invalid> - 2021-09-01 22:56 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Pathological Input ] olcott <NoOne@NoWhere.com> - 2021-09-02 00:09 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Pathological Input ] André G. Isaak <agisaak@gm.invalid> - 2021-09-01 23:48 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Pathological Input ] olcott <NoOne@NoWhere.com> - 2021-09-02 10:28 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Pathological Input ] Richard Damon <Richard@Damon-Family.org> - 2021-09-02 06:17 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-02 12:28 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 10:23 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-02 22:00 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 18:20 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] André G. Isaak <agisaak@gm.invalid> - 2021-09-02 17:46 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 19:01 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] André G. Isaak <agisaak@gm.invalid> - 2021-09-02 18:20 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 19:32 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] André G. Isaak <agisaak@gm.invalid> - 2021-09-02 19:10 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-02 22:21 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 01:27 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 19:40 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 02:05 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 20:08 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 02:29 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 20:42 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-02 22:24 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 21:26 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-02 22:54 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 21:57 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-02 23:15 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 03:42 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 21:55 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-02 23:09 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 22:18 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-02 23:52 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 23:09 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] André G. Isaak <agisaak@gm.invalid> - 2021-09-02 22:59 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 09:05 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 12:49 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 15:11 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 16:58 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 16:23 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 17:31 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 06:32 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-09-03 04:47 -0700
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 14:41 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 09:20 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 15:58 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 08:51 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] André G. Isaak <agisaak@gm.invalid> - 2021-09-03 08:09 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 09:24 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] André G. Isaak <agisaak@gm.invalid> - 2021-09-03 08:33 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 09:46 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] André G. Isaak <agisaak@gm.invalid> - 2021-09-03 09:12 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 10:28 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] André G. Isaak <agisaak@gm.invalid> - 2021-09-03 09:43 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 15:01 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] André G. Isaak <agisaak@gm.invalid> - 2021-09-03 14:24 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 15:31 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] André G. Isaak <agisaak@gm.invalid> - 2021-09-03 14:58 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 16:18 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 17:43 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] André G. Isaak <agisaak@gm.invalid> - 2021-09-03 15:46 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 17:14 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 18:46 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] André G. Isaak <agisaak@gm.invalid> - 2021-09-03 17:00 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 18:57 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Jeff Barnett <jbb@notatt.com> - 2021-09-03 17:45 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 22:36 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 17:25 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-04 00:02 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 19:03 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-04 01:20 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 19:27 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 21:10 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 20:36 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 22:07 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-04 22:30 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-09-03 23:12 -0700
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-04 08:45 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 10:09 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-04 09:49 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 11:22 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-04 10:32 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 11:54 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-04 11:21 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 12:40 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-04 12:01 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 13:21 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-04 12:41 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 14:08 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-04 13:14 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 14:28 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-04 13:52 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-04 21:56 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 18:34 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 19:13 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-09-04 02:05 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 20:31 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-04 20:51 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-04 15:06 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-04 22:00 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 17:55 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-04 20:49 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Mike <usenet@darjeeling.plus.com> - 2021-09-05 03:59 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Andy Walker <anw@cuboid.co.uk> - 2021-09-04 12:58 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Jeff Barnett <jbb@notatt.com> - 2021-09-04 13:59 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-04 21:26 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-04 16:13 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-04 22:37 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 16:27 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 15:36 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 17:06 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 11:41 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 14:52 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 16:11 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 09:57 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 11:47 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 11:34 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 10:39 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 11:51 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 09:09 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 12:01 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 15:58 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 10:02 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 16:18 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 12:02 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 21:16 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 03:47 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 21:56 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Jeff Barnett <jbb@notatt.com> - 2021-09-02 22:29 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 15:58 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 10:01 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 16:16 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 10:30 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 16:50 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 14:55 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 16:34 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 15:57 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-03 17:50 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 22:40 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-03 17:27 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-04 01:07 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-03 19:25 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 11:57 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-04 11:26 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 12:42 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-04 12:05 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 13:27 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-04 12:44 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 14:11 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-04 13:42 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 15:11 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-04 14:47 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 16:17 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-04 17:36 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 18:47 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-04 18:08 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 20:14 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-04 23:02 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-05 06:40 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-05 00:34 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-04 22:58 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-05 06:44 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-05 16:22 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-05 10:28 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-05 17:24 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-05 11:48 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-05 12:16 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-05 13:21 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-05 12:34 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-05 14:26 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-05 13:50 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-05 15:32 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-05 20:48 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-05 15:25 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-05 17:45 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-06 00:14 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 10:15 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 09:30 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 11:07 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 10:17 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 14:14 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 14:15 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 15:38 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 15:28 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 16:41 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 16:53 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-09-07 02:55 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 21:07 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 20:17 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 20:13 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 12:25 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 14:20 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 20:23 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-06 20:26 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 14:31 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-06 20:59 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 15:56 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-06 22:03 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 17:07 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 19:20 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-07 01:24 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 19:17 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 18:42 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 17:55 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ end of life on Earth ] olcott <NoOne@NoWhere.com> - 2021-09-06 19:37 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ end of life on Earth ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 19:01 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ end of life on Earth ] olcott <NoOne@NoWhere.com> - 2021-09-06 20:08 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ end of life on Earth ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 21:23 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ end of life on Earth ] André G. Isaak <agisaak@gm.invalid> - 2021-09-06 19:33 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ end of life on Earth ] olcott <NoOne@NoWhere.com> - 2021-09-06 20:45 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ end of life on Earth ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 21:19 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 20:37 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-09-07 16:50 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-07 11:04 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-07 11:09 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] André G. Isaak <agisaak@gm.invalid> - 2021-09-07 10:41 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-07 11:59 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] André G. Isaak <agisaak@gm.invalid> - 2021-09-07 11:55 -0600
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-07 13:15 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-07 23:26 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-07 17:38 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-08 01:52 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-07 20:12 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-09-08 02:26 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-07 20:45 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 21:52 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-07 21:11 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 22:22 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 11:32 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-06 21:58 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 16:18 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-06 23:55 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 18:32 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-07 01:40 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 19:49 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-07 02:09 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 20:40 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-07 02:57 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 21:17 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 22:56 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 22:05 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 23:51 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-06 22:59 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 06:28 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-07 11:54 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-07 09:07 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-07 16:31 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 10:51 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-08 01:42 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 20:08 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 21:12 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 20:28 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 21:55 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 21:18 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 22:27 -0400
H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 21:53 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-07 21:09 -0600
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 22:18 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-08 00:14 -0600
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 09:20 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-08 08:48 -0600
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 11:26 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-08 17:49 +0100
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 14:09 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-08 21:42 +0100
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 15:49 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-08 23:11 +0100
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 17:36 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-09 01:21 +0100
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 19:41 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 21:18 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 21:21 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 23:05 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 22:09 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 23:31 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-09 02:54 +0100
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 21:07 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-09 12:02 +0100
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-09 08:59 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-09 16:32 +0100
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-09 10:46 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-09 23:29 +0100
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-09 17:50 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-09 19:23 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-10 03:19 +0100
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-09 21:36 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-10 10:37 +0100
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-10 08:43 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-10 21:42 +0100
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-10 16:30 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-10 16:10 -0600
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-10 17:38 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-10 17:07 -0600
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-10 18:20 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-10 22:09 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-10 22:03 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-10 22:00 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-09 21:26 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-09 21:23 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 20:22 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-08 11:59 -0600
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 13:12 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-08 12:58 -0600
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 14:13 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 14:33 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-08 14:02 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ] olcott <NoOne@NoWhere.com> - 2021-09-08 15:41 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ] André G. Isaak <agisaak@gm.invalid> - 2021-09-08 15:27 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ] olcott <NoOne@NoWhere.com> - 2021-09-08 17:00 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ] André G. Isaak <agisaak@gm.invalid> - 2021-09-08 16:20 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-08 17:34 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-08 19:57 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-08 19:17 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-08 21:23 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-08 21:23 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-08 23:12 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) André G. Isaak <agisaak@gm.invalid> - 2021-09-08 19:21 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-08 21:02 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-08 23:14 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-08 22:25 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-08 23:37 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-08 23:16 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-09 06:58 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-09 09:09 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-09 21:41 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-10 10:00 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-09-10 09:20 -0700
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-10 11:35 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-10 21:55 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-11 08:57 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-11 16:21 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-11 16:16 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-11 17:35 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-11 17:14 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-11 18:44 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-11 17:53 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-11 19:05 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-11 18:14 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-11 19:41 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-11 22:53 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-12 06:33 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-12 08:43 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) André G. Isaak <agisaak@gm.invalid> - 2021-09-12 09:47 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-12 12:00 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) André G. Isaak <agisaak@gm.invalid> - 2021-09-12 11:20 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-12 12:31 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) André G. Isaak <agisaak@gm.invalid> - 2021-09-12 11:51 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-12 13:00 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) André G. Isaak <agisaak@gm.invalid> - 2021-09-12 12:28 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-12 13:36 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) André G. Isaak <agisaak@gm.invalid> - 2021-09-12 12:47 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-12 13:52 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) André G. Isaak <agisaak@gm.invalid> - 2021-09-12 13:20 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-12 15:08 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-12 14:35 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( SUMMATION ) olcott <NoOne@NoWhere.com> - 2021-09-12 13:44 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( SUMMATION ) Richard Damon <Richard@Damon-Family.org> - 2021-09-12 15:14 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( SUMMATION ) André G. Isaak <agisaak@gm.invalid> - 2021-09-12 13:18 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( SUMMATION ) Richard Damon <Richard@Damon-Family.org> - 2021-09-12 15:24 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-12 13:57 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-12 13:01 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-12 14:12 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-12 13:16 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-12 14:26 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-12 13:34 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-12 15:00 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) André G. Isaak <agisaak@gm.invalid> - 2021-09-12 14:30 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) André G. Isaak <agisaak@gm.invalid> - 2021-09-12 12:37 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-12 13:51 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-12 15:17 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) André G. Isaak <agisaak@gm.invalid> - 2021-09-12 13:19 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-12 13:44 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-12 12:48 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-12 12:41 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-12 12:18 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) André G. Isaak <agisaak@gm.invalid> - 2021-09-08 23:16 -0600
Re: H1(P,P) is a halt decider ... Andy Walker <anw@cuboid.co.uk> - 2021-09-09 10:21 +0100
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-09 08:34 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) André G. Isaak <agisaak@gm.invalid> - 2021-09-09 15:08 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-09 17:15 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) André G. Isaak <agisaak@gm.invalid> - 2021-09-09 17:18 -0600
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) olcott <NoOne@NoWhere.com> - 2021-09-09 18:31 -0500
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ]( calling your bluff! ) Richard Damon <Richard@Damon-Family.org> - 2021-09-09 21:47 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 19:54 -0400
Re: H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion criteria ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 19:51 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 19:48 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 19:46 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 19:01 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 20:25 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-09-08 19:09 -0600
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 20:17 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 21:32 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 21:33 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 23:20 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 22:30 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 23:50 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 23:10 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-09 07:05 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-09 09:16 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-09 16:05 +0100
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-09 10:25 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-09 16:41 +0100
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-09 10:51 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-09 23:29 +0100
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-09 19:30 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-09 18:50 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-09 20:38 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-09 19:46 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-09 22:25 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-09 22:19 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-09 22:05 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 20:17 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 07:15 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 07:04 -0400
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 09:39 -0500
Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 20:01 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-07 22:33 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-08 03:55 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-07 22:07 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 07:09 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-08 15:58 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 14:08 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-08 21:42 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 15:53 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-08 23:52 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 18:10 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 20:11 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-09 01:21 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 19:37 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 21:30 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 21:25 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 23:25 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-09 02:54 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 21:14 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 23:29 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 22:39 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-08 23:48 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-08 23:08 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-09 07:09 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-09 09:18 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-09 20:53 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-09 12:02 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-09 08:47 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-09 16:18 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-09 10:31 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-09 23:29 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-09 21:14 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-09-09 20:29 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-09-09 21:02 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-06 20:54 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <news.x.richarddamon@xoxy.net> - 2021-09-05 12:34 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-04 22:22 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-04 16:42 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-05 00:09 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-04 23:25 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-05 06:58 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-05 17:12 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-05 11:40 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Richard Damon <Richard@Damon-Family.org> - 2021-09-05 12:51 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-05 20:38 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-02 22:49 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-02 22:35 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 21:50 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-02 23:04 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] olcott <NoOne@NoWhere.com> - 2021-09-02 22:17 -0500
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance ] Richard Damon <Richard@Damon-Family.org> - 2021-09-02 23:53 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-30 00:54 +0100
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-29 15:45 -0400
Re: That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ] Richard Damon <Richard@Damon-Family.org> - 2021-08-28 20:00 -0400
Page 34 of 37 — ← Prev page 1 … 32 33 [34] 35 36 37 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-08 23:10 -0500 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <R6udnfpE2LazFKT8nZ2dnUU7-YWdnZ2d@giganews.com> |
| In reply to | #39209 |
On 9/8/2021 10:50 PM, Richard Damon wrote:
> On 9/8/21 11:30 PM, olcott wrote:
>> On 9/8/2021 10:20 PM, Richard Damon wrote:
>>> On 9/8/21 10:33 PM, olcott wrote:
>>>> On 9/8/2021 8:32 PM, Richard Damon wrote:
>>>>> On 9/8/21 9:17 PM, olcott wrote:
>>>>>> On 9/8/2021 8:09 PM, André G. Isaak wrote:
>>>>>>> On 2021-09-08 18:01, olcott wrote:
>>>>>>>
>>>>>>>> The execution trace of the input to H1(P,P) conclusively proves that
>>>>>>>> this input definitely halts.
>>>>>>>>
>>>>>>>> The execution trace of the input to H(P,P) called from H1(P,P)
>>>>>>>> conclusively proves that this input definitely never halts.
>>>>>>>
>>>>>>> No. The execution trace shows that your halt decider decides to abort
>>>>>>> the simulation. That's completely different from showing that this
>>>>>>> input 'definitely never halts'. Your grasp of what traces show is
>>>>>>> seriously lacking.
>>>>>>>
>>>>>>> Since P(P) either halts or it doesn't, it isn't possible for both of
>>>>>>> the above deciders to be correct. So how can they both 'conclusively
>>>>>>> prove' contradictory answers?
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> Richard said that such a system would be inconsistent.
>>>>>> I agree, this is a key new insight.
>>>>>
>>>>> Right, YOUR LOGIC SYSTEM has been shown to be inconsistent, likelyy
>>>>> because you have assumes a (or many) false statements as fact.
>>>>>
>>>>>>
>>>>>> Since the execution trace of the input to H1(P,P) conclusively proves
>>>>>> that it halts and the execution trace of the input to H(P,P)
>>>>>> conclusively proves that it never halts we do have an inconsistent
>>>>>> system.
>>>>>
>>>>> Right, YOU LOGIC that says the two are correct is faulty and
>>>>> inconsistent.
>>>>>
>>>>>>
>>>>>> It is inconsistent on the basis of its input that has the pathological
>>>>>> self-reference(Olcott 2004) error, which is detected by this code:
>>>>>>
>>>>>
>>>>> Nope.
>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>>>>>> OutputString("Pathological self-reference error!");
>>>>>> }
>>>>>>
>>>>>> Thus refuting Rice's theorem and the halting theorem. We accept the
>>>>>> H1(P,P) halt status as correct because P does not refer to H1.
>>>>>>
>>>>>
>>>>> Nope, FAIL.
>>>>>
>>>>
>>>> You never try to show how I am wrong you merely assert that you believe
>>>> that I am wrong. If you cannot show my mistake that is for one of two
>>>> reasons:
>>>
>>> The criteria that you are claiming to decide on is Syntactic, not
>>> Symantec, and thus not under the domain of Rice's theorem.
>>>
>>
>> Ah great now that you committed to a position I can say that you are
>> wrong. An undecidability decider decides a semantic property.
>>
>>>>
>>>> (1) I made no mistake
>>>> (2) You don't understand these things very well
>>>
>>> You don't understand what you claim to be disproving.
>>>
>>>>
>>>> That the system derives an inconsistent result and each result is
>>>> confirmed to be correct means bad input.
>>>
>>> If a system is inconsistent, it isn't the 'inputs' that are bad (as in
>>> the inputs to the machines). The LOGIC SYSTEM is bad, and that shows
>>> that the 'axioms' used to build it (your 'truisms') are flawed.
>>>
>>
>> Since we can verify by the execution trace that H1(P,P)==1 is correct
>> and H(P,P)==0 is correct it is not the logical system.
>>
>> "This sentence is not true" has the same error and it is not the fault
>> of the logic system.
>
> So you thing that it is possible for the statement "H^(<H^>) is a
> Halting Computation" can both be True and False?
>
> The fact that you claim the execution traces prove it, just shows that
> the inconsitency runs deep in the system, and isn't just a small error
> at the end.
>
> Basically you are admitting that your system if fatally flawed, only you
> are smart enough to see it.
>
It is definitely an inconsistency, yet not because the system is
inconsistent.
int main()
{
if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
OutputString("Pathological self-reference error!");
}
The above decidability decider correctly rejects the input
>>
>>> You don't even seem to know the basics of Logic systems.
>>>
>>>>
>>>> The only reason why people "believe" that the system is wrong is that
>>>> they very diligently make sure to not pay attention.
>>>
>>>
>>>>
>>>> The input to H cannot possibly ever halt unless H aborts its simulation
>>>> of this input. This is an easily verified fact that everyone
>>>> (a) Dishonestly ignores
>>>> (b) Dishonestly rejects
>>>> (c) Intentionally fails to comprehend
>>>>
>>>
>>> But you just keep using the WRONG definition of Halting.
>>>
>>> The fact that H^ does Halt, for what ever reason, means it is a Halting
>>> Computation.
>>>
>>> Remember, to even talk abort any machine H^, you FIRST had to fix your
>>> definition of H, as it is based on it. Every time you mention changing
>>> H, everything you though you proved about H^ needs to be thrown out
>>> until you go back to that original H.
>>>
>>> THAT is part of the flaw of your logic, you mix different H^s and use
>>> them with the wrong Hs.
>>>
>>
>>
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-09 07:05 -0400 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <2Ul_I.27180$gc3.22668@fx12.iad> |
| In reply to | #39211 |
On 9/9/21 12:10 AM, olcott wrote:
> On 9/8/2021 10:50 PM, Richard Damon wrote:
>> On 9/8/21 11:30 PM, olcott wrote:
>>> On 9/8/2021 10:20 PM, Richard Damon wrote:
>>>> On 9/8/21 10:33 PM, olcott wrote:
>>>>> On 9/8/2021 8:32 PM, Richard Damon wrote:
>>>>>> On 9/8/21 9:17 PM, olcott wrote:
>>>>>>> On 9/8/2021 8:09 PM, André G. Isaak wrote:
>>>>>>>> On 2021-09-08 18:01, olcott wrote:
>>>>>>>>
>>>>>>>>> The execution trace of the input to H1(P,P) conclusively proves
>>>>>>>>> that
>>>>>>>>> this input definitely halts.
>>>>>>>>>
>>>>>>>>> The execution trace of the input to H(P,P) called from H1(P,P)
>>>>>>>>> conclusively proves that this input definitely never halts.
>>>>>>>>
>>>>>>>> No. The execution trace shows that your halt decider decides to
>>>>>>>> abort
>>>>>>>> the simulation. That's completely different from showing that this
>>>>>>>> input 'definitely never halts'. Your grasp of what traces show is
>>>>>>>> seriously lacking.
>>>>>>>>
>>>>>>>> Since P(P) either halts or it doesn't, it isn't possible for
>>>>>>>> both of
>>>>>>>> the above deciders to be correct. So how can they both
>>>>>>>> 'conclusively
>>>>>>>> prove' contradictory answers?
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> Richard said that such a system would be inconsistent.
>>>>>>> I agree, this is a key new insight.
>>>>>>
>>>>>> Right, YOUR LOGIC SYSTEM has been shown to be inconsistent, likelyy
>>>>>> because you have assumes a (or many) false statements as fact.
>>>>>>
>>>>>>>
>>>>>>> Since the execution trace of the input to H1(P,P) conclusively
>>>>>>> proves
>>>>>>> that it halts and the execution trace of the input to H(P,P)
>>>>>>> conclusively proves that it never halts we do have an inconsistent
>>>>>>> system.
>>>>>>
>>>>>> Right, YOU LOGIC that says the two are correct is faulty and
>>>>>> inconsistent.
>>>>>>
>>>>>>>
>>>>>>> It is inconsistent on the basis of its input that has the
>>>>>>> pathological
>>>>>>> self-reference(Olcott 2004) error, which is detected by this code:
>>>>>>>
>>>>>>
>>>>>> Nope.
>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>>>>>>> OutputString("Pathological self-reference error!");
>>>>>>> }
>>>>>>>
>>>>>>> Thus refuting Rice's theorem and the halting theorem. We accept the
>>>>>>> H1(P,P) halt status as correct because P does not refer to H1.
>>>>>>>
>>>>>>
>>>>>> Nope, FAIL.
>>>>>>
>>>>>
>>>>> You never try to show how I am wrong you merely assert that you
>>>>> believe
>>>>> that I am wrong. If you cannot show my mistake that is for one of two
>>>>> reasons:
>>>>
>>>> The criteria that you are claiming to decide on is Syntactic, not
>>>> Symantec, and thus not under the domain of Rice's theorem.
>>>>
>>>
>>> Ah great now that you committed to a position I can say that you are
>>> wrong. An undecidability decider decides a semantic property.
>>>
>>>>>
>>>>> (1) I made no mistake
>>>>> (2) You don't understand these things very well
>>>>
>>>> You don't understand what you claim to be disproving.
>>>>
>>>>>
>>>>> That the system derives an inconsistent result and each result is
>>>>> confirmed to be correct means bad input.
>>>>
>>>> If a system is inconsistent, it isn't the 'inputs' that are bad (as in
>>>> the inputs to the machines). The LOGIC SYSTEM is bad, and that shows
>>>> that the 'axioms' used to build it (your 'truisms') are flawed.
>>>>
>>>
>>> Since we can verify by the execution trace that H1(P,P)==1 is correct
>>> and H(P,P)==0 is correct it is not the logical system.
>>>
>>> "This sentence is not true" has the same error and it is not the fault
>>> of the logic system.
>>
>> So you thing that it is possible for the statement "H^(<H^>) is a
>> Halting Computation" can both be True and False?
>>
>> The fact that you claim the execution traces prove it, just shows that
>> the inconsitency runs deep in the system, and isn't just a small error
>> at the end.
>>
>> Basically you are admitting that your system if fatally flawed, only you
>> are smart enough to see it.
>>
>
>
> It is definitely an inconsistency, yet not because the system is
> inconsistent.
Your choices are either your logic system is inconsistent, or H is
inconsistent in the value it produces, and thus you have LIED in calling
it a Computation.
That is your choices.
>
> int main()
> {
> if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
> OutputString("Pathological self-reference error!");
> }
>
> The above decidability decider correctly rejects the input
So? You have just created some criteria that you can show one example
that it decides correctly. Doesn't mean that you actually shown anything.
Can you describe in WORDS that don't refer to the program what the
condition you are deciding on actually is? Something that is Semantic in
definition. Then we can see if your 'Universal Decidability Decider'
actually works.
SO far, it just sounds like you have defined this decider to decide what
its output will be.
>
>
>>>
>>>> You don't even seem to know the basics of Logic systems.
>>>>
>>>>>
>>>>> The only reason why people "believe" that the system is wrong is that
>>>>> they very diligently make sure to not pay attention.
>>>>
>>>>
>>>>>
>>>>> The input to H cannot possibly ever halt unless H aborts its
>>>>> simulation
>>>>> of this input. This is an easily verified fact that everyone
>>>>> (a) Dishonestly ignores
>>>>> (b) Dishonestly rejects
>>>>> (c) Intentionally fails to comprehend
>>>>>
>>>>
>>>> But you just keep using the WRONG definition of Halting.
>>>>
>>>> The fact that H^ does Halt, for what ever reason, means it is a Halting
>>>> Computation.
>>>>
>>>> Remember, to even talk abort any machine H^, you FIRST had to fix your
>>>> definition of H, as it is based on it. Every time you mention changing
>>>> H, everything you though you proved about H^ needs to be thrown out
>>>> until you go back to that original H.
>>>>
>>>> THAT is part of the flaw of your logic, you mix different H^s and use
>>>> them with the wrong Hs.
>>>>
>>>
>>>
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-09 09:16 -0500 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <jvqdnYYcS8nbiqf8nZ2dnUU7-Y_NnZ2d@giganews.com> |
| In reply to | #39219 |
On 9/9/2021 6:05 AM, Richard Damon wrote:
> On 9/9/21 12:10 AM, olcott wrote:
>> On 9/8/2021 10:50 PM, Richard Damon wrote:
>>> On 9/8/21 11:30 PM, olcott wrote:
>>>> On 9/8/2021 10:20 PM, Richard Damon wrote:
>>>>> On 9/8/21 10:33 PM, olcott wrote:
>>>>>> On 9/8/2021 8:32 PM, Richard Damon wrote:
>>>>>>> On 9/8/21 9:17 PM, olcott wrote:
>>>>>>>> On 9/8/2021 8:09 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-09-08 18:01, olcott wrote:
>>>>>>>>>
>>>>>>>>>> The execution trace of the input to H1(P,P) conclusively proves
>>>>>>>>>> that
>>>>>>>>>> this input definitely halts.
>>>>>>>>>>
>>>>>>>>>> The execution trace of the input to H(P,P) called from H1(P,P)
>>>>>>>>>> conclusively proves that this input definitely never halts.
>>>>>>>>>
>>>>>>>>> No. The execution trace shows that your halt decider decides to
>>>>>>>>> abort
>>>>>>>>> the simulation. That's completely different from showing that this
>>>>>>>>> input 'definitely never halts'. Your grasp of what traces show is
>>>>>>>>> seriously lacking.
>>>>>>>>>
>>>>>>>>> Since P(P) either halts or it doesn't, it isn't possible for
>>>>>>>>> both of
>>>>>>>>> the above deciders to be correct. So how can they both
>>>>>>>>> 'conclusively
>>>>>>>>> prove' contradictory answers?
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> Richard said that such a system would be inconsistent.
>>>>>>>> I agree, this is a key new insight.
>>>>>>>
>>>>>>> Right, YOUR LOGIC SYSTEM has been shown to be inconsistent, likelyy
>>>>>>> because you have assumes a (or many) false statements as fact.
>>>>>>>
>>>>>>>>
>>>>>>>> Since the execution trace of the input to H1(P,P) conclusively
>>>>>>>> proves
>>>>>>>> that it halts and the execution trace of the input to H(P,P)
>>>>>>>> conclusively proves that it never halts we do have an inconsistent
>>>>>>>> system.
>>>>>>>
>>>>>>> Right, YOU LOGIC that says the two are correct is faulty and
>>>>>>> inconsistent.
>>>>>>>
>>>>>>>>
>>>>>>>> It is inconsistent on the basis of its input that has the
>>>>>>>> pathological
>>>>>>>> self-reference(Olcott 2004) error, which is detected by this code:
>>>>>>>>
>>>>>>>
>>>>>>> Nope.
>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>>>>>>>> OutputString("Pathological self-reference error!");
>>>>>>>> }
>>>>>>>>
>>>>>>>> Thus refuting Rice's theorem and the halting theorem. We accept the
>>>>>>>> H1(P,P) halt status as correct because P does not refer to H1.
>>>>>>>>
>>>>>>>
>>>>>>> Nope, FAIL.
>>>>>>>
>>>>>>
>>>>>> You never try to show how I am wrong you merely assert that you
>>>>>> believe
>>>>>> that I am wrong. If you cannot show my mistake that is for one of two
>>>>>> reasons:
>>>>>
>>>>> The criteria that you are claiming to decide on is Syntactic, not
>>>>> Symantec, and thus not under the domain of Rice's theorem.
>>>>>
>>>>
>>>> Ah great now that you committed to a position I can say that you are
>>>> wrong. An undecidability decider decides a semantic property.
>>>>
>>>>>>
>>>>>> (1) I made no mistake
>>>>>> (2) You don't understand these things very well
>>>>>
>>>>> You don't understand what you claim to be disproving.
>>>>>
>>>>>>
>>>>>> That the system derives an inconsistent result and each result is
>>>>>> confirmed to be correct means bad input.
>>>>>
>>>>> If a system is inconsistent, it isn't the 'inputs' that are bad (as in
>>>>> the inputs to the machines). The LOGIC SYSTEM is bad, and that shows
>>>>> that the 'axioms' used to build it (your 'truisms') are flawed.
>>>>>
>>>>
>>>> Since we can verify by the execution trace that H1(P,P)==1 is correct
>>>> and H(P,P)==0 is correct it is not the logical system.
>>>>
>>>> "This sentence is not true" has the same error and it is not the fault
>>>> of the logic system.
>>>
>>> So you thing that it is possible for the statement "H^(<H^>) is a
>>> Halting Computation" can both be True and False?
>>>
>>> The fact that you claim the execution traces prove it, just shows that
>>> the inconsitency runs deep in the system, and isn't just a small error
>>> at the end.
>>>
>>> Basically you are admitting that your system if fatally flawed, only you
>>> are smart enough to see it.
>>>
>>
>>
>> It is definitely an inconsistency, yet not because the system is
>> inconsistent.
>
> Your choices are either your logic system is inconsistent, or H is
> inconsistent in the value it produces, and thus you have LIED in calling
> it a Computation.
>
> That is your choices.
>
>>
>> int main()
>> {
>> if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>> OutputString("Pathological self-reference error!");
>> }
>>
>> The above decidability decider correctly rejects the input
>
> So? You have just created some criteria that you can show one example
> that it decides correctly. Doesn't mean that you actually shown anything.
>
The decidability decider proves that the input is bad because is has the
pathological self-reference(Olcott 2004) error.
The source of the inconsistency is bad data not incorrect formal system.
"This sentence is not true" is another example of this same bad data.
> Can you describe in WORDS that don't refer to the program what the
> condition you are deciding on actually is? Something that is Semantic in
> definition. Then we can see if your 'Universal Decidability Decider'
> actually works.
>
It is the pathological self-reference error:
(a) "This sentence is not true"
(b) "This sentence is unprovable"
(c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
> SO far, it just sounds like you have defined this decider to decide what
> its output will be.
>
>>
>>
>>>>
>>>>> You don't even seem to know the basics of Logic systems.
>>>>>
>>>>>>
>>>>>> The only reason why people "believe" that the system is wrong is that
>>>>>> they very diligently make sure to not pay attention.
>>>>>
>>>>>
>>>>>>
>>>>>> The input to H cannot possibly ever halt unless H aborts its
>>>>>> simulation
>>>>>> of this input. This is an easily verified fact that everyone
>>>>>> (a) Dishonestly ignores
>>>>>> (b) Dishonestly rejects
>>>>>> (c) Intentionally fails to comprehend
>>>>>>
>>>>>
>>>>> But you just keep using the WRONG definition of Halting.
>>>>>
>>>>> The fact that H^ does Halt, for what ever reason, means it is a Halting
>>>>> Computation.
>>>>>
>>>>> Remember, to even talk abort any machine H^, you FIRST had to fix your
>>>>> definition of H, as it is based on it. Every time you mention changing
>>>>> H, everything you though you proved about H^ needs to be thrown out
>>>>> until you go back to that original H.
>>>>>
>>>>> THAT is part of the flaw of your logic, you mix different H^s and use
>>>>> them with the wrong Hs.
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-09-09 16:05 +0100 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <87sfydaixa.fsf@bsb.me.uk> |
| In reply to | #39225 |
olcott <NoOne@NoWhere.com> writes: > It is the pathological self-reference error: ... > (c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn > Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts (1) What is "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and (2) what does it mean to say that an input (presumably a string) does or does not halt? The only reasonable answers show that you are wrong. (1) "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" is, presumably, ⟨Ĥ⟩ ⟨Ĥ⟩. (2) The only reasonable meaning for whether a string halts or not would be what happens if it were passed to a UTM, but UTM ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting computation (because Ĥ(⟨Ĥ⟩) is a halting computation). Your sentence actually has poor choices of words because, in addition to (1) and (2), "Ĥ halts" is also meaningless. Computations halt (or don't) not Turing machines. A note to other readers: the poor use of words is deliberate. 90% of PO's posting use vague undefined notions because saying things clearly just makes the mistakes too obvious. "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts" is a magic incantation, often repeated, that is never explained. When pushed, the answer is typically some crank non-explanation: "so you don't know what an input is?". -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-09 10:25 -0500 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <UMidnXAukKkeuqf8nZ2dnUU7-aXNnZ2d@giganews.com> |
| In reply to | #39227 |
On 9/9/2021 10:05 AM, Ben Bacarisse wrote: > olcott <NoOne@NoWhere.com> writes: > >> It is the pathological self-reference error: > ... >> (c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >> Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts > > (1) What is "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and (2) what does it mean to say > that an input (presumably a string) does or does not halt? The only > reasonable answers show that you are wrong. > Since it is well established and repeated 12 times a day every day for six months that H and Ĥ.qx are simulating halt deciders it is 100% perfectly clear exactly what the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ does not halts means. You are being a total jackass when you pretend to forget that after you have been told 10,000 times. > (1) "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" is, presumably, ⟨Ĥ⟩ ⟨Ĥ⟩. > > (2) The only reasonable meaning for whether a string halts or not would > be what happens if it were passed to a UTM, but UTM ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting > computation (because Ĥ(⟨Ĥ⟩) is a halting computation). > It would seem that way only if you very diligently make sure to not pay attention to the execution trace of the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩, which can only be 100% fully elaborated by its proxy computation H(P,P). Perhaps your lack of understanding of the C/x86 H(P,P) computation proves that our dialogue can never be fruitful thus no sense in continuing. It is the case that H(P,P)==0 is correct It is the case that H1((P,P)==1 is correct It is the case the this is inconsistent. It is the case that this inconsistency defines a decidability decider that correctly rejects P on the basis that P has the pathological self-reference(Olcott 2004) error. > Your sentence actually has poor choices of words because, in addition to > (1) and (2), "Ĥ halts" is also meaningless. Computations halt (or > don't) not Turing machines. > > A note to other readers: the poor use of words is deliberate. 90% of > PO's posting use vague undefined notions because saying things clearly > just makes the mistakes too obvious. "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never > halts" is a magic incantation, often repeated, that is never explained. > When pushed, the answer is typically some crank non-explanation: "so you > don't know what an input is?". > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-09-09 16:41 +0100 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <87bl51ah8o.fsf@bsb.me.uk> |
| In reply to | #39229 |
olcott <NoOne@NoWhere.com> writes: > On 9/9/2021 10:05 AM, Ben Bacarisse wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> It is the pathological self-reference error: >> ... >>> (c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>> Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts >> (1) What is "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and (2) what does it mean to say >> that an input (presumably a string) does or does not halt? The only >> reasonable answers show that you are wrong. > > Since it is well established and repeated 12 times a day every day for > six months that H and Ĥ.qx are simulating halt deciders it is 100% > perfectly clear exactly what the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ does not halts > means. > > You are being a total jackass when you pretend to forget that > after you have been told 10,000 times. You have never answered both (1) and (2). But the crank response is always to say "I've told you 1000 times" rather than simply saying what the input is: hic Rhodus, hic salta. >> (1) "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" is, presumably, ⟨Ĥ⟩ ⟨Ĥ⟩. >> (2) The only reasonable meaning for whether a string halts or not would >> be what happens if it were passed to a UTM, but UTM ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting >> computation (because Ĥ(⟨Ĥ⟩) is a halting computation). > > It would seem that way only if you very diligently make sure to not > pay attention to the execution trace of the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩, > which can only be 100% fully elaborated by its proxy computation > H(P,P). Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting computation. That can't explain your magic phrase. What is the "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and what does it mean for an input to "never halt"? My other guess is that even /you/ know what you mean by it. Clarity is your enemy right now. Magic phrases are your friends. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-09 10:51 -0500 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <d8adnZrzRtX4sKf8nZ2dnUU7-bnNnZ2d@giganews.com> |
| In reply to | #39232 |
On 9/9/2021 10:41 AM, Ben Bacarisse wrote: > olcott <NoOne@NoWhere.com> writes: > >> On 9/9/2021 10:05 AM, Ben Bacarisse wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> It is the pathological self-reference error: >>> ... >>>> (c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>> Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts >>> (1) What is "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and (2) what does it mean to say >>> that an input (presumably a string) does or does not halt? The only >>> reasonable answers show that you are wrong. >> >> Since it is well established and repeated 12 times a day every day for >> six months that H and Ĥ.qx are simulating halt deciders it is 100% >> perfectly clear exactly what the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ does not halts >> means. >> >> You are being a total jackass when you pretend to forget that >> after you have been told 10,000 times. > > You have never answered both (1) and (2). But the crank response is > always to say "I've told you 1000 times" rather than simply saying what > the input is: hic Rhodus, hic salta. > >>> (1) "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" is, presumably, ⟨Ĥ⟩ ⟨Ĥ⟩. >>> (2) The only reasonable meaning for whether a string halts or not would >>> be what happens if it were passed to a UTM, but UTM ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting >>> computation (because Ĥ(⟨Ĥ⟩) is a halting computation). >> >> It would seem that way only if you very diligently make sure to not >> pay attention to the execution trace of the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩, >> which can only be 100% fully elaborated by its proxy computation >> H(P,P). > > Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting computation. That can't explain your magic > phrase. What is the "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and what does it mean > for an input to "never halt"? > Perhaps your lack of understanding of the C/x86 H(P,P) computation proves that our dialogue can never be fruitful thus no sense in continuing. This lack of technical competence would also prevent you from accurately assessing that H(P,P) is a valid proxy computation for Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩. (a) It is the case that H(P,P)==0 is correct Not having any understanding of the x86 language makes it impossible to understand that the simulation of the input to H(P,P) cannot possibly ever halt unless H aborts this simulation. Begin Local Halt Decider Simulation at Machine Address:c36 [00000c36][002117ca][002117ce] 55 push ebp [00000c37][002117ca][002117ce] 8bec mov ebp,esp [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08] [00000c3c][002117c6][00000c36] 50 push eax // push P [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08] [00000c40][002117c2][00000c36] 51 push ecx // push P [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P) [00000c36][0025c1f2][0025c1f6] 55 push ebp [00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp [00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08] [00000c3c][0025c1ee][00000c36] 50 push eax // push P [00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08] [00000c40][0025c1ea][00000c36] 51 push ecx // push P [00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P) Local Halt Decider: Infinite Recursion Detected Simulation Stopped (b) It is the case that H1((P,P)==1 is correct (c) It is the case the this is inconsistent. (d) It is the case that this inconsistency defines a decidability decider that correctly rejects P on the basis that P has the pathological self-reference(Olcott 2004) error. > My other guess is that even /you/ know what you mean by it. Clarity is > your enemy right now. Magic phrases are your friends. > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-09-09 23:29 +0100 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <87zgsl8jsk.fsf@bsb.me.uk> |
| In reply to | #39234 |
olcott <NoOne@NoWhere.com> writes: > On 9/9/2021 10:41 AM, Ben Bacarisse wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> On 9/9/2021 10:05 AM, Ben Bacarisse wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> It is the pathological self-reference error: >>>> ... >>>>> (c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>> Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts >>>> (1) What is "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and (2) what does it mean to say >>>> that an input (presumably a string) does or does not halt? The only >>>> reasonable answers show that you are wrong. >>> >>> Since it is well established and repeated 12 times a day every day for >>> six months that H and Ĥ.qx are simulating halt deciders it is 100% >>> perfectly clear exactly what the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ does not halts >>> means. >>> >>> You are being a total jackass when you pretend to forget that >>> after you have been told 10,000 times. >> You have never answered both (1) and (2). But the crank response is >> always to say "I've told you 1000 times" rather than simply saying what >> the input is: hic Rhodus, hic salta. >> >>>> (1) "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" is, presumably, ⟨Ĥ⟩ ⟨Ĥ⟩. >>>> (2) The only reasonable meaning for whether a string halts or not would >>>> be what happens if it were passed to a UTM, but UTM ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting >>>> computation (because Ĥ(⟨Ĥ⟩) is a halting computation). >>> >>> It would seem that way only if you very diligently make sure to not >>> pay attention to the execution trace of the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩, >>> which can only be 100% fully elaborated by its proxy computation >>> H(P,P). >> >> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting computation. That can't explain your magic >> phrase. What is the "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and what does it mean >> for an input to "never halt"? > > Perhaps your lack of understanding of the C/x86 H(P,P) computation > proves that our dialogue can never be fruitful thus no sense in > continuing. Another copy-and-paste answer that does not address any of the points put to you. You have nothing to say except to try to draw fire away from these difficult truths. All the posts remain available to you should you ever decide you'd like to answer the points put to you. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-09 19:30 -0400 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <%Nw_I.78059$Kv2.51869@fx47.iad> |
| In reply to | #39234 |
On 9/9/21 11:51 AM, olcott wrote: > On 9/9/2021 10:41 AM, Ben Bacarisse wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> On 9/9/2021 10:05 AM, Ben Bacarisse wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> It is the pathological self-reference error: >>>> ... >>>>> (c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>> Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts >>>> (1) What is "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and (2) what does it mean to >>>> say >>>> that an input (presumably a string) does or does not halt? The only >>>> reasonable answers show that you are wrong. >>> >>> Since it is well established and repeated 12 times a day every day for >>> six months that H and Ĥ.qx are simulating halt deciders it is 100% >>> perfectly clear exactly what the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ does not halts >>> means. >>> >>> You are being a total jackass when you pretend to forget that >>> after you have been told 10,000 times. >> >> You have never answered both (1) and (2). But the crank response is >> always to say "I've told you 1000 times" rather than simply saying what >> the input is: hic Rhodus, hic salta. >> >>>> (1) "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" is, presumably, ⟨Ĥ⟩ ⟨Ĥ⟩. >>>> (2) The only reasonable meaning for whether a string halts or not would >>>> be what happens if it were passed to a UTM, but UTM ⟨Ĥ⟩ ⟨Ĥ⟩ is a >>>> halting >>>> computation (because Ĥ(⟨Ĥ⟩) is a halting computation). >>> >>> It would seem that way only if you very diligently make sure to not >>> pay attention to the execution trace of the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩, >>> which can only be 100% fully elaborated by its proxy computation >>> H(P,P). >> >> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting computation. That can't explain your magic >> phrase. What is the "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and what does it mean >> for an input to "never halt"? >> > > Perhaps your lack of understanding of the C/x86 H(P,P) computation > proves that our dialogue can never be fruitful thus no sense in continuing. > > This lack of technical competence would also prevent you from accurately > assessing that H(P,P) is a valid proxy computation for Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩. > > (a) It is the case that H(P,P)==0 is correct > > Not having any understanding of the x86 language makes it impossible to > understand that the simulation of the input to H(P,P) cannot possibly > ever halt unless H aborts this simulation. > And I have NEVER seen a proper x86 processor that when execting a Call 0966 ends up at C36. Fail > Begin Local Halt Decider Simulation at Machine Address:c36 > [00000c36][002117ca][002117ce] 55 push ebp > [00000c37][002117ca][002117ce] 8bec mov ebp,esp > [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08] > [00000c3c][002117c6][00000c36] 50 push eax // push P > [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08] > [00000c40][002117c2][00000c36] 51 push ecx // push P > [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P) > > [00000c36][0025c1f2][0025c1f6] 55 push ebp > [00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp > [00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08] > [00000c3c][0025c1ee][00000c36] 50 push eax // push P > [00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08] > [00000c40][0025c1ea][00000c36] 51 push ecx // push P > [00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P) > Local Halt Decider: Infinite Recursion Detected Simulation Stopped > > (b) It is the case that H1((P,P)==1 is correct > (c) It is the case the this is inconsistent. > (d) It is the case that this inconsistency defines a decidability > decider that correctly rejects P on the basis that P has the > pathological self-reference(Olcott 2004) error. > > > >> My other guess is that even /you/ know what you mean by it. Clarity is >> your enemy right now. Magic phrases are your friends. >> > >
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-09 18:50 -0500 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <TI6dnaETsuEoAKf8nZ2dnUU7-IOdnZ2d@giganews.com> |
| In reply to | #39243 |
On 9/9/2021 6:30 PM, Richard Damon wrote: > On 9/9/21 11:51 AM, olcott wrote: >> On 9/9/2021 10:41 AM, Ben Bacarisse wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> On 9/9/2021 10:05 AM, Ben Bacarisse wrote: >>>>> olcott <NoOne@NoWhere.com> writes: >>>>> >>>>>> It is the pathological self-reference error: >>>>> ... >>>>>> (c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>> Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts >>>>> (1) What is "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and (2) what does it mean to >>>>> say >>>>> that an input (presumably a string) does or does not halt? The only >>>>> reasonable answers show that you are wrong. >>>> >>>> Since it is well established and repeated 12 times a day every day for >>>> six months that H and Ĥ.qx are simulating halt deciders it is 100% >>>> perfectly clear exactly what the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ does not halts >>>> means. >>>> >>>> You are being a total jackass when you pretend to forget that >>>> after you have been told 10,000 times. >>> >>> You have never answered both (1) and (2). But the crank response is >>> always to say "I've told you 1000 times" rather than simply saying what >>> the input is: hic Rhodus, hic salta. >>> >>>>> (1) "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" is, presumably, ⟨Ĥ⟩ ⟨Ĥ⟩. >>>>> (2) The only reasonable meaning for whether a string halts or not would >>>>> be what happens if it were passed to a UTM, but UTM ⟨Ĥ⟩ ⟨Ĥ⟩ is a >>>>> halting >>>>> computation (because Ĥ(⟨Ĥ⟩) is a halting computation). >>>> >>>> It would seem that way only if you very diligently make sure to not >>>> pay attention to the execution trace of the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩, >>>> which can only be 100% fully elaborated by its proxy computation >>>> H(P,P). >>> >>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting computation. That can't explain your magic >>> phrase. What is the "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and what does it mean >>> for an input to "never halt"? >>> >> >> Perhaps your lack of understanding of the C/x86 H(P,P) computation >> proves that our dialogue can never be fruitful thus no sense in continuing. >> >> This lack of technical competence would also prevent you from accurately >> assessing that H(P,P) is a valid proxy computation for Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩. >> >> (a) It is the case that H(P,P)==0 is correct >> >> Not having any understanding of the x86 language makes it impossible to >> understand that the simulation of the input to H(P,P) cannot possibly >> ever halt unless H aborts this simulation. >> > > And I have NEVER seen a proper x86 processor that when execting a > Call 0966 ends up at C36. > I have explained this to you at least 50 times you are a Jackass. > Fail > >> Begin Local Halt Decider Simulation at Machine Address:c36 >> [00000c36][002117ca][002117ce] 55 push ebp >> [00000c37][002117ca][002117ce] 8bec mov ebp,esp >> [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08] >> [00000c3c][002117c6][00000c36] 50 push eax // push P >> [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08] >> [00000c40][002117c2][00000c36] 51 push ecx // push P >> [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P) >> >> [00000c36][0025c1f2][0025c1f6] 55 push ebp >> [00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp >> [00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08] >> [00000c3c][0025c1ee][00000c36] 50 push eax // push P >> [00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08] >> [00000c40][0025c1ea][00000c36] 51 push ecx // push P >> [00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P) >> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >> >> (b) It is the case that H1((P,P)==1 is correct >> (c) It is the case the this is inconsistent. >> (d) It is the case that this inconsistency defines a decidability >> decider that correctly rejects P on the basis that P has the >> pathological self-reference(Olcott 2004) error. >> >> >> >>> My other guess is that even /you/ know what you mean by it. Clarity is >>> your enemy right now. Magic phrases are your friends. >>> >> >> > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-09 20:38 -0400 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <oOx_I.24954$nR3.16331@fx38.iad> |
| In reply to | #39245 |
On 9/9/21 7:50 PM, olcott wrote: > On 9/9/2021 6:30 PM, Richard Damon wrote: >> On 9/9/21 11:51 AM, olcott wrote: >>> On 9/9/2021 10:41 AM, Ben Bacarisse wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> On 9/9/2021 10:05 AM, Ben Bacarisse wrote: >>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>> >>>>>>> It is the pathological self-reference error: >>>>>> ... >>>>>>> (c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>> Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts >>>>>> (1) What is "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and (2) what does it mean to >>>>>> say >>>>>> that an input (presumably a string) does or does not halt? The only >>>>>> reasonable answers show that you are wrong. >>>>> >>>>> Since it is well established and repeated 12 times a day every day for >>>>> six months that H and Ĥ.qx are simulating halt deciders it is 100% >>>>> perfectly clear exactly what the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ does not halts >>>>> means. >>>>> >>>>> You are being a total jackass when you pretend to forget that >>>>> after you have been told 10,000 times. >>>> >>>> You have never answered both (1) and (2). But the crank response is >>>> always to say "I've told you 1000 times" rather than simply saying what >>>> the input is: hic Rhodus, hic salta. >>>> >>>>>> (1) "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" is, presumably, ⟨Ĥ⟩ ⟨Ĥ⟩. >>>>>> (2) The only reasonable meaning for whether a string halts or not >>>>>> would >>>>>> be what happens if it were passed to a UTM, but UTM ⟨Ĥ⟩ ⟨Ĥ⟩ is a >>>>>> halting >>>>>> computation (because Ĥ(⟨Ĥ⟩) is a halting computation). >>>>> >>>>> It would seem that way only if you very diligently make sure to not >>>>> pay attention to the execution trace of the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩, >>>>> which can only be 100% fully elaborated by its proxy computation >>>>> H(P,P). >>>> >>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting computation. That can't explain your magic >>>> phrase. What is the "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and what does it mean >>>> for an input to "never halt"? >>>> >>> >>> Perhaps your lack of understanding of the C/x86 H(P,P) computation >>> proves that our dialogue can never be fruitful thus no sense in >>> continuing. >>> >>> This lack of technical competence would also prevent you from accurately >>> assessing that H(P,P) is a valid proxy computation for Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩. >>> >>> (a) It is the case that H(P,P)==0 is correct >>> >>> Not having any understanding of the x86 language makes it impossible to >>> understand that the simulation of the input to H(P,P) cannot possibly >>> ever halt unless H aborts this simulation. >>> >> >> And I have NEVER seen a proper x86 processor that when execting a >> Call 0966 ends up at C36. >> > > I have explained this to you at least 50 times you are a Jackass. > And your explaination is still wrong. Since H WILL affect the code that is calling it, ignoring that is just going to give you the wrong answer. PERIOD. Now, If you want to write an ACTUAL proof, you know, something that quotes ACTUAL accepted truths and combines then with accepted logical principles, to try to prove your statement, go ahead. The fact that it seems obvious top you by the meaning of the words, when you have already shown that you don't actually know the meaning of the words is not a proof. You get the wrong answer by the definition, putting up a lot of smoke doesn't make it right. Your Decider is BROKEN because your simulator gives the WRONG trace. PERIOD. >> Fail >> >>> Begin Local Halt Decider Simulation at Machine Address:c36 >>> [00000c36][002117ca][002117ce] 55 push ebp >>> [00000c37][002117ca][002117ce] 8bec mov ebp,esp >>> [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08] >>> [00000c3c][002117c6][00000c36] 50 push eax // push P >>> [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08] >>> [00000c40][002117c2][00000c36] 51 push ecx // push P >>> [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P) >>> >>> [00000c36][0025c1f2][0025c1f6] 55 push ebp >>> [00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp >>> [00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08] >>> [00000c3c][0025c1ee][00000c36] 50 push eax // push P >>> [00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08] >>> [00000c40][0025c1ea][00000c36] 51 push ecx // push P >>> [00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P) >>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>> >>> (b) It is the case that H1((P,P)==1 is correct >>> (c) It is the case the this is inconsistent. >>> (d) It is the case that this inconsistency defines a decidability >>> decider that correctly rejects P on the basis that P has the >>> pathological self-reference(Olcott 2004) error. >>> >>> >>> >>>> My other guess is that even /you/ know what you mean by it. Clarity is >>>> your enemy right now. Magic phrases are your friends. >>>> >>> >>> >> > >
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-09 19:46 -0500 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <PtSdnXnxyLlWN6f8nZ2dnUU78IvNnZ2d@giganews.com> |
| In reply to | #39246 |
On 9/9/2021 7:38 PM, Richard Damon wrote:
> On 9/9/21 7:50 PM, olcott wrote:
>> On 9/9/2021 6:30 PM, Richard Damon wrote:
>>> On 9/9/21 11:51 AM, olcott wrote:
>>>> On 9/9/2021 10:41 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 9/9/2021 10:05 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> It is the pathological self-reference error:
>>>>>>> ...
>>>>>>>> (c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>> Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
>>>>>>> (1) What is "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and (2) what does it mean to
>>>>>>> say
>>>>>>> that an input (presumably a string) does or does not halt? The only
>>>>>>> reasonable answers show that you are wrong.
>>>>>>
>>>>>> Since it is well established and repeated 12 times a day every day for
>>>>>> six months that H and Ĥ.qx are simulating halt deciders it is 100%
>>>>>> perfectly clear exactly what the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ does not halts
>>>>>> means.
>>>>>>
>>>>>> You are being a total jackass when you pretend to forget that
>>>>>> after you have been told 10,000 times.
>>>>>
>>>>> You have never answered both (1) and (2). But the crank response is
>>>>> always to say "I've told you 1000 times" rather than simply saying what
>>>>> the input is: hic Rhodus, hic salta.
>>>>>
>>>>>>> (1) "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" is, presumably, ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>> (2) The only reasonable meaning for whether a string halts or not
>>>>>>> would
>>>>>>> be what happens if it were passed to a UTM, but UTM ⟨Ĥ⟩ ⟨Ĥ⟩ is a
>>>>>>> halting
>>>>>>> computation (because Ĥ(⟨Ĥ⟩) is a halting computation).
>>>>>>
>>>>>> It would seem that way only if you very diligently make sure to not
>>>>>> pay attention to the execution trace of the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩,
>>>>>> which can only be 100% fully elaborated by its proxy computation
>>>>>> H(P,P).
>>>>>
>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting computation. That can't explain your magic
>>>>> phrase. What is the "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and what does it mean
>>>>> for an input to "never halt"?
>>>>>
>>>>
>>>> Perhaps your lack of understanding of the C/x86 H(P,P) computation
>>>> proves that our dialogue can never be fruitful thus no sense in
>>>> continuing.
>>>>
>>>> This lack of technical competence would also prevent you from accurately
>>>> assessing that H(P,P) is a valid proxy computation for Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>
>>>> (a) It is the case that H(P,P)==0 is correct
>>>>
>>>> Not having any understanding of the x86 language makes it impossible to
>>>> understand that the simulation of the input to H(P,P) cannot possibly
>>>> ever halt unless H aborts this simulation.
>>>>
>>>
>>> And I have NEVER seen a proper x86 processor that when execting a
>>> Call 0966 ends up at C36.
>>>
>>
>> I have explained this to you at least 50 times you are a Jackass.
>>
>
> And your explaination is still wrong.
>
> Since H WILL affect the code that is calling it, ignoring that is just
> going to give you the wrong answer.
>
As least your replies are getting far less stupid.
After hundreds of times that I have told you, this is the first time
that you did not simply ignore all of the words that I said.
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
main() outputs 0 instead of 1 because the input to H(P,P) never halts.
> PERIOD.
>
> Now, If you want to write an ACTUAL proof, you know, something that
> quotes ACTUAL accepted truths and combines then with accepted logical
> principles, to try to prove your statement, go ahead.
>
> The fact that it seems obvious top you by the meaning of the words,
> when you have already shown that you don't actually know the meaning of
> the words is not a proof.
>
> You get the wrong answer by the definition, putting up a lot of smoke
> doesn't make it right.
>
> Your Decider is BROKEN because your simulator gives the WRONG trace.
>
> PERIOD.
>
>>> Fail
>>>
>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>> [00000c36][002117ca][002117ce] 55 push ebp
>>>> [00000c37][002117ca][002117ce] 8bec mov ebp,esp
>>>> [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
>>>> [00000c3c][002117c6][00000c36] 50 push eax // push P
>>>> [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
>>>> [00000c40][002117c2][00000c36] 51 push ecx // push P
>>>> [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)
>>>>
>>>> [00000c36][0025c1f2][0025c1f6] 55 push ebp
>>>> [00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
>>>> [00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
>>>> [00000c3c][0025c1ee][00000c36] 50 push eax // push P
>>>> [00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
>>>> [00000c40][0025c1ea][00000c36] 51 push ecx // push P
>>>> [00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>
>>>> (b) It is the case that H1((P,P)==1 is correct
>>>> (c) It is the case the this is inconsistent.
>>>> (d) It is the case that this inconsistency defines a decidability
>>>> decider that correctly rejects P on the basis that P has the
>>>> pathological self-reference(Olcott 2004) error.
>>>>
>>>>
>>>>
>>>>> My other guess is that even /you/ know what you mean by it. Clarity is
>>>>> your enemy right now. Magic phrases are your friends.
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-09 22:25 -0400 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <xmz_I.41352$jm6.5263@fx07.iad> |
| In reply to | #39247 |
On 9/9/21 8:46 PM, olcott wrote:
> On 9/9/2021 7:38 PM, Richard Damon wrote:
>> On 9/9/21 7:50 PM, olcott wrote:
>>> On 9/9/2021 6:30 PM, Richard Damon wrote:
>>>> On 9/9/21 11:51 AM, olcott wrote:
>>>>> On 9/9/2021 10:41 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 9/9/2021 10:05 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> It is the pathological self-reference error:
>>>>>>>> ...
>>>>>>>>> (c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>> Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
>>>>>>>> (1) What is "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and (2) what does it
>>>>>>>> mean to
>>>>>>>> say
>>>>>>>> that an input (presumably a string) does or does not halt? The
>>>>>>>> only
>>>>>>>> reasonable answers show that you are wrong.
>>>>>>>
>>>>>>> Since it is well established and repeated 12 times a day every
>>>>>>> day for
>>>>>>> six months that H and Ĥ.qx are simulating halt deciders it is 100%
>>>>>>> perfectly clear exactly what the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ does not
>>>>>>> halts
>>>>>>> means.
>>>>>>>
>>>>>>> You are being a total jackass when you pretend to forget that
>>>>>>> after you have been told 10,000 times.
>>>>>>
>>>>>> You have never answered both (1) and (2). But the crank response is
>>>>>> always to say "I've told you 1000 times" rather than simply saying
>>>>>> what
>>>>>> the input is: hic Rhodus, hic salta.
>>>>>>
>>>>>>>> (1) "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" is, presumably, ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>> (2) The only reasonable meaning for whether a string halts or not
>>>>>>>> would
>>>>>>>> be what happens if it were passed to a UTM, but UTM ⟨Ĥ⟩ ⟨Ĥ⟩ is a
>>>>>>>> halting
>>>>>>>> computation (because Ĥ(⟨Ĥ⟩) is a halting computation).
>>>>>>>
>>>>>>> It would seem that way only if you very diligently make sure to not
>>>>>>> pay attention to the execution trace of the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩,
>>>>>>> which can only be 100% fully elaborated by its proxy computation
>>>>>>> H(P,P).
>>>>>>
>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting computation. That can't explain your magic
>>>>>> phrase. What is the "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and what does it
>>>>>> mean
>>>>>> for an input to "never halt"?
>>>>>>
>>>>>
>>>>> Perhaps your lack of understanding of the C/x86 H(P,P) computation
>>>>> proves that our dialogue can never be fruitful thus no sense in
>>>>> continuing.
>>>>>
>>>>> This lack of technical competence would also prevent you from
>>>>> accurately
>>>>> assessing that H(P,P) is a valid proxy computation for Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>
>>>>> (a) It is the case that H(P,P)==0 is correct
>>>>>
>>>>> Not having any understanding of the x86 language makes it
>>>>> impossible to
>>>>> understand that the simulation of the input to H(P,P) cannot possibly
>>>>> ever halt unless H aborts this simulation.
>>>>>
>>>>
>>>> And I have NEVER seen a proper x86 processor that when execting a
>>>> Call 0966 ends up at C36.
>>>>
>>>
>>> I have explained this to you at least 50 times you are a Jackass.
>>>
>>
>> And your explaination is still wrong.
>>
>> Since H WILL affect the code that is calling it, ignoring that is just
>> going to give you the wrong answer.
>>
>
> As least your replies are getting far less stupid.
> After hundreds of times that I have told you, this is the first time
> that you did not simply ignore all of the words that I said.
>
> // Simplified Linz Ĥ (Linz:1990:319)
> // Strachey(1965) CPL translated to C
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> main() outputs 0 instead of 1 because the input to H(P,P) never halts.
Except that it does. H just never simulates far enough to see it.
Remember, the DEFINITION of what H is being asked is what does that
ACTUAL MACHINE that the input REPRESENTS do.
P(P) Halts, and you admit that.
Thus what H(P,P) needs to answer, is what does the unconstrained
Computation P(P) do. It halts, so the right answer is Halt. H says
non-Halting, so it is wrong.
You don't get to change the meaning of the question, no matter how much
you want to or need to in order to make your point.
The fact that H can never see in its simulation that P(P) will halt does
not make the input into the representation of a non-halting Computation.
You are just working with wrong definitions, so you get wrong answers.
If you want to use different definitions, that is find, you just need to
make it clear that you are working on POOP and not the Halting Problem,
which also means you can't claim that you results affect the real
halting problem in any way.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-09 22:19 -0400 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <Bgz_I.9553$nh7.4409@fx22.iad> |
| In reply to | #39229 |
On 9/9/21 11:25 AM, olcott wrote: > On 9/9/2021 10:05 AM, Ben Bacarisse wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> It is the pathological self-reference error: >> ... >>> (c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>> Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts >> >> (1) What is "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and (2) what does it mean to say >> that an input (presumably a string) does or does not halt? The only >> reasonable answers show that you are wrong. >> > > Since it is well established and repeated 12 times a day every day for > six months that H and Ĥ.qx are simulating halt deciders it is 100% > perfectly clear exactly what the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ does not halts > means. You are being a total jackass when you pretend to forget that > after you have been told 10,000 times. Yes, it is perfectly clear, and that clearity is why you won't quote it because it shows you are wrong. The WORLD understands that what you MEAN to say is that the machine that the input represents would, when run unconditionally, never reach a halting state. The problem is that YOU seem to want it to mean that the partial simulator never gets to see a Halting state in the machine. What Others would call a 'Not-Yet-Halted' state, not a non-halting state. Your reluctance to actually spell out your definitions shows that you are being intentionally deceptive (in other words, lying). Note, remember how you goal is to get this stuff published, well the first rule of publishing something like this is that you need to AT THE START, begin with a set of definitions, either referring to well established definitions of things already defined, or clearly defining any new terms. You will NOT be allowed to 'redefine' established terms of art (like Halting or Computation), but will need to clearly indicate altered meaning with a modification of the word. So if you want to use the POOP definition of Halting, you will need to consistently refer to it as something like PO-Halting. Of course, then you would have to admit that you aren't solving the 'Halting Problem' but some POOP 'PO-Halting Problem' which doesn't sound anywhere near as impressive. > >> (1) "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" is, presumably, ⟨Ĥ⟩ ⟨Ĥ⟩. >> >> (2) The only reasonable meaning for whether a string halts or not would >> be what happens if it were passed to a UTM, but UTM ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting >> computation (because Ĥ(⟨Ĥ⟩) is a halting computation). >> > > It would seem that way only if you very diligently make sure to not pay > attention to the execution trace of the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩, which can > only be 100% fully elaborated by its proxy computation H(P,P). No, the proper determination of what the input represents is to give it to something that is defined to act like what the input represents, and that would be a REAL UTM, not something that just plays one on TV for a bit. > > Perhaps your lack of understanding of the C/x86 H(P,P) computation > proves that our dialogue can never be fruitful thus no sense in continuing. > > It is the case that H(P,P)==0 is correct No. > It is the case that H1((P,P)==1 is correct Yes > It is the case the this is inconsistent. > It is the case that this inconsistency defines a decidability > decider that correctly rejects P on the basis that P has the > pathological self-reference(Olcott 2004) error. > No, it shows that H is wrong, and can't decide correctly, or that H isn't even qualified to be in the game. > >> Your sentence actually has poor choices of words because, in addition to >> (1) and (2), "Ĥ halts" is also meaningless. Computations halt (or >> don't) not Turing machines. >> >> A note to other readers: the poor use of words is deliberate. 90% of >> PO's posting use vague undefined notions because saying things clearly >> just makes the mistakes too obvious. "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never >> halts" is a magic incantation, often repeated, that is never explained. >> When pushed, the answer is typically some crank non-explanation: "so you >> don't know what an input is?". >> > >
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-09 22:05 -0400 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <14z_I.26262$6U3.24780@fx43.iad> |
| In reply to | #39225 |
On 9/9/21 10:16 AM, olcott wrote:
> On 9/9/2021 6:05 AM, Richard Damon wrote:
>> On 9/9/21 12:10 AM, olcott wrote:
>>> On 9/8/2021 10:50 PM, Richard Damon wrote:
>>>> On 9/8/21 11:30 PM, olcott wrote:
>>>>> On 9/8/2021 10:20 PM, Richard Damon wrote:
>>>>>> On 9/8/21 10:33 PM, olcott wrote:
>>>>>>> On 9/8/2021 8:32 PM, Richard Damon wrote:
>>>>>>>> On 9/8/21 9:17 PM, olcott wrote:
>>>>>>>>> On 9/8/2021 8:09 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-09-08 18:01, olcott wrote:
>>>>>>>>>>
>>>>>>>>>>> The execution trace of the input to H1(P,P) conclusively proves
>>>>>>>>>>> that
>>>>>>>>>>> this input definitely halts.
>>>>>>>>>>>
>>>>>>>>>>> The execution trace of the input to H(P,P) called from H1(P,P)
>>>>>>>>>>> conclusively proves that this input definitely never halts.
>>>>>>>>>>
>>>>>>>>>> No. The execution trace shows that your halt decider decides to
>>>>>>>>>> abort
>>>>>>>>>> the simulation. That's completely different from showing that
>>>>>>>>>> this
>>>>>>>>>> input 'definitely never halts'. Your grasp of what traces show is
>>>>>>>>>> seriously lacking.
>>>>>>>>>>
>>>>>>>>>> Since P(P) either halts or it doesn't, it isn't possible for
>>>>>>>>>> both of
>>>>>>>>>> the above deciders to be correct. So how can they both
>>>>>>>>>> 'conclusively
>>>>>>>>>> prove' contradictory answers?
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Richard said that such a system would be inconsistent.
>>>>>>>>> I agree, this is a key new insight.
>>>>>>>>
>>>>>>>> Right, YOUR LOGIC SYSTEM has been shown to be inconsistent, likelyy
>>>>>>>> because you have assumes a (or many) false statements as fact.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Since the execution trace of the input to H1(P,P) conclusively
>>>>>>>>> proves
>>>>>>>>> that it halts and the execution trace of the input to H(P,P)
>>>>>>>>> conclusively proves that it never halts we do have an inconsistent
>>>>>>>>> system.
>>>>>>>>
>>>>>>>> Right, YOU LOGIC that says the two are correct is faulty and
>>>>>>>> inconsistent.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is inconsistent on the basis of its input that has the
>>>>>>>>> pathological
>>>>>>>>> self-reference(Olcott 2004) error, which is detected by this code:
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope.
>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>>>>>>>>> OutputString("Pathological self-reference error!");
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Thus refuting Rice's theorem and the halting theorem. We accept
>>>>>>>>> the
>>>>>>>>> H1(P,P) halt status as correct because P does not refer to H1.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope, FAIL.
>>>>>>>>
>>>>>>>
>>>>>>> You never try to show how I am wrong you merely assert that you
>>>>>>> believe
>>>>>>> that I am wrong. If you cannot show my mistake that is for one of
>>>>>>> two
>>>>>>> reasons:
>>>>>>
>>>>>> The criteria that you are claiming to decide on is Syntactic, not
>>>>>> Symantec, and thus not under the domain of Rice's theorem.
>>>>>>
>>>>>
>>>>> Ah great now that you committed to a position I can say that you are
>>>>> wrong. An undecidability decider decides a semantic property.
>>>>>
>>>>>>>
>>>>>>> (1) I made no mistake
>>>>>>> (2) You don't understand these things very well
>>>>>>
>>>>>> You don't understand what you claim to be disproving.
>>>>>>
>>>>>>>
>>>>>>> That the system derives an inconsistent result and each result is
>>>>>>> confirmed to be correct means bad input.
>>>>>>
>>>>>> If a system is inconsistent, it isn't the 'inputs' that are bad
>>>>>> (as in
>>>>>> the inputs to the machines). The LOGIC SYSTEM is bad, and that shows
>>>>>> that the 'axioms' used to build it (your 'truisms') are flawed.
>>>>>>
>>>>>
>>>>> Since we can verify by the execution trace that H1(P,P)==1 is correct
>>>>> and H(P,P)==0 is correct it is not the logical system.
>>>>>
>>>>> "This sentence is not true" has the same error and it is not the fault
>>>>> of the logic system.
>>>>
>>>> So you thing that it is possible for the statement "H^(<H^>) is a
>>>> Halting Computation" can both be True and False?
>>>>
>>>> The fact that you claim the execution traces prove it, just shows that
>>>> the inconsitency runs deep in the system, and isn't just a small error
>>>> at the end.
>>>>
>>>> Basically you are admitting that your system if fatally flawed, only
>>>> you
>>>> are smart enough to see it.
>>>>
>>>
>>>
>>> It is definitely an inconsistency, yet not because the system is
>>> inconsistent.
>>
>> Your choices are either your logic system is inconsistent, or H is
>> inconsistent in the value it produces, and thus you have LIED in calling
>> it a Computation.
>>
>> That is your choices.
>>
>>>
>>> int main()
>>> {
>>> if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>>> OutputString("Pathological self-reference error!");
>>> }
>>>
>>> The above decidability decider correctly rejects the input
>>
>> So? You have just created some criteria that you can show one example
>> that it decides correctly. Doesn't mean that you actually shown anything.
>>
>
> The decidability decider proves that the input is bad because is has the
> pathological self-reference(Olcott 2004) error.
Except that there is no such error. BY DEFINITION a Universal Halt
Decider must be able to decide ALL inputs. It doesn't get to say there
are some that aren't allowed..
This is just your POOP.
>
> The source of the inconsistency is bad data not incorrect formal system.
> "This sentence is not true" is another example of this same bad data.
"This sentence is not true" is a statement that can not be assigned a
truth value, and thus isn't in the category of a 'fact'
Does the Machine H^(<H^>) Halt? Does have a precise value for any given
H, so it is NOT that sort of error.
Yes, the case you would have to reject the input as invalid would be if
P wasn't actually a Computation. Because Halt Deciders only need to be
able to decide computation.
And maybe in this case that is the issue, H^ might not be a Computation,
but that case can only come up if H isn't a Computation, as the ^
transform will always generate a Computation when given one. This is
provable.
So, if you actually prove that H^ isn't a valid machine to give to a
Halt Decider by some proof, what you have done is proven that yout
claimed Halt Decider isn't a Computation, and thus not eligible to be a
Halt Decider, so it doesn't become a counter example to Linz.
>
>> Can you describe in WORDS that don't refer to the program what the
>> condition you are deciding on actually is? Something that is Semantic in
>> definition. Then we can see if your 'Universal Decidability Decider'
>> actually works.
>>
>
> It is the pathological self-reference error:
> (a) "This sentence is not true"
> (b) "This sentence is unprovable"
> (c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
>
FALSE. STRAWMAN
The Input to H^.qx represents a Halting Computation. (based on your
claim that H will answer non-halting for it)
Yes, H can never simulate that input to a Halting State, because,
depending on WHICH H you are talking about, it will either terminate its
simulation too soon and make the wrong decision, or it will never make
the decision.
In the first case it gives the wrong answer, in the second it never
answers, both show it not to be a correct halt decider for that input.
It should be also noted that (c) actually has NO real self-reference in it.
<H^> does NOT say I am the description of the machine I am being give to
(that would be self reference), note how (A) and (B) use the pronoun
'this'. <H^> is just the description of H^ and does NOT 'refer' to it.
That is like you can talk about something like the Tale of Two Cities in
two different ways. One is to reference it by name (or pronoun), the
other is by quoting it: "It was the Best of Times, It was the Worst of
Time...".
Doing the first creates a "reference", and if that reference is in the
work, a 'self-reference'.
The second doesn't, it creates a copy.
<H^> is a copy, not a reference.
In some ways, because of your ERROR in how you translate this into your
machine, you did switch it to a reference (but not a self reference in
H^ itself), and that is one of the reasons you 'equivalence' isn't true.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-08 20:17 -0400 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <boc_I.38839$md6.18421@fx36.iad> |
| In reply to | #39131 |
On 9/8/21 10:20 AM, olcott wrote:
> On 9/8/2021 1:14 AM, André G. Isaak wrote:
>> On 2021-09-07 21:18, olcott wrote:
>>> On 9/7/2021 10:09 PM, André G. Isaak wrote:
>>>> On 2021-09-07 20:53, olcott wrote:
>>>>
>>>>> int main() { H1(P,P); } simulates P that calls H(P,P)
>>>>> makes H1(P,P) a different computation than H(P,P).
>>>>>
>>>>> The functions H and H1 behave differently when invoked with inputs
>>>>> that refer to themselves than when their inputs do not refer to
>>>>> themselves.
>>>>>
>>>>> That explains the difference in the behavior of H1 and H.
>>>>> This makes H1/H a distinctly different computation than H1/H1 or H/H.
>>>>
>>>> The problem here is that when dealing with actual computations (i.e.
>>>> Turing Machines), nothing refers 'to itself'.
>>>>
>>>
>>> Now Ĥ is a Turing machine, so that it will have
>>> some description in Σ*, say ŵ. This string, in
>>> addition to being the description of Ĥ can also
>>> be used as input string. We can therefore legitimately
>>> ask what would happen if Ĥ is applied to ŵ.
>>> (its own Turing machine description)
>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>
>>> I encode this more clearly as: Ĥ applied to ⟨Ĥ⟩
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>>>
>>> Make sure that you refer to these notational conventions not the one
>>> that Linz provides with the two start states and vagueness about
>>> which inputs go where, and which states are which.
>>
>> I have no idea how the above is supposed to be a response to the point
>> I was making. You claimed that your H and H1 behave different when
>> their inputs refer to 'themselves'. I pointed out that when dealing
>> with TMs, nothing 'refers to itself'. The above doesn't address this
>> at all.
>>
>
> You said nothing refers to itself.
> I showed you how Ĥ applied to ⟨Ĥ⟩ thus Ĥ refers to itself.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ sees that Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qn
>
> Ĥ.qx sees that its input ⟨Ĥ⟩ ⟨Ĥ⟩ is in an infinitely repeating cycle
> that never halts unless Ĥ.qx aborts its simulation of this input ⟨Ĥ⟩ ⟨Ĥ⟩
But since H^.qx (aka H) DOES abort its simulation of this input, H^
turns out to be a Halting Computation.
It doesn't matter WHY a machine halts, just that it does.
>
>> Linz's Ĥ takes as an input a complete description of a Turing Machine.
>> Do you understand that a complete description is not a reference?
>>
>> A reference would be something that says 'a TM that behaves just like
>> that one over there'
>>
>> A description gives a complete description of a the of state
>> transitions which defines a TM. It doesn't 'point' to some other machine.
>>
>> If you give a TM as an input a description of a machine that happens
>> to be identical to itself, that TM has absolutely no way of
>> recognizing that the description it has been given describes itself,
>> so how can this make a difference?
>>
>
> It need not know that the input is itself it only needs to tell that all
> of the inputs are identical and none of them will ever halt unless their
> simulation is aborted.
But since the simulated simulation IS aborted, the simulation will come
to a Halt in finite time, and thus doesn't actually need to be aborted
(but will be incorrectly).
Halting only because of X is still Halting.
I will also challenge you to actually TRY to create such a detection
system that is actually reliable. H needs to be able to identify all
representations of itself, which has been proved to be impossible.
>
> The exact same set of state transitions occurs every time that the
> simulation of a machine begins until the next cycle when the simulation
> of another copy begins.
>
> The machine code of P and a P1 exact copy of P is identical even though
> they are stored at different machine addresses because the x86 language
> uses relative addressing.
>
>> And if your H and your H1 are identical, then their *descriptions*
>> will also be identical, so what you write above about H and H1
>> behaving differently when their input 'refers to themselves' is simply
>> nonsensical.
>>
>> André
>>
>
> In the C/x86 model that uses H1/H
> H1 behaves differently when it sees that another C function has aborted
> its input so that H1 doesn't have to abort its input.
>
> It doesn't have to an identical C function, it just can't be the same C
> function. It is basically a case of someone else already did my work for
> me so now that the work is done I don't have to do it.
>
> The master UTM / halt decider H1 can see everything that it simulates:
> (a) P begins
> (b) P calls H(P,P)
> (c) H returns to P
> (d) P returns to main() where it was simulated by H1.
>
> The master UTM / halt decider H can see everything that it simulates:
> (a) P begins
> (b) P calls H(P,P)
> (c) P begins
> (e) P calls H(P,P)
> H(P,P) sees that it must abort its simulation of its input or its input
> never halts.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-08 07:15 -0400 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <dX0_I.32613$2Q_3.13570@fx35.iad> |
| In reply to | #39124 |
On 9/7/21 11:18 PM, olcott wrote:
> On 9/7/2021 10:09 PM, André G. Isaak wrote:
>> On 2021-09-07 20:53, olcott wrote:
>>
>>> int main() { H1(P,P); } simulates P that calls H(P,P)
>>> makes H1(P,P) a different computation than H(P,P).
>>>
>>> The functions H and H1 behave differently when invoked with inputs
>>> that refer to themselves than when their inputs do not refer to
>>> themselves.
>>>
>>> That explains the difference in the behavior of H1 and H.
>>> This makes H1/H a distinctly different computation than H1/H1 or H/H.
>>
>> The problem here is that when dealing with actual computations (i.e.
>> Turing Machines), nothing refers 'to itself'.
>>
>
> Now Ĥ is a Turing machine, so that it will have
> some description in Σ*, say ŵ. This string, in
> addition to being the description of Ĥ can also
> be used as input string. We can therefore legitimately
> ask what would happen if Ĥ is applied to ŵ.
> (its own Turing machine description)
> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>
> I encode this more clearly as: Ĥ applied to ⟨Ĥ⟩
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>
> Make sure that you refer to these notational conventions not the one
> that Linz provides with the two start states and vagueness about which
> inputs go where, and which states are which.
Right, except that H^.q0 <H^> -> H^.qx <H^> <H^> -> H^.qn Halts since we
have that H.q0 <H^> <H^> -> H.qn and H^.qx and H.q0 lead into machines
that are exactly equivalent, except for state qy which we never get to.
Same algorithm, same data, means they MUST transition the same.
Note, the conditions do not define what actually happens, but what NEEDS
to happen to be correct.
Since it has been shown that you H WILL decide that H^ <H^> will be
non-halting, H will go to qn, and thus the identical copy of that
algorithm will ALSO go to qn and then Halt, showing the decision was wrong.
You can't say that H^ must go to qy because it was decided to be
non-halting, that is the tail wagging the dog, we KNOW from the
definitions that H^ MUST go to H^.qn if H goes to its qn.
PERIOD.
H is WRONG.
>
>> Remember that in the Linz proof, we construct H_Hat by making a copy
>> of H and then modifying that copy.
>>
>> When we make a copy of a H and modify it, we end up with an entirely
>> new TM H_Hat which is completely independent from H. Neither "refers"
>> to the other at all. Remember that it isn't possible for a Turing
>> Machine to "call" another Turing Machine the way you have your P()
>> call your H(). That's simply *not* an allowable option in the domain
>> of Turing Machines.
>>
>> And since the Linz proof is *about* Turing Machines, any 'refutation'
>> of that proof must be stated in terms of Turing Machines, or at least
>> in terms of something which clearly could be implemented using Turing
>> Machines. Your P() can't be implemented as a Turing Machine.
>>
>> André
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-08 07:04 -0400 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <7N0_I.40847$jm6.21380@fx07.iad> |
| In reply to | #39119 |
On 9/7/21 10:53 PM, olcott wrote:
> On 9/7/2021 9:27 PM, Richard Damon wrote:
>> On 9/7/21 10:18 PM, olcott wrote:
>>> On 9/7/2021 8:55 PM, Richard Damon wrote:
>>>> On 9/7/21 9:28 PM, olcott wrote:
>>>>> On 9/7/2021 8:12 PM, Richard Damon wrote:
>>>>>> On 9/7/21 9:08 PM, olcott wrote:
>>>>>>> On 9/7/2021 7:42 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 9/7/2021 10:31 AM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 9/7/2021 5:54 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/6/2021 8:57 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/6/2021 8:09 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9/6/2021 7:40 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> TM at H^.qx is an "exact
>>>>>>>>>>>>>>>>>> copy" of H. How can two TMs that are exact copies of
>>>>>>>>>>>>>>>>>> each
>>>>>>>>>>>>>>>>>> other make
>>>>>>>>>>>>>>>>>> different transitions given the same input?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That H1 calls H means that H1 can see what H does.
>>>>>>>>>>>>>>>>> The H is called by H1 means that H does not even know
>>>>>>>>>>>>>>>>> that H1
>>>>>>>>>>>>>>>>> exists.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> TMs don't call each other.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ creates a master slave relationship
>>>>>>>>>>>>>>> between H and Ĥ.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The master can see exactly what the slave is doing.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The slave it totally unaware of the existence of the master.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The master can change its behavior on the basis of what the
>>>>>>>>>>>>>>> slave does.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The slave cannot change its behavior on the basis of what
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> master does.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thus the master slave relationship can and does cause an
>>>>>>>>>>>>>>> identical
>>>>>>>>>>>>>>> function with the same input to have different behavior
>>>>>>>>>>>>>>> even if
>>>>>>>>>>>>>>> no one
>>>>>>>>>>>>>>> ever noticed this before.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Function? Have you been only pretending to be talking about
>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>> machines the whole time? If you were not being deceitful,
>>>>>>>>>>>>>> your
>>>>>>>>>>>>>> H (the
>>>>>>>>>>>>>> TM) is wrong because
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H.q0 <H^><H^> |- H.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> No matter how much you ignore the fact that the master slave
>>>>>>>>>>>>> relationship where H is the master of Ĥ causes different
>>>>>>>>>>>>> behavior:
>>>>>>>>>>>>>
>>>>>>>>>>>>> H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>> Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>
>>>>>>>>>>>>> for two identical functions with the same input, this master
>>>>>>>>>>>>> slave
>>>>>>>>>>>>> relationship still causes differing behavior.
>>>>>>>>>>>>
>>>>>>>>>>>> Functions? You used the notation of Turing machines. Were you
>>>>>>>>>>>> being
>>>>>>>>>>>> deceptive? I am perfectly prepared to accept that you are
>>>>>>>>>>>> cheating in
>>>>>>>>>>>> some way with your hidden C functions, but you can't cheat with
>>>>>>>>>>>> TMs.
>>>>>>>>>>>> What you said using the notation of TMs was wrong (about TMs)
>>>>>>>>>>>> because
>>>>>>>>>>>> identical state transition functions produce the same
>>>>>>>>>>>> transitions
>>>>>>>>>>>> when
>>>>>>>>>>>> given identical input. So your recent admission that your H
>>>>>>>>>>>> should
>>>>>>>>>>>> accept the string <H^><H^> means that
>>>>>>>>>>>>
>>>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>>>>
>>>>>>>>>>>> shows your H is wrong -- on your own terms. The facts of the
>>>>>>>>>>>> matter
>>>>>>>>>>>> come from you.
>>>>>>>>>>>>
>>>>>>>>>>>> I can stop posting if you admit you have been disingenuously
>>>>>>>>>>>> using
>>>>>>>>>>>> the
>>>>>>>>>>>> notation of TMs to talk about your dodgy C code. If you
>>>>>>>>>>>> want to
>>>>>>>>>>>> keep
>>>>>>>>>>>> talking about TMs you need to admit you are wrong. Identical
>>>>>>>>>>>> state
>>>>>>>>>>>> transition functions with identical inputs always generate the
>>>>>>>>>>>> same
>>>>>>>>>>>> sequence of machine configurations.
>>>>>>>>>>>
>>>>>>>>>>> So in other words you have another shortcoming in your technical
>>>>>>>>>>> knowledge this time it is directly in the field of computer
>>>>>>>>>>> science on
>>>>>>>>>>> not in related fields such as software engineering.
>>>>>>>>>>>
>>>>>>>>>>> You seem to be unaware that the TM description being simulated
>>>>>>>>>>> by a
>>>>>>>>>>> UTM has no access to see the internal steps of its simulator
>>>>>>>>>>> and yet
>>>>>>>>>>> the UTM can directly see all of the steps of the TM description
>>>>>>>>>>> that
>>>>>>>>>>> it is simulating.
>>>>>>>>>> So you are talking about TMs after all? Please use the correct
>>>>>>>>>> language. TMs don't have "functions" and don't make "calls".
>>>>>>>>>> Identical state transition functions with identical inputs always
>>>>>>>>>> generate the same sequence of machine configurations so, the
>>>>>>>>>> often
>>>>>>>>>> quoted property of your H^:
>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>> shows that your H is wrong.
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>>>>>>>>> OutputString("Pathological self-reference error!");
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> if (H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ != Ĥ applied to ⟨Ĥ⟩)
>>>>>>>>> OutputString("Pathological self-reference error!");
>>>>>>>>
>>>>>>>> You need to pay attention. I can't help you if you just put your
>>>>>>>> fingers in your ears and chant.
>>>>>>>>
>>>>>>>>>> ... You tell us that H should accept <H^><H^>
>>>>>>>>>> and you tell us that the TM at H^.qx is an "exact copy" of H and
>>>>>>>>>> you
>>>>>>>>>> tell us that H^.qx <H^><H^> |- H^.qn. You tell us everything we
>>>>>>>>>> need to
>>>>>>>>>> know that you are wrong. The only thing missing is an apology
>>>>>>>>>> from you
>>>>>>>>>> for ignoring these helpful explanations for so long.
>>>>>>>>
>>>>>>>> Is there anything here you don't understand? It's not hard.
>>>>>>>> Identical
>>>>>>>> state transition functions always generate the same computational
>>>>>>>> steps
>>>>>>>> when presented with the same input.
>>>>>>>>
>>>>>>>
>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>>> // Strachey(1965) CPL translated to C
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>> if (H(x, x))
>>>>>>> HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> When the exact analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>> int main() { H1(P,P); } is examined
>>>>>>>
>>>>>>> When code of the x86 H1 and H is identical and their input is the
>>>>>>> same
>>>>>>> yet their behavior is different then we know that something is up.
>>>>>>>
>>>>>>> When we examine actual fully operational code we can't simply assume
>>>>>>> that we imagined the behavior incorrectly.
>>>>>>>
>>>>>>> That only leaves the code and the input. The input is the same
>>>>>>> 32-bit
>>>>>>> integer, that only leaves the code.
>>>>>>>
>>>>>>> It turns out that the most plausible explanation is that the code
>>>>>>> is not
>>>>>>> the same. The master / slave relationship between H1/H and H/Ĥ is
>>>>>>> hard
>>>>>>> coded into the full H1/H and H/Ĥ computations.
>>>>>>>
>>>>>>> The fact that:
>>>>>>> H1 simulates P that simulates H(P,P)
>>>>>>> H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ that simulates ⟨Ĥ⟩ ⟨Ĥ⟩ at Ĥ.qx
>>>>>>>
>>>>>>> hard codes the master / slave relationships between H1/H and H/Ĥ.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Just means that the code does not code an actual Computation, but
>>>>>> somewhere is using data that is NOT part of its formal input to make
>>>>>> the
>>>>>> decision.
>>>>>>
>>>>>
>>>>> If the code is identical and the input is identical then the behavior
>>>>> must be identical. If the code is not identical and the input is
>>>>> identical then the behavior need not be identical.
>>>>>
>>>>> Different code with the same input can derive different results as a
>>>>> pure function of this input.
>>>>>
>>>>
>>>> So you admit that they have different code?
>>>>
>>>> I thought your claim was that H and H1 had identical code.
>>>>
>>>
>>> int main() { H1(P,P); } specifies that H1 is in a master slave
>>> relationship with H(P,P) even though H1 and H have identical code.
>>>
>>> The master / slave relationship specified in main() defines H1 as a
>>> distinctly different computation than H.
>>>
>>> The exact same thing works in reverse.
>>> int main() { H(P,P); } that simulates P the calls H1...
>>
>> If H1 and H have the same code and get the same input then they MUST
>> behave the same. That is FUNDAMENTAL to how computers work.
>>
>
> int main() { H1(P,P); } simulates P that calls H(P,P)
> makes H1(P,P) a different computation than H(P,P).
>
> The functions H and H1 behave differently when invoked with inputs that
> refer to themselves than when their inputs do not refer to themselves.
No, there MUST be either a DIFFERNCE between the two programs, or the
programs are not Computations of their defined inputs, but have so other
input.
This is a Fact.
The fact that you won't show the code says we can't point out exactly
where that difference is.
That different input could even just be the contents of the Program
Counter when executing the code.
Think of it this way, you have a defined assembly instruction sequence,
and a defined data input to these. If both are the same, the programs
WILL execute identically. If not, you have a broken computer.
Look at the two traces of the PROGRAM executing, look at the point they
diverge. SOMETHING will be different.
Either you have a data difference, or an instruction difference.
PERIOD.
That you think two truly identical programs with identical inputs can do
something different, then you don't understand how computers work.
I KNOW from your description that it is very likely that H is has a
problem in its definition. Your H is NOT the computational equivalent of
Linz H as it does things that can't be done in that manner in a Turing
Machine, and this likely means that it isn't accually a Computation of
its defined inputs.
THe fact that you don't see this, doesn't mean it isn't true, as you are
already stuck believing one known false statement, that it is possible
for a Halting Computation to be decided correctly as being non-halting,
and you keep coming up with stranger ways to try to justify it.
>
> That explains the difference in the behavior of H1 and H.
> This makes H1/H a distinctly different computation than H1/H1 or H/H.
>
> // This also explains how this is a
> // pathological self-reference decider
> // that refutes Rice's Theorem
> //
> int main()
> {
> if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
> OutputString("Pathological self-reference error!");
> }
>
But is Self-Reference a Semantic Property, or is it a Syntactic Property?
Since we can see the self reference by just examining the code for P,
and not actually running it, Rice's Theorem doesn't apply.
Maybe you need to understand the meaning of the words.
>> To act different, they need some input that is different. (maybe this
>> master / slave relationship).
>>
>> Since their formal inputs are the same, that means there is some other
>> input that is not a formal input that makes a difference, and thus they
>> fail to be a Computation, and thus not eligible to be a Decider.
>>
>> You have just voided you whole argument.
>>
>> H is admitted to not be a pure function of its defined inputs, thus not
>> eligable to be a Halt Decider.
>>
>> FAIL.
>>
>> (You just keep digging yourself in deeper).
>>
>>>
>>>> And H^ needs to have basically identical code to H embedded in it (the
>>>> only difference is in a state we don't get to).
>>>>
>>>> If you are now admitting the actual code is different, that shows that
>>>> your argument isn't valid any more.
>>>>
>>>
>>>
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-08 09:39 -0500 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <Ve-dne_5RZOMVqX8nZ2dnUU7-Q3NnZ2d@giganews.com> |
| In reply to | #39127 |
On 9/8/2021 6:04 AM, Richard Damon wrote:
> On 9/7/21 10:53 PM, olcott wrote:
>> On 9/7/2021 9:27 PM, Richard Damon wrote:
>>> On 9/7/21 10:18 PM, olcott wrote:
>>>> On 9/7/2021 8:55 PM, Richard Damon wrote:
>>>>> On 9/7/21 9:28 PM, olcott wrote:
>>>>>> On 9/7/2021 8:12 PM, Richard Damon wrote:
>>>>>>> On 9/7/21 9:08 PM, olcott wrote:
>>>>>>>> On 9/7/2021 7:42 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 9/7/2021 10:31 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 9/7/2021 5:54 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/6/2021 8:57 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 9/6/2021 8:09 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 9/6/2021 7:40 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> TM at H^.qx is an "exact
>>>>>>>>>>>>>>>>>>> copy" of H. How can two TMs that are exact copies of
>>>>>>>>>>>>>>>>>>> each
>>>>>>>>>>>>>>>>>>> other make
>>>>>>>>>>>>>>>>>>> different transitions given the same input?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That H1 calls H means that H1 can see what H does.
>>>>>>>>>>>>>>>>>> The H is called by H1 means that H does not even know
>>>>>>>>>>>>>>>>>> that H1
>>>>>>>>>>>>>>>>>> exists.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> TMs don't call each other.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ creates a master slave relationship
>>>>>>>>>>>>>>>> between H and Ĥ.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The master can see exactly what the slave is doing.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The slave it totally unaware of the existence of the master.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The master can change its behavior on the basis of what the
>>>>>>>>>>>>>>>> slave does.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The slave cannot change its behavior on the basis of what
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> master does.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thus the master slave relationship can and does cause an
>>>>>>>>>>>>>>>> identical
>>>>>>>>>>>>>>>> function with the same input to have different behavior
>>>>>>>>>>>>>>>> even if
>>>>>>>>>>>>>>>> no one
>>>>>>>>>>>>>>>> ever noticed this before.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Function? Have you been only pretending to be talking about
>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>> machines the whole time? If you were not being deceitful,
>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>> H (the
>>>>>>>>>>>>>>> TM) is wrong because
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H.q0 <H^><H^> |- H.qn
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No matter how much you ignore the fact that the master slave
>>>>>>>>>>>>>> relationship where H is the master of Ĥ causes different
>>>>>>>>>>>>>> behavior:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>> Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> for two identical functions with the same input, this master
>>>>>>>>>>>>>> slave
>>>>>>>>>>>>>> relationship still causes differing behavior.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Functions? You used the notation of Turing machines. Were you
>>>>>>>>>>>>> being
>>>>>>>>>>>>> deceptive? I am perfectly prepared to accept that you are
>>>>>>>>>>>>> cheating in
>>>>>>>>>>>>> some way with your hidden C functions, but you can't cheat with
>>>>>>>>>>>>> TMs.
>>>>>>>>>>>>> What you said using the notation of TMs was wrong (about TMs)
>>>>>>>>>>>>> because
>>>>>>>>>>>>> identical state transition functions produce the same
>>>>>>>>>>>>> transitions
>>>>>>>>>>>>> when
>>>>>>>>>>>>> given identical input. So your recent admission that your H
>>>>>>>>>>>>> should
>>>>>>>>>>>>> accept the string <H^><H^> means that
>>>>>>>>>>>>>
>>>>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> shows your H is wrong -- on your own terms. The facts of the
>>>>>>>>>>>>> matter
>>>>>>>>>>>>> come from you.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can stop posting if you admit you have been disingenuously
>>>>>>>>>>>>> using
>>>>>>>>>>>>> the
>>>>>>>>>>>>> notation of TMs to talk about your dodgy C code. If you
>>>>>>>>>>>>> want to
>>>>>>>>>>>>> keep
>>>>>>>>>>>>> talking about TMs you need to admit you are wrong. Identical
>>>>>>>>>>>>> state
>>>>>>>>>>>>> transition functions with identical inputs always generate the
>>>>>>>>>>>>> same
>>>>>>>>>>>>> sequence of machine configurations.
>>>>>>>>>>>>
>>>>>>>>>>>> So in other words you have another shortcoming in your technical
>>>>>>>>>>>> knowledge this time it is directly in the field of computer
>>>>>>>>>>>> science on
>>>>>>>>>>>> not in related fields such as software engineering.
>>>>>>>>>>>>
>>>>>>>>>>>> You seem to be unaware that the TM description being simulated
>>>>>>>>>>>> by a
>>>>>>>>>>>> UTM has no access to see the internal steps of its simulator
>>>>>>>>>>>> and yet
>>>>>>>>>>>> the UTM can directly see all of the steps of the TM description
>>>>>>>>>>>> that
>>>>>>>>>>>> it is simulating.
>>>>>>>>>>> So you are talking about TMs after all? Please use the correct
>>>>>>>>>>> language. TMs don't have "functions" and don't make "calls".
>>>>>>>>>>> Identical state transition functions with identical inputs always
>>>>>>>>>>> generate the same sequence of machine configurations so, the
>>>>>>>>>>> often
>>>>>>>>>>> quoted property of your H^:
>>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>>> shows that your H is wrong.
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>>>>>>>>>> OutputString("Pathological self-reference error!");
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> if (H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ != Ĥ applied to ⟨Ĥ⟩)
>>>>>>>>>> OutputString("Pathological self-reference error!");
>>>>>>>>>
>>>>>>>>> You need to pay attention. I can't help you if you just put your
>>>>>>>>> fingers in your ears and chant.
>>>>>>>>>
>>>>>>>>>>> ... You tell us that H should accept <H^><H^>
>>>>>>>>>>> and you tell us that the TM at H^.qx is an "exact copy" of H and
>>>>>>>>>>> you
>>>>>>>>>>> tell us that H^.qx <H^><H^> |- H^.qn. You tell us everything we
>>>>>>>>>>> need to
>>>>>>>>>>> know that you are wrong. The only thing missing is an apology
>>>>>>>>>>> from you
>>>>>>>>>>> for ignoring these helpful explanations for so long.
>>>>>>>>>
>>>>>>>>> Is there anything here you don't understand? It's not hard.
>>>>>>>>> Identical
>>>>>>>>> state transition functions always generate the same computational
>>>>>>>>> steps
>>>>>>>>> when presented with the same input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>>>> // Strachey(1965) CPL translated to C
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>> if (H(x, x))
>>>>>>>> HERE: goto HERE;
>>>>>>>> }
>>>>>>>>
>>>>>>>> When the exact analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>> int main() { H1(P,P); } is examined
>>>>>>>>
>>>>>>>> When code of the x86 H1 and H is identical and their input is the
>>>>>>>> same
>>>>>>>> yet their behavior is different then we know that something is up.
>>>>>>>>
>>>>>>>> When we examine actual fully operational code we can't simply assume
>>>>>>>> that we imagined the behavior incorrectly.
>>>>>>>>
>>>>>>>> That only leaves the code and the input. The input is the same
>>>>>>>> 32-bit
>>>>>>>> integer, that only leaves the code.
>>>>>>>>
>>>>>>>> It turns out that the most plausible explanation is that the code
>>>>>>>> is not
>>>>>>>> the same. The master / slave relationship between H1/H and H/Ĥ is
>>>>>>>> hard
>>>>>>>> coded into the full H1/H and H/Ĥ computations.
>>>>>>>>
>>>>>>>> The fact that:
>>>>>>>> H1 simulates P that simulates H(P,P)
>>>>>>>> H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ that simulates ⟨Ĥ⟩ ⟨Ĥ⟩ at Ĥ.qx
>>>>>>>>
>>>>>>>> hard codes the master / slave relationships between H1/H and H/Ĥ.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Just means that the code does not code an actual Computation, but
>>>>>>> somewhere is using data that is NOT part of its formal input to make
>>>>>>> the
>>>>>>> decision.
>>>>>>>
>>>>>>
>>>>>> If the code is identical and the input is identical then the behavior
>>>>>> must be identical. If the code is not identical and the input is
>>>>>> identical then the behavior need not be identical.
>>>>>>
>>>>>> Different code with the same input can derive different results as a
>>>>>> pure function of this input.
>>>>>>
>>>>>
>>>>> So you admit that they have different code?
>>>>>
>>>>> I thought your claim was that H and H1 had identical code.
>>>>>
>>>>
>>>> int main() { H1(P,P); } specifies that H1 is in a master slave
>>>> relationship with H(P,P) even though H1 and H have identical code.
>>>>
>>>> The master / slave relationship specified in main() defines H1 as a
>>>> distinctly different computation than H.
>>>>
>>>> The exact same thing works in reverse.
>>>> int main() { H(P,P); } that simulates P the calls H1...
>>>
>>> If H1 and H have the same code and get the same input then they MUST
>>> behave the same. That is FUNDAMENTAL to how computers work.
>>>
>>
>> int main() { H1(P,P); } simulates P that calls H(P,P)
>> makes H1(P,P) a different computation than H(P,P).
>>
>> The functions H and H1 behave differently when invoked with inputs that
>> refer to themselves than when their inputs do not refer to themselves.
>
> No, there MUST be either a DIFFERNCE between the two programs, or the
> programs are not Computations of their defined inputs, but have so other
> input.
It is simply a matter of H1/H1 or H/H does not see anyone else doing the
work of aborting the simulation of its input so it must do this work.
The H1 of H1/H sees that its input halts.
The H1 of H1/H1 sees that its input never halts.
The H of H1/H sees that its input never halts.
The H of H/H sees that its input never halts.
Here is the H1/H scenario in complete detail:
The master UTM / halt decider H1 can see everything that it simulates:
(a) P begins
(b) P calls H(P,P)
(c) H returns to P
(d) P returns to main() where it was simulated by H1.
The master UTM / halt decider H can see everything that it simulates:
(a) P begins
(b) P calls H(P,P)
(c) P begins
(e) P calls H(P,P)
H(P,P) sees that it must abort its simulation of its input or its input
never halts.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-08 20:01 -0400 |
| Subject | Re: H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <A9c_I.116270$o45.97067@fx46.iad> |
| In reply to | #39132 |
On 9/8/21 10:39 AM, olcott wrote:
> On 9/8/2021 6:04 AM, Richard Damon wrote:
>> On 9/7/21 10:53 PM, olcott wrote:
>>> On 9/7/2021 9:27 PM, Richard Damon wrote:
>>>> On 9/7/21 10:18 PM, olcott wrote:
>>>>> On 9/7/2021 8:55 PM, Richard Damon wrote:
>>>>>> On 9/7/21 9:28 PM, olcott wrote:
>>>>>>> On 9/7/2021 8:12 PM, Richard Damon wrote:
>>>>>>>> On 9/7/21 9:08 PM, olcott wrote:
>>>>>>>>> On 9/7/2021 7:42 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 9/7/2021 10:31 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/7/2021 5:54 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/6/2021 8:57 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9/6/2021 8:09 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 9/6/2021 7:40 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> TM at H^.qx is an "exact
>>>>>>>>>>>>>>>>>>>> copy" of H. How can two TMs that are exact copies of
>>>>>>>>>>>>>>>>>>>> each
>>>>>>>>>>>>>>>>>>>> other make
>>>>>>>>>>>>>>>>>>>> different transitions given the same input?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That H1 calls H means that H1 can see what H does.
>>>>>>>>>>>>>>>>>>> The H is called by H1 means that H does not even know
>>>>>>>>>>>>>>>>>>> that H1
>>>>>>>>>>>>>>>>>>> exists.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> TMs don't call each other.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ creates a master slave
>>>>>>>>>>>>>>>>> relationship
>>>>>>>>>>>>>>>>> between H and Ĥ.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The master can see exactly what the slave is doing.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The slave it totally unaware of the existence of the
>>>>>>>>>>>>>>>>> master.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The master can change its behavior on the basis of what
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> slave does.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The slave cannot change its behavior on the basis of what
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> master does.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thus the master slave relationship can and does cause an
>>>>>>>>>>>>>>>>> identical
>>>>>>>>>>>>>>>>> function with the same input to have different behavior
>>>>>>>>>>>>>>>>> even if
>>>>>>>>>>>>>>>>> no one
>>>>>>>>>>>>>>>>> ever noticed this before.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Function? Have you been only pretending to be talking
>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>>> machines the whole time? If you were not being deceitful,
>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>> H (the
>>>>>>>>>>>>>>>> TM) is wrong because
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H.q0 <H^><H^> |- H.qn
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No matter how much you ignore the fact that the master slave
>>>>>>>>>>>>>>> relationship where H is the master of Ĥ causes different
>>>>>>>>>>>>>>> behavior:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>> Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> for two identical functions with the same input, this master
>>>>>>>>>>>>>>> slave
>>>>>>>>>>>>>>> relationship still causes differing behavior.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Functions? You used the notation of Turing machines. Were
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>> being
>>>>>>>>>>>>>> deceptive? I am perfectly prepared to accept that you are
>>>>>>>>>>>>>> cheating in
>>>>>>>>>>>>>> some way with your hidden C functions, but you can't cheat
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> TMs.
>>>>>>>>>>>>>> What you said using the notation of TMs was wrong (about TMs)
>>>>>>>>>>>>>> because
>>>>>>>>>>>>>> identical state transition functions produce the same
>>>>>>>>>>>>>> transitions
>>>>>>>>>>>>>> when
>>>>>>>>>>>>>> given identical input. So your recent admission that your H
>>>>>>>>>>>>>> should
>>>>>>>>>>>>>> accept the string <H^><H^> means that
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> shows your H is wrong -- on your own terms. The facts of the
>>>>>>>>>>>>>> matter
>>>>>>>>>>>>>> come from you.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can stop posting if you admit you have been disingenuously
>>>>>>>>>>>>>> using
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> notation of TMs to talk about your dodgy C code. If you
>>>>>>>>>>>>>> want to
>>>>>>>>>>>>>> keep
>>>>>>>>>>>>>> talking about TMs you need to admit you are wrong. Identical
>>>>>>>>>>>>>> state
>>>>>>>>>>>>>> transition functions with identical inputs always generate
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> same
>>>>>>>>>>>>>> sequence of machine configurations.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So in other words you have another shortcoming in your
>>>>>>>>>>>>> technical
>>>>>>>>>>>>> knowledge this time it is directly in the field of computer
>>>>>>>>>>>>> science on
>>>>>>>>>>>>> not in related fields such as software engineering.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You seem to be unaware that the TM description being simulated
>>>>>>>>>>>>> by a
>>>>>>>>>>>>> UTM has no access to see the internal steps of its simulator
>>>>>>>>>>>>> and yet
>>>>>>>>>>>>> the UTM can directly see all of the steps of the TM
>>>>>>>>>>>>> description
>>>>>>>>>>>>> that
>>>>>>>>>>>>> it is simulating.
>>>>>>>>>>>> So you are talking about TMs after all? Please use the correct
>>>>>>>>>>>> language. TMs don't have "functions" and don't make "calls".
>>>>>>>>>>>> Identical state transition functions with identical inputs
>>>>>>>>>>>> always
>>>>>>>>>>>> generate the same sequence of machine configurations so, the
>>>>>>>>>>>> often
>>>>>>>>>>>> quoted property of your H^:
>>>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>>>> shows that your H is wrong.
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>>>>>>>>>>> OutputString("Pathological self-reference error!");
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> if (H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ != Ĥ applied to ⟨Ĥ⟩)
>>>>>>>>>>> OutputString("Pathological self-reference error!");
>>>>>>>>>>
>>>>>>>>>> You need to pay attention. I can't help you if you just put your
>>>>>>>>>> fingers in your ears and chant.
>>>>>>>>>>
>>>>>>>>>>>> ... You tell us that H should accept <H^><H^>
>>>>>>>>>>>> and you tell us that the TM at H^.qx is an "exact copy" of H
>>>>>>>>>>>> and
>>>>>>>>>>>> you
>>>>>>>>>>>> tell us that H^.qx <H^><H^> |- H^.qn. You tell us
>>>>>>>>>>>> everything we
>>>>>>>>>>>> need to
>>>>>>>>>>>> know that you are wrong. The only thing missing is an apology
>>>>>>>>>>>> from you
>>>>>>>>>>>> for ignoring these helpful explanations for so long.
>>>>>>>>>>
>>>>>>>>>> Is there anything here you don't understand? It's not hard.
>>>>>>>>>> Identical
>>>>>>>>>> state transition functions always generate the same computational
>>>>>>>>>> steps
>>>>>>>>>> when presented with the same input.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>>>>> // Strachey(1965) CPL translated to C
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>> if (H(x, x))
>>>>>>>>> HERE: goto HERE;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> When the exact analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>> int main() { H1(P,P); } is examined
>>>>>>>>>
>>>>>>>>> When code of the x86 H1 and H is identical and their input is the
>>>>>>>>> same
>>>>>>>>> yet their behavior is different then we know that something is up.
>>>>>>>>>
>>>>>>>>> When we examine actual fully operational code we can't simply
>>>>>>>>> assume
>>>>>>>>> that we imagined the behavior incorrectly.
>>>>>>>>>
>>>>>>>>> That only leaves the code and the input. The input is the same
>>>>>>>>> 32-bit
>>>>>>>>> integer, that only leaves the code.
>>>>>>>>>
>>>>>>>>> It turns out that the most plausible explanation is that the code
>>>>>>>>> is not
>>>>>>>>> the same. The master / slave relationship between H1/H and H/Ĥ is
>>>>>>>>> hard
>>>>>>>>> coded into the full H1/H and H/Ĥ computations.
>>>>>>>>>
>>>>>>>>> The fact that:
>>>>>>>>> H1 simulates P that simulates H(P,P)
>>>>>>>>> H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ that simulates ⟨Ĥ⟩ ⟨Ĥ⟩ at Ĥ.qx
>>>>>>>>>
>>>>>>>>> hard codes the master / slave relationships between H1/H and H/Ĥ.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Just means that the code does not code an actual Computation, but
>>>>>>>> somewhere is using data that is NOT part of its formal input to
>>>>>>>> make
>>>>>>>> the
>>>>>>>> decision.
>>>>>>>>
>>>>>>>
>>>>>>> If the code is identical and the input is identical then the
>>>>>>> behavior
>>>>>>> must be identical. If the code is not identical and the input is
>>>>>>> identical then the behavior need not be identical.
>>>>>>>
>>>>>>> Different code with the same input can derive different results as a
>>>>>>> pure function of this input.
>>>>>>>
>>>>>>
>>>>>> So you admit that they have different code?
>>>>>>
>>>>>> I thought your claim was that H and H1 had identical code.
>>>>>>
>>>>>
>>>>> int main() { H1(P,P); } specifies that H1 is in a master slave
>>>>> relationship with H(P,P) even though H1 and H have identical code.
>>>>>
>>>>> The master / slave relationship specified in main() defines H1 as a
>>>>> distinctly different computation than H.
>>>>>
>>>>> The exact same thing works in reverse.
>>>>> int main() { H(P,P); } that simulates P the calls H1...
>>>>
>>>> If H1 and H have the same code and get the same input then they MUST
>>>> behave the same. That is FUNDAMENTAL to how computers work.
>>>>
>>>
>>> int main() { H1(P,P); } simulates P that calls H(P,P)
>>> makes H1(P,P) a different computation than H(P,P).
>>>
>>> The functions H and H1 behave differently when invoked with inputs that
>>> refer to themselves than when their inputs do not refer to themselves.
>>
>> No, there MUST be either a DIFFERNCE between the two programs, or the
>> programs are not Computations of their defined inputs, but have so other
>> input.
>
> It is simply a matter of H1/H1 or H/H does not see anyone else doing the
> work of aborting the simulation of its input so it must do this work.
>
> The H1 of H1/H sees that its input halts.
> The H1 of H1/H1 sees that its input never halts.
>
> The H of H1/H sees that its input never halts.
> The H of H/H sees that its input never halts.
>
> Here is the H1/H scenario in complete detail:
> The master UTM / halt decider H1 can see everything that it simulates:
> (a) P begins
> (b) P calls H(P,P)
> (c) H returns to P
> (d) P returns to main() where it was simulated by H1.
>
> The master UTM / halt decider H can see everything that it simulates:
> (a) P begins
> (b) P calls H(P,P)
> (c) P begins
> (e) P calls H(P,P)
>
> H(P,P) sees that it must abort its simulation of its input or its input
> never halts.
>
SO why did H1 see H abort its simulation and return the answer, while H
USING THE EXACT SAME CODE, didn't see that return.
H ignored H, but H1 didn't ignore H. That is a difference. Why?
Because that aren't the exact same machines.
If you look at that point of diffence, you will see the difference, and
it isn't part of the offical input, so either the machines are different
or they aren't Computations.
PERIOD.
FAIL
[toc] | [prev] | [next] | [standalone]
Page 34 of 37 — ← Prev page 1 … 32 33 [34] 35 36 37 Next page →
Back to top | Article view | comp.theory
csiph-web