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 35 of 37 — ← Prev page 1 … 33 34 [35] 36 37 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-07 22:33 -0400 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <JhVZI.73960$Kv2.34888@fx47.iad> |
| In reply to | #39115 |
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...
So either this 'master / slave relationship' is code that makes them not
the same machine, or it shows that they aren't actually a Computation (I
think the latter).
If they aren't the same machine, the fact that H1 can decided H^ (the P
based on H) doesn't mean anything as does that H can decided H1^ (the P
based on H1) as Linz only claims that a given Hat machine will confound
the decider it was built on.
If you try to claim they are the same machine, then their different
output from the same input proves that they arent actually a
Computation, and thus not really the Computational Equivalent to a
Turing Machine, so the can't be a real Halt Decider.
FAIL.
You just don't understand what it means to be a Computation, and thus
what can be a Halt Decider.
>
>> 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-09-08 03:55 +0100 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <87o893epxp.fsf@bsb.me.uk> |
| In reply to | #39105 |
olcott <NoOne@NoWhere.com> writes:
> 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:
>>>> ... 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
If your analogy does not match the facts I stated about TMs then it's
wrong. Does it conform that H <H^><H^> and H^.qx <H^><H^> both
transition to the corresponding rejecting states, H.qn and H^.qn? If
so, a simple "thanks, Ben, I was wrong" would do. If not, throw the
analogy away because it's misleading you.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-07 22:07 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <GaadnTn-QNpHtaX8nZ2dnUU7-IfNnZ2d@giganews.com> |
| In reply to | #39120 |
On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> 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:
>
>>>>> ... 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
>
> If your analogy does not match the facts I stated about TMs then it's
> wrong.
Identical code with identical inputs must derive identical results.
> Does it conform that H <H^><H^> and H^.qx <H^><H^> both
> transition to the corresponding rejecting states, H.qn and H^.qn? If
> so, a simple "thanks, Ben, I was wrong" would do. If not, throw the
> analogy away because it's misleading you.
>
// 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 = ", H1((u32)P, (u32)P));
}
As I just explained to Richard my x86 halt decider / emulators behave
differently when their input refer to themselves than when their input
does not refer to themselves.
This is why H1(P,P) is a halt decider for its input and
H ⟨Ĥ⟩ ⟨Ĥ⟩ is a halt decider for its input.
// 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!");
}
--
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 07:09 -0400 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <UR0_I.4698$mg5.3267@fx26.iad> |
| In reply to | #39122 |
On 9/7/21 11:07 PM, olcott wrote:
> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> 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:
>>
>>>>>> ... 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
>>
>> If your analogy does not match the facts I stated about TMs then it's
>> wrong.
>
> Identical code with identical inputs must derive identical results.
>
>> Does it conform that H <H^><H^> and H^.qx <H^><H^> both
>> transition to the corresponding rejecting states, H.qn and H^.qn? If
>> so, a simple "thanks, Ben, I was wrong" would do. If not, throw the
>> analogy away because it's misleading you.
>>
>
> // 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 = ", H1((u32)P, (u32)P));
> }
>
> As I just explained to Richard my x86 halt decider / emulators behave
> differently when their input refer to themselves than when their input
> does not refer to themselves.
>
> This is why H1(P,P) is a halt decider for its input and
> H ⟨Ĥ⟩ ⟨Ĥ⟩ is a halt decider for its input.
And identical instruction sequences with identical data will always
produce the exact same results, so somewhere you are lying.
H and H1 need to have SOMETHING that makes them different in order for
them to behave differently.
Either they are the same algorithm with different inputs or different
algorithms. Since you claim that they are the same algorithm with same
inputs, that MUST be a lie.
That, or your computer is broken.
>
> // 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!");
> }
>
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-09-08 15:58 +0100 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <877dfrdshl.fsf@bsb.me.uk> |
| In reply to | #39122 |
olcott <NoOne@NoWhere.com> writes:
> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> 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:
>>
>>>>>> ... 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
>> If your analogy does not match the facts I stated about TMs then it's
>> wrong.
>
> Identical code with identical inputs must derive identical results.
No. That is obviously not true, except for some very rare languages
that you probably don't know. A big part of the reason people work with
TMs is to avoid all the mess you can get into with real code. Come
clean: when you write lines that appear to about TMs are you really
talking about code? If so you should stop abusing the notation. It's
about TMs and not C or x86 code of whatever the flavour is today.
>> Does it conform that H <H^><H^> and H^.qx <H^><H^> both
>> transition to the corresponding rejecting states, H.qn and H^.qn? If
>> so, a simple "thanks, Ben, I was wrong" would do. If not, throw the
>> analogy away because it's misleading you.
So which it is? Does your code analogy agree with the facts about TMs,
thereby showing you that your H is wrong, or should you just throw it
way because it is not applicable?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-08 14:08 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <HfOdnd8-8ciul6T8nZ2dnUU7-VHNnZ2d@giganews.com> |
| In reply to | #39136 |
On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> 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:
>>>
>>>>>>> ... 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
>>> If your analogy does not match the facts I stated about TMs then it's
>>> wrong.
>>
>> Identical code with identical inputs must derive identical results.
>
> No. That is obviously not true, except for some very rare languages
> that you probably don't know.
At this point I would estimate that your technical competence is much
lower that I had assumed. I would ask you to provide a concrete example
and would estimate that you would dodge thus sufficiently proving that
your technical competence is very likely much lower that I had assumed.
> A big part of the reason people work with
> TMs is to avoid all the mess you can get into with real code. Come
> clean: when you write lines that appear to about TMs are you really
> talking about code? If so you should stop abusing the notation. It's
> about TMs and not C or x86 code of whatever the flavour is today.
>
>>> Does it conform that H <H^><H^> and H^.qx <H^><H^> both
>>> transition to the corresponding rejecting states, H.qn and H^.qn? If
>>> so, a simple "thanks, Ben, I was wrong" would do. If not, throw the
>>> analogy away because it's misleading you.
>
> So which it is? Does your code analogy agree with the facts about TMs,
> thereby showing you that your H is wrong, or should you just throw it
> way because it is not applicable?
>
--
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-08 21:42 +0100 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <87mtomdcjv.fsf@bsb.me.uk> |
| In reply to | #39145 |
olcott <NoOne@NoWhere.com> writes:
> On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> 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:
>>>>
>>>>>>>> ... 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
>>>> If your analogy does not match the facts I stated about TMs then it's
>>>> wrong.
>>>
>>> Identical code with identical inputs must derive identical results.
>>
>> No. That is obviously not true, except for some very rare languages
>> that you probably don't know.
>
> At this point I would estimate that your technical competence is much
> lower that I had assumed. I would ask you to provide a concrete
> example and would estimate that you would dodge thus sufficiently
> proving that your technical competence is very likely much lower that
> I had assumed.
As you know, whether I am right or not has nothing to do with either my
competence or your opinion of it. TMs are not "code". Code can do IO,
use static objects, examine its execution environment and so on. A lot
of x86 code even has access to hardware-generated random numbers. You
know this.
If you want to talk code, stop using the notation for TM configurations.
If you want to talk TMs, you will have to face the fact that you are
wrong.
>>>> Does it conform that H <H^><H^> and H^.qx <H^><H^> both
>>>> transition to the corresponding rejecting states, H.qn and H^.qn? If
>>>> so, a simple "thanks, Ben, I was wrong" would do. If not, throw the
>>>> analogy away because it's misleading you.
>>
>> So which it is? Does your code analogy agree with the facts about TMs,
>> thereby showing you that your H is wrong, or should you just throw it
>> [away] because it is not applicable?
So?
You keep flip-flopping about all of this. You write formal TM
configurations but when the obvious error is pointed out you flip to
your never-published C code. Then you flip back and say the two are
analogous, but when that fails you pull the old "you are incompetent"
line from the crank playbook. The only way you can be right about TMs
is, I think, to stop talking about them altogether. Learning about them
seems not to be an option.
It is a mark of respect to be considered incompetent by you. Thank you.
It means the case put to you is so string you have no more to say. What
you've been supposedly saying about TMs is so obviously wrong, all you
have left is this non-argument.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-08 15:53 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <7tKdnfOSF5lIv6T8nZ2dnUU7-QnNnZ2d@giganews.com> |
| In reply to | #39152 |
On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> 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:
>>>>>
>>>>>>>>> ... 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
>>>>> If your analogy does not match the facts I stated about TMs then it's
>>>>> wrong.
>>>>
>>>> Identical code with identical inputs must derive identical results.
>>>
>>> No. That is obviously not true, except for some very rare languages
>>> that you probably don't know.
>>
>> At this point I would estimate that your technical competence is much
>> lower that I had assumed. I would ask you to provide a concrete
>> example and would estimate that you would dodge thus sufficiently
>> proving that your technical competence is very likely much lower that
>> I had assumed.
>
> As you know, whether I am right or not has nothing to do with either my
> competence or your opinion of it. TMs are not "code". Code can do IO,
> use static objects, examine its execution environment and so on. A lot
> of x86 code even has access to hardware-generated random numbers. You
> know this.
>
> If you want to talk code, stop using the notation for TM configurations.
> If you want to talk TMs, you will have to face the fact that you are
> wrong.
>
So like I said you simply dodged supporting your obviously incorrect
rebuttal that identical code (sequences of state transitions) cannot
derive different results from the same input.
>>>>> Does it conform that H <H^><H^> and H^.qx <H^><H^> both
>>>>> transition to the corresponding rejecting states, H.qn and H^.qn? If
>>>>> so, a simple "thanks, Ben, I was wrong" would do. If not, throw the
>>>>> analogy away because it's misleading you.
>>>
>>> So which it is? Does your code analogy agree with the facts about TMs,
>>> thereby showing you that your H is wrong, or should you just throw it
>>> [away] because it is not applicable?
>
> So?
>
> You keep flip-flopping about all of this. You write formal TM
> configurations but when the obvious error is pointed out you flip to
> your never-published C code. Then you flip back and say the two are
> analogous, but when that fails you pull the old "you are incompetent"
> line from the crank playbook. The only way you can be right about TMs
> is, I think, to stop talking about them altogether. Learning about them
> seems not to be an option.
>
> It is a mark of respect to be considered incompetent by you. Thank you.
> It means the case put to you is so string you have no more to say. What
> you've been supposedly saying about TMs is so obviously wrong, all you
> have left is this non-argument.
>
--
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-08 23:52 +0100 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <87bl52d6jb.fsf@bsb.me.uk> |
| In reply to | #39154 |
olcott <NoOne@NoWhere.com> writes:
> On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> 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:
>>>>>>
>>>>>>>>>> ... 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
>>>>>> If your analogy does not match the facts I stated about TMs then it's
>>>>>> wrong.
>>>>>
>>>>> Identical code with identical inputs must derive identical results.
>>>>
>>>> No. That is obviously not true, except for some very rare languages
>>>> that you probably don't know.
>>>
>>> At this point I would estimate that your technical competence is much
>>> lower that I had assumed. I would ask you to provide a concrete
>>> example and would estimate that you would dodge thus sufficiently
>>> proving that your technical competence is very likely much lower that
>>> I had assumed.
>>
>> As you know, whether I am right or not has nothing to do with either my
>> competence or your opinion of it. TMs are not "code". Code can do IO,
>> use static objects, examine its execution environment and so on. A lot
>> of x86 code even has access to hardware-generated random numbers. You
>> know this.
>>
>> If you want to talk code, stop using the notation for TM configurations.
>> If you want to talk TMs, you will have to face the fact that you are
>> wrong.
>
> So like I said you simply dodged supporting your obviously incorrect
> rebuttal that identical code (sequences of state transitions) cannot
> derive different results from the same input.
Code is not a "sequence of state transitions", and TMs don't "derive
results" (they accept, reject or fail to halt), but I don't want to get
sucked into your bad wording.
The state transition function of H and that at H^.qx are the same
because one TM is an exact copy of the other (your words). The "inputs"
(what you should call the tape) and the position of the tape head are
also the same. The computations must evolve along exactly the same
lines.
Writing it out formally is unlikely to help because the argument needs a
mapping between the states of H and H^ and I suspect that explaining
that would either take months, or you'd declare it "extraneous" and
refuse to even consider it. There's another way, but that involves a
slight variation in the construction and you don't like such changes.
There comes a point where no more clarity is available to you. If you
don't know by now that the same transition function, operating on the
same configuration can't result in transitions to different states, I
don't think there is any hope that you ever will. I think you are
doomed to be wrong and not know it, but if you think some more
explanation might help, ask away.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-08 18:10 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <rcKdne_RV4dp36T8nZ2dnUU7-cPNnZ2d@giganews.com> |
| In reply to | #39161 |
On 9/8/2021 5:52 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> 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:
>>>>>>>
>>>>>>>>>>> ... 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
>>>>>>> If your analogy does not match the facts I stated about TMs then it's
>>>>>>> wrong.
>>>>>>
>>>>>> Identical code with identical inputs must derive identical results.
>>>>>
>>>>> No. That is obviously not true, except for some very rare languages
>>>>> that you probably don't know.
>>>>
>>>> At this point I would estimate that your technical competence is much
>>>> lower that I had assumed. I would ask you to provide a concrete
>>>> example and would estimate that you would dodge thus sufficiently
>>>> proving that your technical competence is very likely much lower that
>>>> I had assumed.
>>>
>>> As you know, whether I am right or not has nothing to do with either my
>>> competence or your opinion of it. TMs are not "code". Code can do IO,
>>> use static objects, examine its execution environment and so on. A lot
>>> of x86 code even has access to hardware-generated random numbers. You
>>> know this.
>>>
>>> If you want to talk code, stop using the notation for TM configurations.
>>> If you want to talk TMs, you will have to face the fact that you are
>>> wrong.
>>
>> So like I said you simply dodged supporting your obviously incorrect
>> rebuttal that identical code (sequences of state transitions) cannot
>> derive different results from the same input.
>
> Code is not a "sequence of state transitions", and TMs don't "derive
> results" (they accept, reject or fail to halt), but I don't want to get
> sucked into your bad wording.
>
> The state transition function of H and that at H^.qx are the same
> because one TM is an exact copy of the other (your words). The "inputs"
> (what you should call the tape) and the position of the tape head are
> also the same. The computations must evolve along exactly the same
> lines.
>
This would seem intuitive yet false.
If we look at it at the very high level of abstraction we can comprehend
that simulating halt decider H need not abort the simulation of its
input because the simulating halt decider at Ĥ.qx does abort the
simulation of its input.
// 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 = ", H1((u32)P, (u32)P));
}
People that actually understand the C/x86 language will see that
simulating halt decider H1(P,P) need not abort the simulation of its
input because the execution trace of its input shows that its simulation
of P halts.
When we have two different halt deciders that must coordinate with each
other it was initially difficult to see the exact execution trace that
H1 and H used as their basis. I created a debug function that output
this full trace immediately before H1/H terminates.
H sees that its input never halts:
Output_Decoded_Instructions() [0025c7fd] size(336) capacity(240000)
[00001026][0025c7e9][0025c7ed] 55 push ebp
[00001027][0025c7e9][0025c7ed] 8bec mov ebp,esp // P begins
[00001029][0025c7e9][0025c7ed] 8b4508 mov eax,[ebp+08]
[0000102c][0025c7e5][00001026] 50 push eax
[0000102d][0025c7e5][00001026] 8b4d08 mov ecx,[ebp+08]
[00001030][0025c7e1][00001026] 51 push ecx
[00001031][0025c7dd][00001036] e8d0fdffff call 00000e06 // call H(P,P)
[00001026][002a7211][002a7215] 55 push ebp // P begins
[00001027][002a7211][002a7215] 8bec mov ebp,esp
[00001029][002a7211][002a7215] 8b4508 mov eax,[ebp+08]
[0000102c][002a720d][00001026] 50 push eax
[0000102d][002a720d][00001026] 8b4d08 mov ecx,[ebp+08]
[00001030][002a7209][00001026] 51 push ecx
[00001031][002a7205][00001036] e8d0fdffff call 00000e06 // call H(P,P)
END---Output_Decoded_Instructions(0025c7fd)
H1 simply sees that its simulated input halts:
Output_Decoded_Instructions() [00211dd5] size(288) capacity(240000)
[00001026][00211dc1][00211dc5] 55 push ebp // P begins
[00001027][00211dc1][00211dc5] 8bec mov ebp,esp
[00001029][00211dc1][00211dc5] 8b4508 mov eax,[ebp+08]
[0000102c][00211dbd][00001026] 50 push eax
[0000102d][00211dbd][00001026] 8b4d08 mov ecx,[ebp+08]
[00001030][00211db9][00001026] 51 push ecx
[00001031][00211db5][00001036] e8d0fdffff call 00000e06 // call H(P,P)
[00001036][00211dc1][00211dc5] 83c408 add esp,+08 // return to P
[00001039][00211dc1][00211dc5] 85c0 test eax,eax
[0000103b][00211dc1][00211dc5] 7402 jz 0000103f
[0000103f][00211dc5][00000cde] 5d pop ebp
[00001040][00211dc9][00001026] c3 ret // P halts
END---Output_Decoded_Instructions(00211dd5)
> Writing it out formally is unlikely to help because the argument needs a
> mapping between the states of H and H^ and I suspect that explaining
> that would either take months, or you'd declare it "extraneous" and
> refuse to even consider it. There's another way, but that involves a
> slight variation in the construction and you don't like such changes.
>
> There comes a point where no more clarity is available to you. If you
> don't know by now that the same transition function, operating on the
> same configuration can't result in transitions to different states, I
> don't think there is any hope that you ever will. I think you are
> doomed to be wrong and not know it, but if you think some more
> explanation might help, ask away.
>
--
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:11 -0400 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <tic_I.43704$%Z2.14596@fx06.iad> |
| In reply to | #39162 |
On 9/8/21 7:10 PM, olcott wrote:
> On 9/8/2021 5:52 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> 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:
>>>>>>>>
>>>>>>>>>>>> ... 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
>>>>>>>> If your analogy does not match the facts I stated about TMs then
>>>>>>>> it's
>>>>>>>> wrong.
>>>>>>>
>>>>>>> Identical code with identical inputs must derive identical results.
>>>>>>
>>>>>> No. That is obviously not true, except for some very rare languages
>>>>>> that you probably don't know.
>>>>>
>>>>> At this point I would estimate that your technical competence is much
>>>>> lower that I had assumed. I would ask you to provide a concrete
>>>>> example and would estimate that you would dodge thus sufficiently
>>>>> proving that your technical competence is very likely much lower that
>>>>> I had assumed.
>>>>
>>>> As you know, whether I am right or not has nothing to do with either my
>>>> competence or your opinion of it. TMs are not "code". Code can do IO,
>>>> use static objects, examine its execution environment and so on. A lot
>>>> of x86 code even has access to hardware-generated random numbers. You
>>>> know this.
>>>>
>>>> If you want to talk code, stop using the notation for TM
>>>> configurations.
>>>> If you want to talk TMs, you will have to face the fact that you are
>>>> wrong.
>>>
>>> So like I said you simply dodged supporting your obviously incorrect
>>> rebuttal that identical code (sequences of state transitions) cannot
>>> derive different results from the same input.
>>
>> Code is not a "sequence of state transitions", and TMs don't "derive
>> results" (they accept, reject or fail to halt), but I don't want to get
>> sucked into your bad wording.
>>
>> The state transition function of H and that at H^.qx are the same
>> because one TM is an exact copy of the other (your words). The "inputs"
>> (what you should call the tape) and the position of the tape head are
>> also the same. The computations must evolve along exactly the same
>> lines.
>>
>
> This would seem intuitive yet false.
>
> If we look at it at the very high level of abstraction we can comprehend
> that simulating halt decider H need not abort the simulation of its
> input because the simulating halt decider at Ĥ.qx does abort the
> simulation of its input.
It may not NEED to, but because it has the exact same instructions, it
WILL, and the fact that it didn't actually NEED to is why it is wrong.
Your failure is that you think code can just decide to what it rignt,
when it actually just has to do what is was instructed to do.
You just don't understand what programming actually is.
>
> // 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 = ", H1((u32)P, (u32)P));
> }
>
> People that actually understand the C/x86 language will see that
> simulating halt decider H1(P,P) need not abort the simulation of its
> input because the execution trace of its input shows that its simulation
> of P halts.
But if H1 has the same code as H, it WILL do the same thing. The fact
that it does something different shows that it is in fact different.
It also shows that H actually didn't need to abort its simulation
either, because the next layer of H will abort and make the P that it is
simulating halting.
But, H is caught in the trap that it has to do what its instruction says
it will do, and that is abort the simulation too soon and make a mistake.
>
> When we have two different halt deciders that must coordinate with each
> other it was initially difficult to see the exact execution trace that
> H1 and H used as their basis. I created a debug function that output
> this full trace immediately before H1/H terminates.
Ok, so you now ADMIT that they are different! Thus H1 actually helps
PROVE that H was wrong, and thus Linz is confirmed (since P was built on
H, that is the decider that must get it right).
>
> H sees that its input never halts:
> Output_Decoded_Instructions() [0025c7fd] size(336) capacity(240000)
> [00001026][0025c7e9][0025c7ed] 55 push ebp
> [00001027][0025c7e9][0025c7ed] 8bec mov ebp,esp // P begins
> [00001029][0025c7e9][0025c7ed] 8b4508 mov eax,[ebp+08]
> [0000102c][0025c7e5][00001026] 50 push eax
> [0000102d][0025c7e5][00001026] 8b4d08 mov ecx,[ebp+08]
> [00001030][0025c7e1][00001026] 51 push ecx
> [00001031][0025c7dd][00001036] e8d0fdffff call 00000e06 // call H(P,P)
> [00001026][002a7211][002a7215] 55 push ebp // P begins
> [00001027][002a7211][002a7215] 8bec mov ebp,esp
> [00001029][002a7211][002a7215] 8b4508 mov eax,[ebp+08]
> [0000102c][002a720d][00001026] 50 push eax
> [0000102d][002a720d][00001026] 8b4d08 mov ecx,[ebp+08]
> [00001030][002a7209][00001026] 51 push ecx
> [00001031][002a7205][00001036] e8d0fdffff call 00000e06 // call H(P,P)
> END---Output_Decoded_Instructions(0025c7fd)
>
>
> H1 simply sees that its simulated input halts:
> Output_Decoded_Instructions() [00211dd5] size(288) capacity(240000)
> [00001026][00211dc1][00211dc5] 55 push ebp // P begins
> [00001027][00211dc1][00211dc5] 8bec mov ebp,esp
> [00001029][00211dc1][00211dc5] 8b4508 mov eax,[ebp+08]
> [0000102c][00211dbd][00001026] 50 push eax
> [0000102d][00211dbd][00001026] 8b4d08 mov ecx,[ebp+08]
> [00001030][00211db9][00001026] 51 push ecx
> [00001031][00211db5][00001036] e8d0fdffff call 00000e06 // call H(P,P)
> [00001036][00211dc1][00211dc5] 83c408 add esp,+08 // return to P
> [00001039][00211dc1][00211dc5] 85c0 test eax,eax
> [0000103b][00211dc1][00211dc5] 7402 jz 0000103f
> [0000103f][00211dc5][00000cde] 5d pop ebp
> [00001040][00211dc9][00001026] c3 ret // P halts
> END---Output_Decoded_Instructions(00211dd5)
>
>
>> Writing it out formally is unlikely to help because the argument needs a
>> mapping between the states of H and H^ and I suspect that explaining
>> that would either take months, or you'd declare it "extraneous" and
>> refuse to even consider it. There's another way, but that involves a
>> slight variation in the construction and you don't like such changes.
>>
>> There comes a point where no more clarity is available to you. If you
>> don't know by now that the same transition function, operating on the
>> same configuration can't result in transitions to different states, I
>> don't think there is any hope that you ever will. I think you are
>> doomed to be wrong and not know it, but if you think some more
>> explanation might help, ask away.
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-09-09 01:21 +0100 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <8735qed2f4.fsf@bsb.me.uk> |
| In reply to | #39162 |
olcott <NoOne@NoWhere.com> writes:
> On 9/8/2021 5:52 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> 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:
>>>>>>>>
>>>>>>>>>>>> ... 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
>>>>>>>> If your analogy does not match the facts I stated about TMs then it's
>>>>>>>> wrong.
>>>>>>>
>>>>>>> Identical code with identical inputs must derive identical results.
>>>>>>
>>>>>> No. That is obviously not true, except for some very rare languages
>>>>>> that you probably don't know.
>>>>>
>>>>> At this point I would estimate that your technical competence is much
>>>>> lower that I had assumed. I would ask you to provide a concrete
>>>>> example and would estimate that you would dodge thus sufficiently
>>>>> proving that your technical competence is very likely much lower that
>>>>> I had assumed.
>>>>
>>>> As you know, whether I am right or not has nothing to do with either my
>>>> competence or your opinion of it. TMs are not "code". Code can do IO,
>>>> use static objects, examine its execution environment and so on. A lot
>>>> of x86 code even has access to hardware-generated random numbers. You
>>>> know this.
>>>>
>>>> If you want to talk code, stop using the notation for TM configurations.
>>>> If you want to talk TMs, you will have to face the fact that you are
>>>> wrong.
>>>
>>> So like I said you simply dodged supporting your obviously incorrect
>>> rebuttal that identical code (sequences of state transitions) cannot
>>> derive different results from the same input.
>>
>> Code is not a "sequence of state transitions", and TMs don't "derive
>> results" (they accept, reject or fail to halt), but I don't want to get
>> sucked into your bad wording.
>>
>> The state transition function of H and that at H^.qx are the same
>> because one TM is an exact copy of the other (your words). The "inputs"
>> (what you should call the tape) and the position of the tape head are
>> also the same. The computations must evolve along exactly the same
>> lines.
>
> This would seem intuitive yet false.
Its a fact.
> If we look at it at the very high level of abstraction we can
> comprehend that simulating halt decider H need not abort the
> simulation of its input because the simulating halt decider at Ĥ.qx
> does abort the simulation of its input.
The identical "machines" at H.q0 and H^.qx must perform exactly the same
steps when presented with the same tape contents. H must transition to
qn because H^.qx <H^><H^> does.
>> Writing it out formally is unlikely to help because the argument needs a
>> mapping between the states of H and H^ and I suspect that explaining
>> that would either take months, or you'd declare it "extraneous" and
>> refuse to even consider it. There's another way, but that involves a
>> slight variation in the construction and you don't like such changes.
>>
>> There comes a point where no more clarity is available to you. If you
>> don't know by now that the same transition function, operating on the
>> same configuration can't result in transitions to different states, I
>> don't think there is any hope that you ever will. I think you are
>> doomed to be wrong and not know it, but if you think some more
>> explanation might help, ask away.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-08 19:37 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <RrqdnQyyOJupyqT8nZ2dnUU7-fnNnZ2d@giganews.com> |
| In reply to | #39173 |
On 9/8/2021 7:21 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 9/8/2021 5:52 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> 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:
>>>>>>>>>
>>>>>>>>>>>>> ... 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
>>>>>>>>> If your analogy does not match the facts I stated about TMs then it's
>>>>>>>>> wrong.
>>>>>>>>
>>>>>>>> Identical code with identical inputs must derive identical results.
>>>>>>>
>>>>>>> No. That is obviously not true, except for some very rare languages
>>>>>>> that you probably don't know.
>>>>>>
>>>>>> At this point I would estimate that your technical competence is much
>>>>>> lower that I had assumed. I would ask you to provide a concrete
>>>>>> example and would estimate that you would dodge thus sufficiently
>>>>>> proving that your technical competence is very likely much lower that
>>>>>> I had assumed.
>>>>>
>>>>> As you know, whether I am right or not has nothing to do with either my
>>>>> competence or your opinion of it. TMs are not "code". Code can do IO,
>>>>> use static objects, examine its execution environment and so on. A lot
>>>>> of x86 code even has access to hardware-generated random numbers. You
>>>>> know this.
>>>>>
>>>>> If you want to talk code, stop using the notation for TM configurations.
>>>>> If you want to talk TMs, you will have to face the fact that you are
>>>>> wrong.
>>>>
>>>> So like I said you simply dodged supporting your obviously incorrect
>>>> rebuttal that identical code (sequences of state transitions) cannot
>>>> derive different results from the same input.
>>>
>>> Code is not a "sequence of state transitions", and TMs don't "derive
>>> results" (they accept, reject or fail to halt), but I don't want to get
>>> sucked into your bad wording.
>>>
>>> The state transition function of H and that at H^.qx are the same
>>> because one TM is an exact copy of the other (your words). The "inputs"
>>> (what you should call the tape) and the position of the tape head are
>>> also the same. The computations must evolve along exactly the same
>>> lines.
>>
>> This would seem intuitive yet false.
>
> Its a fact.
>
>> If we look at it at the very high level of abstraction we can
>> comprehend that simulating halt decider H need not abort the
>> simulation of its input because the simulating halt decider at Ĥ.qx
>> does abort the simulation of its input.
>
> The identical "machines" at H.q0 and H^.qx must perform exactly the same
> steps when presented with the same tape contents. H must transition to
> qn because H^.qx <H^><H^> does.
>
When one machine is called with an input that refers to its own machine
description and another machine is called with an input that does not
refer to its own machine description then the two computations are not
the same even if their machine descriptions may be otherwise identical.
I have empirical proof of this otherwise I may have not noticed this
myself. The execution trace that H derives of its input ⟨Ĥ⟩ ⟨Ĥ⟩ shows
that Ĥ.qx transitions to Ĥ.qn
The execution trace that Ĥ.qx derives of its input ⟨Ĥ⟩ ⟨Ĥ⟩ shows that
its input never halts.
As Richard aptly pointed out this shows that the system is inconsistent.
This particular inconsistency becomes a pathological self-reference
(Olcott 2004) decider refuting Rice's Theorem.
>>> Writing it out formally is unlikely to help because the argument needs a
>>> mapping between the states of H and H^ and I suspect that explaining
>>> that would either take months, or you'd declare it "extraneous" and
>>> refuse to even consider it. There's another way, but that involves a
>>> slight variation in the construction and you don't like such changes.
>>>
>>> There comes a point where no more clarity is available to you. If you
>>> don't know by now that the same transition function, operating on the
>>> same configuration can't result in transitions to different states, I
>>> don't think there is any hope that you ever will. I think you are
>>> doomed to be wrong and not know it, but if you think some more
>>> explanation might help, ask away.
>
>
--
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 21:30 -0400 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <Rsd_I.33607$tG6.25097@fx39.iad> |
| In reply to | #39177 |
On 9/8/21 8:37 PM, olcott wrote:
> On 9/8/2021 7:21 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 9/8/2021 5:52 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> 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:
>>>>>>>>>>
>>>>>>>>>>>>>> ... 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
>>>>>>>>>> If your analogy does not match the facts I stated about TMs
>>>>>>>>>> then it's
>>>>>>>>>> wrong.
>>>>>>>>>
>>>>>>>>> Identical code with identical inputs must derive identical
>>>>>>>>> results.
>>>>>>>>
>>>>>>>> No. That is obviously not true, except for some very rare
>>>>>>>> languages
>>>>>>>> that you probably don't know.
>>>>>>>
>>>>>>> At this point I would estimate that your technical competence is
>>>>>>> much
>>>>>>> lower that I had assumed. I would ask you to provide a concrete
>>>>>>> example and would estimate that you would dodge thus sufficiently
>>>>>>> proving that your technical competence is very likely much lower
>>>>>>> that
>>>>>>> I had assumed.
>>>>>>
>>>>>> As you know, whether I am right or not has nothing to do with
>>>>>> either my
>>>>>> competence or your opinion of it. TMs are not "code". Code can
>>>>>> do IO,
>>>>>> use static objects, examine its execution environment and so on.
>>>>>> A lot
>>>>>> of x86 code even has access to hardware-generated random numbers.
>>>>>> You
>>>>>> know this.
>>>>>>
>>>>>> If you want to talk code, stop using the notation for TM
>>>>>> configurations.
>>>>>> If you want to talk TMs, you will have to face the fact that you are
>>>>>> wrong.
>>>>>
>>>>> So like I said you simply dodged supporting your obviously incorrect
>>>>> rebuttal that identical code (sequences of state transitions) cannot
>>>>> derive different results from the same input.
>>>>
>>>> Code is not a "sequence of state transitions", and TMs don't "derive
>>>> results" (they accept, reject or fail to halt), but I don't want to get
>>>> sucked into your bad wording.
>>>>
>>>> The state transition function of H and that at H^.qx are the same
>>>> because one TM is an exact copy of the other (your words). The
>>>> "inputs"
>>>> (what you should call the tape) and the position of the tape head are
>>>> also the same. The computations must evolve along exactly the same
>>>> lines.
>>>
>>> This would seem intuitive yet false.
>>
>> Its a fact.
>>
>>> If we look at it at the very high level of abstraction we can
>>> comprehend that simulating halt decider H need not abort the
>>> simulation of its input because the simulating halt decider at Ĥ.qx
>>> does abort the simulation of its input.
>>
>> The identical "machines" at H.q0 and H^.qx must perform exactly the same
>> steps when presented with the same tape contents. H must transition to
>> qn because H^.qx <H^><H^> does.
>>
>
> When one machine is called with an input that refers to its own machine
> description and another machine is called with an input that does not
> refer to its own machine description then the two computations are not
> the same even if their machine descriptions may be otherwise identical.
But if H and H1 are copies of each other, why aren't there descriptions
the same? I think this shows that H1 isn't really a copy of H, or maybe
it is that H isn't a Computatation, and thus there isn't a 'Turing
Machine Equivalent Description' since it doesn't have a Turing Machine
Equivalent.
>
> I have empirical proof of this otherwise I may have not noticed this
> myself. The execution trace that H derives of its input ⟨Ĥ⟩ ⟨Ĥ⟩ shows
> that Ĥ.qx transitions to Ĥ.qn
>
> The execution trace that Ĥ.qx derives of its input ⟨Ĥ⟩ ⟨Ĥ⟩ shows that
> its input never halts.
And the point where those traces diverge shows what is different betwen
the two machienes.
Since H^ is supposed to have an EXACT copy of H, (except for a small
edit in the qy state that we don't get to), it shows that you built H^
wrong, or maybe that you can't actually express your H as a Turing
Machine because it isn't actually a Computation, and thus there isn't a
Turing Machine Equivalent for it.
>
> As Richard aptly pointed out this shows that the system is inconsistent.
> This particular inconsistency becomes a pathological self-reference
> (Olcott 2004) decider refuting Rice's Theorem.
No, it shows that *YOUR* LOGIC SYSTEM is inconsistent, and thus can't be
used for any meaningful proof, as a logic system that is inconsistent
can prove ANY statement, whether True of False.
The 'system' in Computation Theory, it is only after you have added your
'Truisms' that the system goes bad, thus showing your 'Truisms' are
really suitable.
Glad you see the error in YOUR system.
>
>>>> Writing it out formally is unlikely to help because the argument
>>>> needs a
>>>> mapping between the states of H and H^ and I suspect that explaining
>>>> that would either take months, or you'd declare it "extraneous" and
>>>> refuse to even consider it. There's another way, but that involves a
>>>> slight variation in the construction and you don't like such changes.
>>>>
>>>> There comes a point where no more clarity is available to you. If you
>>>> don't know by now that the same transition function, operating on the
>>>> same configuration can't result in transitions to different states, I
>>>> don't think there is any hope that you ever will. I think you are
>>>> doomed to be wrong and not know it, but if you think some more
>>>> explanation might help, ask away.
>>
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-08 21:25 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <OqidnSeRNOkF7aT8nZ2dnUU7-Y-dnZ2d@giganews.com> |
| In reply to | #39184 |
On 9/8/2021 8:30 PM, Richard Damon wrote:
> On 9/8/21 8:37 PM, olcott wrote:
>> On 9/8/2021 7:21 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 9/8/2021 5:52 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> 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:
>>>>>>>>>>>
>>>>>>>>>>>>>>> ... 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
>>>>>>>>>>> If your analogy does not match the facts I stated about TMs
>>>>>>>>>>> then it's
>>>>>>>>>>> wrong.
>>>>>>>>>>
>>>>>>>>>> Identical code with identical inputs must derive identical
>>>>>>>>>> results.
>>>>>>>>>
>>>>>>>>> No. That is obviously not true, except for some very rare
>>>>>>>>> languages
>>>>>>>>> that you probably don't know.
>>>>>>>>
>>>>>>>> At this point I would estimate that your technical competence is
>>>>>>>> much
>>>>>>>> lower that I had assumed. I would ask you to provide a concrete
>>>>>>>> example and would estimate that you would dodge thus sufficiently
>>>>>>>> proving that your technical competence is very likely much lower
>>>>>>>> that
>>>>>>>> I had assumed.
>>>>>>>
>>>>>>> As you know, whether I am right or not has nothing to do with
>>>>>>> either my
>>>>>>> competence or your opinion of it. TMs are not "code". Code can
>>>>>>> do IO,
>>>>>>> use static objects, examine its execution environment and so on.
>>>>>>> A lot
>>>>>>> of x86 code even has access to hardware-generated random numbers.
>>>>>>> You
>>>>>>> know this.
>>>>>>>
>>>>>>> If you want to talk code, stop using the notation for TM
>>>>>>> configurations.
>>>>>>> If you want to talk TMs, you will have to face the fact that you are
>>>>>>> wrong.
>>>>>>
>>>>>> So like I said you simply dodged supporting your obviously incorrect
>>>>>> rebuttal that identical code (sequences of state transitions) cannot
>>>>>> derive different results from the same input.
>>>>>
>>>>> Code is not a "sequence of state transitions", and TMs don't "derive
>>>>> results" (they accept, reject or fail to halt), but I don't want to get
>>>>> sucked into your bad wording.
>>>>>
>>>>> The state transition function of H and that at H^.qx are the same
>>>>> because one TM is an exact copy of the other (your words). The
>>>>> "inputs"
>>>>> (what you should call the tape) and the position of the tape head are
>>>>> also the same. The computations must evolve along exactly the same
>>>>> lines.
>>>>
>>>> This would seem intuitive yet false.
>>>
>>> Its a fact.
>>>
>>>> If we look at it at the very high level of abstraction we can
>>>> comprehend that simulating halt decider H need not abort the
>>>> simulation of its input because the simulating halt decider at Ĥ.qx
>>>> does abort the simulation of its input.
>>>
>>> The identical "machines" at H.q0 and H^.qx must perform exactly the same
>>> steps when presented with the same tape contents. H must transition to
>>> qn because H^.qx <H^><H^> does.
>>>
>>
>> When one machine is called with an input that refers to its own machine
>> description and another machine is called with an input that does not
>> refer to its own machine description then the two computations are not
>> the same even if their machine descriptions may be otherwise identical.
>
> But if H and H1 are copies of each other, why aren't there descriptions
> the same? I think this shows that H1 isn't really a copy of H, or maybe
> it is that H isn't a Computatation, and thus there isn't a 'Turing
> Machine Equivalent Description' since it doesn't have a Turing Machine
> Equivalent.
>
The machine / Input pair is not the same in that
H1/P has an input that does not call H1
H/P has an input that does call H
>>
>> I have empirical proof of this otherwise I may have not noticed this
>> myself. The execution trace that H derives of its input ⟨Ĥ⟩ ⟨Ĥ⟩ shows
>> that Ĥ.qx transitions to Ĥ.qn
>>
>> The execution trace that Ĥ.qx derives of its input ⟨Ĥ⟩ ⟨Ĥ⟩ shows that
>> its input never halts.
>
> And the point where those traces diverge shows what is different betwen
> the two machienes.
>
> Since H^ is supposed to have an EXACT copy of H, (except for a small
> edit in the qy state that we don't get to), it shows that you built H^
> wrong, or maybe that you can't actually express your H as a Turing
> Machine because it isn't actually a Computation, and thus there isn't a
> Turing Machine Equivalent for it.
>
>>
>> As Richard aptly pointed out this shows that the system is inconsistent.
>> This particular inconsistency becomes a pathological self-reference
>> (Olcott 2004) decider refuting Rice's Theorem.
>
> No, it shows that *YOUR* LOGIC SYSTEM is inconsistent, and thus can't be
> used for any meaningful proof, as a logic system that is inconsistent
> can prove ANY statement, whether True of False.
>
> The 'system' in Computation Theory, it is only after you have added your
> 'Truisms' that the system goes bad, thus showing your 'Truisms' are
> really suitable.
>
> Glad you see the error in YOUR system.
>
>>
>>>>> Writing it out formally is unlikely to help because the argument
>>>>> needs a
>>>>> mapping between the states of H and H^ and I suspect that explaining
>>>>> that would either take months, or you'd declare it "extraneous" and
>>>>> refuse to even consider it. There's another way, but that involves a
>>>>> slight variation in the construction and you don't like such changes.
>>>>>
>>>>> There comes a point where no more clarity is available to you. If you
>>>>> don't know by now that the same transition function, operating on the
>>>>> same configuration can't result in transitions to different states, I
>>>>> don't think there is any hope that you ever will. I think you are
>>>>> doomed to be wrong and not know it, but if you think some more
>>>>> explanation might help, ask away.
>>>
>>>
>>
>>
>
--
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 23:25 -0400 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <v8f_I.27179$gc3.23435@fx12.iad> |
| In reply to | #39194 |
On 9/8/21 10:25 PM, olcott wrote:
> On 9/8/2021 8:30 PM, Richard Damon wrote:
>> On 9/8/21 8:37 PM, olcott wrote:
>>> On 9/8/2021 7:21 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 9/8/2021 5:52 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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:
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ... 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
>>>>>>>>>>>> If your analogy does not match the facts I stated about TMs
>>>>>>>>>>>> then it's
>>>>>>>>>>>> wrong.
>>>>>>>>>>>
>>>>>>>>>>> Identical code with identical inputs must derive identical
>>>>>>>>>>> results.
>>>>>>>>>>
>>>>>>>>>> No. That is obviously not true, except for some very rare
>>>>>>>>>> languages
>>>>>>>>>> that you probably don't know.
>>>>>>>>>
>>>>>>>>> At this point I would estimate that your technical competence is
>>>>>>>>> much
>>>>>>>>> lower that I had assumed. I would ask you to provide a concrete
>>>>>>>>> example and would estimate that you would dodge thus sufficiently
>>>>>>>>> proving that your technical competence is very likely much lower
>>>>>>>>> that
>>>>>>>>> I had assumed.
>>>>>>>>
>>>>>>>> As you know, whether I am right or not has nothing to do with
>>>>>>>> either my
>>>>>>>> competence or your opinion of it. TMs are not "code". Code can
>>>>>>>> do IO,
>>>>>>>> use static objects, examine its execution environment and so on.
>>>>>>>> A lot
>>>>>>>> of x86 code even has access to hardware-generated random numbers.
>>>>>>>> You
>>>>>>>> know this.
>>>>>>>>
>>>>>>>> If you want to talk code, stop using the notation for TM
>>>>>>>> configurations.
>>>>>>>> If you want to talk TMs, you will have to face the fact that you
>>>>>>>> are
>>>>>>>> wrong.
>>>>>>>
>>>>>>> So like I said you simply dodged supporting your obviously incorrect
>>>>>>> rebuttal that identical code (sequences of state transitions) cannot
>>>>>>> derive different results from the same input.
>>>>>>
>>>>>> Code is not a "sequence of state transitions", and TMs don't "derive
>>>>>> results" (they accept, reject or fail to halt), but I don't want
>>>>>> to get
>>>>>> sucked into your bad wording.
>>>>>>
>>>>>> The state transition function of H and that at H^.qx are the same
>>>>>> because one TM is an exact copy of the other (your words). The
>>>>>> "inputs"
>>>>>> (what you should call the tape) and the position of the tape head are
>>>>>> also the same. The computations must evolve along exactly the same
>>>>>> lines.
>>>>>
>>>>> This would seem intuitive yet false.
>>>>
>>>> Its a fact.
>>>>
>>>>> If we look at it at the very high level of abstraction we can
>>>>> comprehend that simulating halt decider H need not abort the
>>>>> simulation of its input because the simulating halt decider at Ĥ.qx
>>>>> does abort the simulation of its input.
>>>>
>>>> The identical "machines" at H.q0 and H^.qx must perform exactly the
>>>> same
>>>> steps when presented with the same tape contents. H must transition to
>>>> qn because H^.qx <H^><H^> does.
>>>>
>>>
>>> When one machine is called with an input that refers to its own machine
>>> description and another machine is called with an input that does not
>>> refer to its own machine description then the two computations are not
>>> the same even if their machine descriptions may be otherwise identical.
>>
>> But if H and H1 are copies of each other, why aren't there descriptions
>> the same? I think this shows that H1 isn't really a copy of H, or maybe
>> it is that H isn't a Computatation, and thus there isn't a 'Turing
>> Machine Equivalent Description' since it doesn't have a Turing Machine
>> Equivalent.
>>
>
> The machine / Input pair is not the same in that
> H1/P has an input that does not call H1
> H/P has an input that does call H
But a machine that calls H1 would be different than a machine that calls
H, so that would be a DIFFERENT input.
Note, H^ is NOT defined with 'self-reference' where it uses whatever
machine it is given to. A given machine H^ is designed for a very
special machine H.
If H1 is the same machine as H, then H1(P,I) must equal H(P,I) for ALL P
and I. Since H1(H^,H^) does not equal H(H^,H^) they can't be the same
machine.
It actually seems to be from what you say, the issue is that H isn't a
Computation, and thus there IS no Turing Machine H to make H^ from.
You don't seem to realy understand what this H^ thing in the proof is,
maybe because you don't really understand what Computations or Turing
Mschines are.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-09-09 02:54 +0100 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <87ilzabjio.fsf@bsb.me.uk> |
| In reply to | #39177 |
olcott <NoOne@NoWhere.com> writes:
> On 9/8/2021 7:21 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 9/8/2021 5:52 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> 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:
>>>>>>>>>>
>>>>>>>>>>>>>> ... 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
>>>>>>>>>> If your analogy does not match the facts I stated about TMs then it's
>>>>>>>>>> wrong.
>>>>>>>>>
>>>>>>>>> Identical code with identical inputs must derive identical results.
>>>>>>>>
>>>>>>>> No. That is obviously not true, except for some very rare languages
>>>>>>>> that you probably don't know.
>>>>>>>
>>>>>>> At this point I would estimate that your technical competence is much
>>>>>>> lower that I had assumed. I would ask you to provide a concrete
>>>>>>> example and would estimate that you would dodge thus sufficiently
>>>>>>> proving that your technical competence is very likely much lower that
>>>>>>> I had assumed.
>>>>>>
>>>>>> As you know, whether I am right or not has nothing to do with either my
>>>>>> competence or your opinion of it. TMs are not "code". Code can do IO,
>>>>>> use static objects, examine its execution environment and so on. A lot
>>>>>> of x86 code even has access to hardware-generated random numbers. You
>>>>>> know this.
>>>>>>
>>>>>> If you want to talk code, stop using the notation for TM configurations.
>>>>>> If you want to talk TMs, you will have to face the fact that you are
>>>>>> wrong.
>>>>>
>>>>> So like I said you simply dodged supporting your obviously incorrect
>>>>> rebuttal that identical code (sequences of state transitions) cannot
>>>>> derive different results from the same input.
>>>>
>>>> Code is not a "sequence of state transitions", and TMs don't "derive
>>>> results" (they accept, reject or fail to halt), but I don't want to get
>>>> sucked into your bad wording.
>>>>
>>>> The state transition function of H and that at H^.qx are the same
>>>> because one TM is an exact copy of the other (your words). The "inputs"
>>>> (what you should call the tape) and the position of the tape head are
>>>> also the same. The computations must evolve along exactly the same
>>>> lines.
>>>
>>> This would seem intuitive yet false.
>>
>> Its a fact.
>>
>>> If we look at it at the very high level of abstraction we can
>>> comprehend that simulating halt decider H need not abort the
>>> simulation of its input because the simulating halt decider at Ĥ.qx
>>> does abort the simulation of its input.
>>
>> The identical "machines" at H.q0 and H^.qx must perform exactly the same
>> steps when presented with the same tape contents. H must transition to
>> qn because H^.qx <H^><H^> does.
>
> When one machine is called with an input that refers to its own
> machine description and another machine is called with an input that
> does not refer to its own machine description then the two
> computations are not the same even if their machine descriptions may
> be otherwise identical.
You are confused. Of course the computations you describe are
different. H.q0 <H^><H^> and H^.q0 <H^> are indeed not the same but
H.q0 <H^><H^> and H^.qx <H^><H^> are (with a minor difference you refuse
to accept anyway).
Of course, I can see all sorts of barriers to your understanding this.
You almost certainly still think that H^ can transition back to H^.q0.
If you still think that, then you are totally at sea. In effect, you
don't appear to know how H and H^ are really related, so it's no
surprise that you think that
H^ <H^> |-* H^.qx <H^><H^> |-* H^.qn
does not mean that H.q0 <H^><H^> |-* H.qn also. But you are wrong, it
does.
> I have empirical proof of this otherwise I may have not noticed this
> myself.
No, you don't have, and never have had, two TMs in the "hat"
relationship as Linz describes it. You once said you did, but that was,
apparently, "poetic license". What you have is a pile of C/x86 code
that you think is pretty much the same as having two TMs.
> The execution trace that H derives of its input ⟨Ĥ⟩ ⟨Ĥ⟩ shows
> that Ĥ.qx transitions to Ĥ.qn
Since you don't have any TMs to trace the execution of, this is also
"poetic license".
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-08 21:14 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <dYKdnUDEEcyC86T8nZ2dnUU7-QHNnZ2d@giganews.com> |
| In reply to | #39188 |
On 9/8/2021 8:54 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 9/8/2021 7:21 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 9/8/2021 5:52 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> 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:
>>>>>>>>>>>
>>>>>>>>>>>>>>> ... 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
>>>>>>>>>>> If your analogy does not match the facts I stated about TMs then it's
>>>>>>>>>>> wrong.
>>>>>>>>>>
>>>>>>>>>> Identical code with identical inputs must derive identical results.
>>>>>>>>>
>>>>>>>>> No. That is obviously not true, except for some very rare languages
>>>>>>>>> that you probably don't know.
>>>>>>>>
>>>>>>>> At this point I would estimate that your technical competence is much
>>>>>>>> lower that I had assumed. I would ask you to provide a concrete
>>>>>>>> example and would estimate that you would dodge thus sufficiently
>>>>>>>> proving that your technical competence is very likely much lower that
>>>>>>>> I had assumed.
>>>>>>>
>>>>>>> As you know, whether I am right or not has nothing to do with either my
>>>>>>> competence or your opinion of it. TMs are not "code". Code can do IO,
>>>>>>> use static objects, examine its execution environment and so on. A lot
>>>>>>> of x86 code even has access to hardware-generated random numbers. You
>>>>>>> know this.
>>>>>>>
>>>>>>> If you want to talk code, stop using the notation for TM configurations.
>>>>>>> If you want to talk TMs, you will have to face the fact that you are
>>>>>>> wrong.
>>>>>>
>>>>>> So like I said you simply dodged supporting your obviously incorrect
>>>>>> rebuttal that identical code (sequences of state transitions) cannot
>>>>>> derive different results from the same input.
>>>>>
>>>>> Code is not a "sequence of state transitions", and TMs don't "derive
>>>>> results" (they accept, reject or fail to halt), but I don't want to get
>>>>> sucked into your bad wording.
>>>>>
>>>>> The state transition function of H and that at H^.qx are the same
>>>>> because one TM is an exact copy of the other (your words). The "inputs"
>>>>> (what you should call the tape) and the position of the tape head are
>>>>> also the same. The computations must evolve along exactly the same
>>>>> lines.
>>>>
>>>> This would seem intuitive yet false.
>>>
>>> Its a fact.
>>>
>>>> If we look at it at the very high level of abstraction we can
>>>> comprehend that simulating halt decider H need not abort the
>>>> simulation of its input because the simulating halt decider at Ĥ.qx
>>>> does abort the simulation of its input.
>>>
>>> The identical "machines" at H.q0 and H^.qx must perform exactly the same
>>> steps when presented with the same tape contents. H must transition to
>>> qn because H^.qx <H^><H^> does.
>>
>> When one machine is called with an input that refers to its own
>> machine description and another machine is called with an input that
>> does not refer to its own machine description then the two
>> computations are not the same even if their machine descriptions may
>> be otherwise identical.
>
> You are confused. Of course the computations you describe are
> different. H.q0 <H^><H^> and H^.q0 <H^> are indeed not the same but
> H.q0 <H^><H^> and H^.qx <H^><H^> are (with a minor difference you refuse
> to accept anyway).
>
You can't understand that when H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ the execution trace
of this simulation shows that Ĥ.qx transitions to Ĥ.qn on input ⟨Ĥ⟩ ⟨Ĥ⟩ ???
In simpler terms you can't understand that a UTM can examine the
execution trace of its simulated TM?
> Of course, I can see all sorts of barriers to your understanding this.
> You almost certainly still think that H^ can transition back to H^.q0.
> If you still think that, then you are totally at sea. In effect, you
> don't appear to know how H and H^ are really related, so it's no
> surprise that you think that
>
> H^ <H^> |-* H^.qx <H^><H^> |-* H^.qn
>
> does not mean that H.q0 <H^><H^> |-* H.qn also. But you are wrong, it
> does.
>
>> I have empirical proof of this otherwise I may have not noticed this
>> myself.
>
> No, you don't have, and never have had, two TMs in the "hat"
> relationship as Linz describes it. You once said you did, but that was,
> apparently, "poetic license". What you have is a pile of C/x86 code
> that you think is pretty much the same as having two TMs.
>
>> The execution trace that H derives of its input ⟨Ĥ⟩ ⟨Ĥ⟩ shows
>> that Ĥ.qx transitions to Ĥ.qn
>
> Since you don't have any TMs to trace the execution of, this is also
> "poetic license".
>
--
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 23:29 -0400 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <Dcf_I.75622$rl3.6806@fx45.iad> |
| In reply to | #39191 |
On 9/8/21 10:14 PM, olcott wrote:
> On 9/8/2021 8:54 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 9/8/2021 7:21 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 9/8/2021 5:52 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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:
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ... 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
>>>>>>>>>>>> If your analogy does not match the facts I stated about TMs
>>>>>>>>>>>> then it's
>>>>>>>>>>>> wrong.
>>>>>>>>>>>
>>>>>>>>>>> Identical code with identical inputs must derive identical
>>>>>>>>>>> results.
>>>>>>>>>>
>>>>>>>>>> No. That is obviously not true, except for some very rare
>>>>>>>>>> languages
>>>>>>>>>> that you probably don't know.
>>>>>>>>>
>>>>>>>>> At this point I would estimate that your technical competence
>>>>>>>>> is much
>>>>>>>>> lower that I had assumed. I would ask you to provide a concrete
>>>>>>>>> example and would estimate that you would dodge thus sufficiently
>>>>>>>>> proving that your technical competence is very likely much
>>>>>>>>> lower that
>>>>>>>>> I had assumed.
>>>>>>>>
>>>>>>>> As you know, whether I am right or not has nothing to do with
>>>>>>>> either my
>>>>>>>> competence or your opinion of it. TMs are not "code". Code can
>>>>>>>> do IO,
>>>>>>>> use static objects, examine its execution environment and so
>>>>>>>> on. A lot
>>>>>>>> of x86 code even has access to hardware-generated random
>>>>>>>> numbers. You
>>>>>>>> know this.
>>>>>>>>
>>>>>>>> If you want to talk code, stop using the notation for TM
>>>>>>>> configurations.
>>>>>>>> If you want to talk TMs, you will have to face the fact that you
>>>>>>>> are
>>>>>>>> wrong.
>>>>>>>
>>>>>>> So like I said you simply dodged supporting your obviously incorrect
>>>>>>> rebuttal that identical code (sequences of state transitions) cannot
>>>>>>> derive different results from the same input.
>>>>>>
>>>>>> Code is not a "sequence of state transitions", and TMs don't "derive
>>>>>> results" (they accept, reject or fail to halt), but I don't want
>>>>>> to get
>>>>>> sucked into your bad wording.
>>>>>>
>>>>>> The state transition function of H and that at H^.qx are the same
>>>>>> because one TM is an exact copy of the other (your words). The
>>>>>> "inputs"
>>>>>> (what you should call the tape) and the position of the tape head are
>>>>>> also the same. The computations must evolve along exactly the same
>>>>>> lines.
>>>>>
>>>>> This would seem intuitive yet false.
>>>>
>>>> Its a fact.
>>>>
>>>>> If we look at it at the very high level of abstraction we can
>>>>> comprehend that simulating halt decider H need not abort the
>>>>> simulation of its input because the simulating halt decider at Ĥ.qx
>>>>> does abort the simulation of its input.
>>>>
>>>> The identical "machines" at H.q0 and H^.qx must perform exactly the
>>>> same
>>>> steps when presented with the same tape contents. H must transition to
>>>> qn because H^.qx <H^><H^> does.
>>>
>>> When one machine is called with an input that refers to its own
>>> machine description and another machine is called with an input that
>>> does not refer to its own machine description then the two
>>> computations are not the same even if their machine descriptions may
>>> be otherwise identical.
>>
>> You are confused. Of course the computations you describe are
>> different. H.q0 <H^><H^> and H^.q0 <H^> are indeed not the same but
>> H.q0 <H^><H^> and H^.qx <H^><H^> are (with a minor difference you refuse
>> to accept anyway).
>>
>
> You can't understand that when H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ the execution trace
> of this simulation shows that Ĥ.qx transitions to Ĥ.qn on input ⟨Ĥ⟩ ⟨Ĥ⟩
> ???
Right, and H^ going to H^.qn means that H^ halted, as that is a halting
state of H^.
THe fact that to H, that state indicated that it thinks its input is
non-halting doesn't change the meaning of the state to H^.
Is THAT your confusion,
>
> In simpler terms you can't understand that a UTM can examine the
> execution trace of its simulated TM?
Yes, a UTM can examine it trace, but a real UTM won't stop until the
machine it is simulating does, no matter how sure it is that it won't.
The problem is when H uses this analysis, and uses the FALSE assumption
that other copies of H will act only as UTM, and not switch out of that
mode leter and also abort their simulation, that cause H to get the
wrong answer.
H (like you) used UNSOUND Logic, and got the wrong answer.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-08 22:39 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <xo6dnWS9F6hkHKT8nZ2dnUU7-LfNnZ2d@giganews.com> |
| In reply to | #39203 |
On 9/8/2021 10:29 PM, Richard Damon wrote:
> On 9/8/21 10:14 PM, olcott wrote:
>> On 9/8/2021 8:54 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 9/8/2021 7:21 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 9/8/2021 5:52 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ... 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
>>>>>>>>>>>>> If your analogy does not match the facts I stated about TMs
>>>>>>>>>>>>> then it's
>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> Identical code with identical inputs must derive identical
>>>>>>>>>>>> results.
>>>>>>>>>>>
>>>>>>>>>>> No. That is obviously not true, except for some very rare
>>>>>>>>>>> languages
>>>>>>>>>>> that you probably don't know.
>>>>>>>>>>
>>>>>>>>>> At this point I would estimate that your technical competence
>>>>>>>>>> is much
>>>>>>>>>> lower that I had assumed. I would ask you to provide a concrete
>>>>>>>>>> example and would estimate that you would dodge thus sufficiently
>>>>>>>>>> proving that your technical competence is very likely much
>>>>>>>>>> lower that
>>>>>>>>>> I had assumed.
>>>>>>>>>
>>>>>>>>> As you know, whether I am right or not has nothing to do with
>>>>>>>>> either my
>>>>>>>>> competence or your opinion of it. TMs are not "code". Code can
>>>>>>>>> do IO,
>>>>>>>>> use static objects, examine its execution environment and so
>>>>>>>>> on. A lot
>>>>>>>>> of x86 code even has access to hardware-generated random
>>>>>>>>> numbers. You
>>>>>>>>> know this.
>>>>>>>>>
>>>>>>>>> If you want to talk code, stop using the notation for TM
>>>>>>>>> configurations.
>>>>>>>>> If you want to talk TMs, you will have to face the fact that you
>>>>>>>>> are
>>>>>>>>> wrong.
>>>>>>>>
>>>>>>>> So like I said you simply dodged supporting your obviously incorrect
>>>>>>>> rebuttal that identical code (sequences of state transitions) cannot
>>>>>>>> derive different results from the same input.
>>>>>>>
>>>>>>> Code is not a "sequence of state transitions", and TMs don't "derive
>>>>>>> results" (they accept, reject or fail to halt), but I don't want
>>>>>>> to get
>>>>>>> sucked into your bad wording.
>>>>>>>
>>>>>>> The state transition function of H and that at H^.qx are the same
>>>>>>> because one TM is an exact copy of the other (your words). The
>>>>>>> "inputs"
>>>>>>> (what you should call the tape) and the position of the tape head are
>>>>>>> also the same. The computations must evolve along exactly the same
>>>>>>> lines.
>>>>>>
>>>>>> This would seem intuitive yet false.
>>>>>
>>>>> Its a fact.
>>>>>
>>>>>> If we look at it at the very high level of abstraction we can
>>>>>> comprehend that simulating halt decider H need not abort the
>>>>>> simulation of its input because the simulating halt decider at Ĥ.qx
>>>>>> does abort the simulation of its input.
>>>>>
>>>>> The identical "machines" at H.q0 and H^.qx must perform exactly the
>>>>> same
>>>>> steps when presented with the same tape contents. H must transition to
>>>>> qn because H^.qx <H^><H^> does.
>>>>
>>>> When one machine is called with an input that refers to its own
>>>> machine description and another machine is called with an input that
>>>> does not refer to its own machine description then the two
>>>> computations are not the same even if their machine descriptions may
>>>> be otherwise identical.
>>>
>>> You are confused. Of course the computations you describe are
>>> different. H.q0 <H^><H^> and H^.q0 <H^> are indeed not the same but
>>> H.q0 <H^><H^> and H^.qx <H^><H^> are (with a minor difference you refuse
>>> to accept anyway).
>>>
>>
>> You can't understand that when H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ the execution trace
>> of this simulation shows that Ĥ.qx transitions to Ĥ.qn on input ⟨Ĥ⟩ ⟨Ĥ⟩
>> ???
>
> Right, and H^ going to H^.qn means that H^ halted, as that is a halting
> state of H^.
>
> THe fact that to H, that state indicated that it thinks its input is
> non-halting doesn't change the meaning of the state to H^.
>
No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many times.
No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many times.
No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many times.
No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many times.
Your insight that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qn seems to indicate an
inconsistent system was helpful, yet untrue.
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.
> Is THAT your confusion,
>
>>
>> In simpler terms you can't understand that a UTM can examine the
>> execution trace of its simulated TM?
>
> Yes, a UTM can examine it trace, but a real UTM won't stop until the
> machine it is simulating does, no matter how sure it is that it won't.
>
> The problem is when H uses this analysis, and uses the FALSE assumption
> that other copies of H will act only as UTM, and not switch out of that
> mode leter and also abort their simulation, that cause H to get the
> wrong answer.
>
> H (like you) used UNSOUND Logic, and got the wrong answer.
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
Page 35 of 37 — ← Prev page 1 … 33 34 [35] 36 37 Next page →
Back to top | Article view | comp.theory
csiph-web