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 26 of 37 — ← Prev page 1 … 24 25 [26] 27 28 … 37 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-06 20:40 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] |
| Message-ID | <YIadnYsG7fOKXqv8nZ2dnUU7-KHNnZ2d@giganews.com> |
| In reply to | #39003 |
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:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 9/6/2021 5:55 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 9/6/2021 3:58 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/5/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>>>>>>>> ... Ĥ includes an exact copy of H embedded at its state Ĥ.qx
>>>>>>>
>>>>>>>>>> You don't understand operating system process context switching.
>>>>>>>>>
>>>>>>>>> Change the subject. Good plan!
>>>>>>>>
>>>>>>>> I am not changing the subject. I am enumerating the key prerequisite
>>>>>>>> knowledge that you are lacking, to understand what I am saying.
>>>>>>> Your claimed knowledge of process context switching is no excuse for not
>>>>>>> knowing what Linz is saying about TMs.
>>>>>>> H^ contains an almost identical copy if H embedded in at the state you
>>>>>>> call H^.qx. Fortunately, the small differences don't prevent you from
>>>>>>> being wrong, so I will use your word and call it an "exact copy".
>>>>>>> You have accepted that, when construed as an input to your H, the string
>>>>>>> <H^><H^> encodes a halting computation. If your H has any pretensions
>>>>>>> of being a halt decider, it should accept that string:
>>>>>>>
>>>>>>> H.q0 <H^><H^> |- H.qy
>>>>>>
>>>>>> I have already said that a bunch of times yet you did not notice
>>>>>> because you diligently want to remain focused in disagreement mode.
>>>>>
>>>>> I am happy you think you've said it lots of times. I could not find any
>>>>> but I also know not to bother asking you for references.
>>>>>
>>>>>>> But you keep telling us that, in fact, the "exact copy" of H embedded in
>>>>>>> H^ transitions to H^.qn when run with just <H^><H^> on the tape:
>>>>>>>
>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>
>>>>>>> An "exact copy" of H can't make an transitions that H can't take, and in
>>>>>>> fact pretty much everything you've said up until now confirms that your
>>>>>>> H in fact rejects the string <H^><H^>. All you effort has been put to
>>>>>>> explaining why the wrong answer is in fact the right one.
>>>>>>
>>>>>> Like I said (and this is beyond your technical competence)
>>>>>> int main() { H1(P,P) }; is the precise analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>
>>>>> Ah, proof by analogy won't fly. This line
>>>>> H^.qx <H^><H^> |- H^.qn
>>>>> shows that your H is wrong. It's a simple as that.
>>>>
>>>> Not at all distinctly different computations can have different
>>>> results.
>>> You tell me they are the same computation.
>>
>> No I never ever said that.
>> I ALWAYS ALWAYS SAY THAT THEY ARE DISTINCTLY DIFFERENT COMPUTATONS.
>
> Identical TMs with identical inputs are computationally equivalent. We
> know that
>
> H^.qx <H^><H^> |- H^.qn
>
> so the same TM (H), run with the same input (<H^><H^>), cannot
> transition to the sate you say it should. One of your claims is wrong.
> (I can't possibly know which, but they can't both be ture.)
>
>>> 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.
> Have you just been pretending to talk about
> TMs the whole time? If you are not talking about TMs, just say so and
> let you carry on waffling about your secret pile of C code. TMs have
> clear and precise behaviour, so you can't waffle about them.
>
>>>>> Your H fails because it does this:
>>>>> H.q0 <H^><H^> |- H.qn
>>>>> when its should do this
>>>>> H.q0 <H^><H^> |- H.qy
>
--
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-07 02:57 +0100 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] |
| Message-ID | <87h7exgna4.fsf@bsb.me.uk> |
| In reply to | #39010 |
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:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 9/6/2021 5:55 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 9/6/2021 3:58 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 9/5/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>>>>>>>> ... Ĥ includes an exact copy of H embedded at its state Ĥ.qx
>>>>>>>>
>>>>>>>>>>> You don't understand operating system process context switching.
>>>>>>>>>>
>>>>>>>>>> Change the subject. Good plan!
>>>>>>>>>
>>>>>>>>> I am not changing the subject. I am enumerating the key prerequisite
>>>>>>>>> knowledge that you are lacking, to understand what I am saying.
>>>>>>>> Your claimed knowledge of process context switching is no excuse for not
>>>>>>>> knowing what Linz is saying about TMs.
>>>>>>>> H^ contains an almost identical copy if H embedded in at the state you
>>>>>>>> call H^.qx. Fortunately, the small differences don't prevent you from
>>>>>>>> being wrong, so I will use your word and call it an "exact copy".
>>>>>>>> You have accepted that, when construed as an input to your H, the string
>>>>>>>> <H^><H^> encodes a halting computation. If your H has any pretensions
>>>>>>>> of being a halt decider, it should accept that string:
>>>>>>>>
>>>>>>>> H.q0 <H^><H^> |- H.qy
>>>>>>>
>>>>>>> I have already said that a bunch of times yet you did not notice
>>>>>>> because you diligently want to remain focused in disagreement mode.
>>>>>>
>>>>>> I am happy you think you've said it lots of times. I could not find any
>>>>>> but I also know not to bother asking you for references.
>>>>>>
>>>>>>>> But you keep telling us that, in fact, the "exact copy" of H embedded in
>>>>>>>> H^ transitions to H^.qn when run with just <H^><H^> on the tape:
>>>>>>>>
>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>
>>>>>>>> An "exact copy" of H can't make an transitions that H can't take, and in
>>>>>>>> fact pretty much everything you've said up until now confirms that your
>>>>>>>> H in fact rejects the string <H^><H^>. All you effort has been put to
>>>>>>>> explaining why the wrong answer is in fact the right one.
>>>>>>>
>>>>>>> Like I said (and this is beyond your technical competence)
>>>>>>> int main() { H1(P,P) }; is the precise analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>
>>>>>> Ah, proof by analogy won't fly. This line
>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>> shows that your H is wrong. It's a simple as that.
>>>>>
>>>>> Not at all distinctly different computations can have different
>>>>> results.
>>>> You tell me they are the same computation.
>>>
>>> No I never ever said that.
>>> I ALWAYS ALWAYS SAY THAT THEY ARE DISTINCTLY DIFFERENT COMPUTATONS.
>>
>> Identical TMs with identical inputs are computationally equivalent. We
>> know that
>> H^.qx <H^><H^> |- H^.qn
>> so the same TM (H), run with the same input (<H^><H^>), cannot
>> transition to the sate you say it should. One of your claims is wrong.
>> (I can't possibly know which, but they can't both be ture.)
>>
>>>> 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
when it should, in fact, accept that string. How do I know that H.q0
<H^><H^> transitions to qn? Because you keep telling me the exact same
TM with the exact same input does that.
You can't waffle about TMs. I think you had better not talk about them
anymore because they make showing you are wrong far too easy.
>>>>>> Your H fails because it does this:
>>>>>> H.q0 <H^><H^> |- H.qn
>>>>>> when its should do this
>>>>>> H.q0 <H^><H^> |- H.qy
>>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-06 21:17 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] |
| Message-ID | <-qWdnQehD4w7Vqv8nZ2dnUU7-a_NnZ2d@giganews.com> |
| In reply to | #39015 |
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:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 9/6/2021 5:55 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/6/2021 3:58 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 9/5/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>>>>>>>> ... Ĥ includes an exact copy of H embedded at its state Ĥ.qx
>>>>>>>>>
>>>>>>>>>>>> You don't understand operating system process context switching.
>>>>>>>>>>>
>>>>>>>>>>> Change the subject. Good plan!
>>>>>>>>>>
>>>>>>>>>> I am not changing the subject. I am enumerating the key prerequisite
>>>>>>>>>> knowledge that you are lacking, to understand what I am saying.
>>>>>>>>> Your claimed knowledge of process context switching is no excuse for not
>>>>>>>>> knowing what Linz is saying about TMs.
>>>>>>>>> H^ contains an almost identical copy if H embedded in at the state you
>>>>>>>>> call H^.qx. Fortunately, the small differences don't prevent you from
>>>>>>>>> being wrong, so I will use your word and call it an "exact copy".
>>>>>>>>> You have accepted that, when construed as an input to your H, the string
>>>>>>>>> <H^><H^> encodes a halting computation. If your H has any pretensions
>>>>>>>>> of being a halt decider, it should accept that string:
>>>>>>>>>
>>>>>>>>> H.q0 <H^><H^> |- H.qy
>>>>>>>>
>>>>>>>> I have already said that a bunch of times yet you did not notice
>>>>>>>> because you diligently want to remain focused in disagreement mode.
>>>>>>>
>>>>>>> I am happy you think you've said it lots of times. I could not find any
>>>>>>> but I also know not to bother asking you for references.
>>>>>>>
>>>>>>>>> But you keep telling us that, in fact, the "exact copy" of H embedded in
>>>>>>>>> H^ transitions to H^.qn when run with just <H^><H^> on the tape:
>>>>>>>>>
>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>
>>>>>>>>> An "exact copy" of H can't make an transitions that H can't take, and in
>>>>>>>>> fact pretty much everything you've said up until now confirms that your
>>>>>>>>> H in fact rejects the string <H^><H^>. All you effort has been put to
>>>>>>>>> explaining why the wrong answer is in fact the right one.
>>>>>>>>
>>>>>>>> Like I said (and this is beyond your technical competence)
>>>>>>>> int main() { H1(P,P) }; is the precise analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>
>>>>>>> Ah, proof by analogy won't fly. This line
>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>> shows that your H is wrong. It's a simple as that.
>>>>>>
>>>>>> Not at all distinctly different computations can have different
>>>>>> results.
>>>>> You tell me they are the same computation.
>>>>
>>>> No I never ever said that.
>>>> I ALWAYS ALWAYS SAY THAT THEY ARE DISTINCTLY DIFFERENT COMPUTATONS.
>>>
>>> Identical TMs with identical inputs are computationally equivalent. We
>>> know that
>>> H^.qx <H^><H^> |- H^.qn
>>> so the same TM (H), run with the same input (<H^><H^>), cannot
>>> transition to the sate you say it should. One of your claims is wrong.
>>> (I can't possibly know which, but they can't both be ture.)
>>>
>>>>> 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.
Because H is simulating Ĥ it can see what H is doing and change its
behavior in a way that H cannot do.
If the theory of computation says that this cannot occur then the theory
of computation must be updated because it is occurring.
> when it should, in fact, accept that string. How do I know that H.q0
> <H^><H^> transitions to qn? Because you keep telling me the exact same
> TM with the exact same input does that.
>
> You can't waffle about TMs. I think you had better not talk about them
> anymore because they make showing you are wrong far too easy.
>
>>>>>>> Your H fails because it does this:
>>>>>>> H.q0 <H^><H^> |- H.qn
>>>>>>> when its should do this
>>>>>>> H.q0 <H^><H^> |- H.qy
>>>
>
--
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-06 22:56 -0400 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] |
| Message-ID | <AxAZI.28673$tG6.17694@fx39.iad> |
| In reply to | #39017 |
On 9/6/21 10:17 PM, olcott wrote:
> 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:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 9/6/2021 5:55 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 9/6/2021 3:58 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 9/5/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>>>>>>>> ... Ĥ includes an exact copy of H embedded at its state
>>>>>>>>>>>>>>>>> Ĥ.qx
>>>>>>>>>>
>>>>>>>>>>>>> You don't understand operating system process context
>>>>>>>>>>>>> switching.
>>>>>>>>>>>>
>>>>>>>>>>>> Change the subject. Good plan!
>>>>>>>>>>>
>>>>>>>>>>> I am not changing the subject. I am enumerating the key
>>>>>>>>>>> prerequisite
>>>>>>>>>>> knowledge that you are lacking, to understand what I am saying.
>>>>>>>>>> Your claimed knowledge of process context switching is no
>>>>>>>>>> excuse for not
>>>>>>>>>> knowing what Linz is saying about TMs.
>>>>>>>>>> H^ contains an almost identical copy if H embedded in at the
>>>>>>>>>> state you
>>>>>>>>>> call H^.qx. Fortunately, the small differences don't prevent
>>>>>>>>>> you from
>>>>>>>>>> being wrong, so I will use your word and call it an "exact copy".
>>>>>>>>>> You have accepted that, when construed as an input to your H,
>>>>>>>>>> the string
>>>>>>>>>> <H^><H^> encodes a halting computation. If your H has any
>>>>>>>>>> pretensions
>>>>>>>>>> of being a halt decider, it should accept that string:
>>>>>>>>>>
>>>>>>>>>> H.q0 <H^><H^> |- H.qy
>>>>>>>>>
>>>>>>>>> I have already said that a bunch of times yet you did not notice
>>>>>>>>> because you diligently want to remain focused in disagreement
>>>>>>>>> mode.
>>>>>>>>
>>>>>>>> I am happy you think you've said it lots of times. I could not
>>>>>>>> find any
>>>>>>>> but I also know not to bother asking you for references.
>>>>>>>>
>>>>>>>>>> But you keep telling us that, in fact, the "exact copy" of H
>>>>>>>>>> embedded in
>>>>>>>>>> H^ transitions to H^.qn when run with just <H^><H^> on the tape:
>>>>>>>>>>
>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>>
>>>>>>>>>> An "exact copy" of H can't make an transitions that H can't
>>>>>>>>>> take, and in
>>>>>>>>>> fact pretty much everything you've said up until now confirms
>>>>>>>>>> that your
>>>>>>>>>> H in fact rejects the string <H^><H^>. All you effort has
>>>>>>>>>> been put to
>>>>>>>>>> explaining why the wrong answer is in fact the right one.
>>>>>>>>>
>>>>>>>>> Like I said (and this is beyond your technical competence)
>>>>>>>>> int main() { H1(P,P) }; is the precise analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>
>>>>>>>> Ah, proof by analogy won't fly. This line
>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>> shows that your H is wrong. It's a simple as that.
>>>>>>>
>>>>>>> Not at all distinctly different computations can have different
>>>>>>> results.
>>>>>> You tell me they are the same computation.
>>>>>
>>>>> No I never ever said that.
>>>>> I ALWAYS ALWAYS SAY THAT THEY ARE DISTINCTLY DIFFERENT COMPUTATONS.
>>>>
>>>> Identical TMs with identical inputs are computationally equivalent. We
>>>> know that
>>>> H^.qx <H^><H^> |- H^.qn
>>>> so the same TM (H), run with the same input (<H^><H^>), cannot
>>>> transition to the sate you say it should. One of your claims is wrong.
>>>> (I can't possibly know which, but they can't both be ture.)
>>>>
>>>>>> 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.Just
>
> Because H is simulating Ĥ it can see what H is doing and change its
> behavior in a way that H cannot do.
>
> If the theory of computation says that this cannot occur then the theory
> of computation must be updated because it is occurring.
>
As I have said, just proves that H isn't a computation, and thus not
qualified to be a decider.
Also, that help explains why it gets the answer WRONG.
>
>> when it should, in fact, accept that string. How do I know that H.q0
>> <H^><H^> transitions to qn? Because you keep telling me the exact same
>> TM with the exact same input does that.
>>
>> You can't waffle about TMs. I think you had better not talk about them
>> anymore because they make showing you are wrong far too easy.
>>
>>>>>>>> Your H fails because it does this:
>>>>>>>> H.q0 <H^><H^> |- H.qn
>>>>>>>> when its should do this
>>>>>>>> H.q0 <H^><H^> |- H.qy
>>>>
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-06 22:05 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] |
| Message-ID | <97ednSh7vf98S6v8nZ2dnUU7-e3NnZ2d@giganews.com> |
| In reply to | #39024 |
On 9/6/2021 9:56 PM, Richard Damon wrote:
> On 9/6/21 10:17 PM, olcott wrote:
>> 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:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/6/2021 5:55 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 9/6/2021 3:58 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 9/5/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ... Ĥ includes an exact copy of H embedded at its state
>>>>>>>>>>>>>>>>>> Ĥ.qx
>>>>>>>>>>>
>>>>>>>>>>>>>> You don't understand operating system process context
>>>>>>>>>>>>>> switching.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Change the subject. Good plan!
>>>>>>>>>>>>
>>>>>>>>>>>> I am not changing the subject. I am enumerating the key
>>>>>>>>>>>> prerequisite
>>>>>>>>>>>> knowledge that you are lacking, to understand what I am saying.
>>>>>>>>>>> Your claimed knowledge of process context switching is no
>>>>>>>>>>> excuse for not
>>>>>>>>>>> knowing what Linz is saying about TMs.
>>>>>>>>>>> H^ contains an almost identical copy if H embedded in at the
>>>>>>>>>>> state you
>>>>>>>>>>> call H^.qx. Fortunately, the small differences don't prevent
>>>>>>>>>>> you from
>>>>>>>>>>> being wrong, so I will use your word and call it an "exact copy".
>>>>>>>>>>> You have accepted that, when construed as an input to your H,
>>>>>>>>>>> the string
>>>>>>>>>>> <H^><H^> encodes a halting computation. If your H has any
>>>>>>>>>>> pretensions
>>>>>>>>>>> of being a halt decider, it should accept that string:
>>>>>>>>>>>
>>>>>>>>>>> H.q0 <H^><H^> |- H.qy
>>>>>>>>>>
>>>>>>>>>> I have already said that a bunch of times yet you did not notice
>>>>>>>>>> because you diligently want to remain focused in disagreement
>>>>>>>>>> mode.
>>>>>>>>>
>>>>>>>>> I am happy you think you've said it lots of times. I could not
>>>>>>>>> find any
>>>>>>>>> but I also know not to bother asking you for references.
>>>>>>>>>
>>>>>>>>>>> But you keep telling us that, in fact, the "exact copy" of H
>>>>>>>>>>> embedded in
>>>>>>>>>>> H^ transitions to H^.qn when run with just <H^><H^> on the tape:
>>>>>>>>>>>
>>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>>>
>>>>>>>>>>> An "exact copy" of H can't make an transitions that H can't
>>>>>>>>>>> take, and in
>>>>>>>>>>> fact pretty much everything you've said up until now confirms
>>>>>>>>>>> that your
>>>>>>>>>>> H in fact rejects the string <H^><H^>. All you effort has
>>>>>>>>>>> been put to
>>>>>>>>>>> explaining why the wrong answer is in fact the right one.
>>>>>>>>>>
>>>>>>>>>> Like I said (and this is beyond your technical competence)
>>>>>>>>>> int main() { H1(P,P) }; is the precise analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>
>>>>>>>>> Ah, proof by analogy won't fly. This line
>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>> shows that your H is wrong. It's a simple as that.
>>>>>>>>
>>>>>>>> Not at all distinctly different computations can have different
>>>>>>>> results.
>>>>>>> You tell me they are the same computation.
>>>>>>
>>>>>> No I never ever said that.
>>>>>> I ALWAYS ALWAYS SAY THAT THEY ARE DISTINCTLY DIFFERENT COMPUTATONS.
>>>>>
>>>>> Identical TMs with identical inputs are computationally equivalent. We
>>>>> know that
>>>>> H^.qx <H^><H^> |- H^.qn
>>>>> so the same TM (H), run with the same input (<H^><H^>), cannot
>>>>> transition to the sate you say it should. One of your claims is wrong.
>>>>> (I can't possibly know which, but they can't both be ture.)
>>>>>
>>>>>>> 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.Just
>>
>> Because H is simulating Ĥ it can see what H is doing and change its
>> behavior in a way that H cannot do.
>>
>> If the theory of computation says that this cannot occur then the theory
>> of computation must be updated because it is occurring.
>>
>
> As I have said, just proves that H isn't a computation, and thus not
> qualified to be a decider.
>
What part of this makes either one or both not a computation?
Because H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it can see whatever Ĥ does and change its
own behavior accordingly.
Because Ĥ is simulated by H it cannot see anything that H does
or change its own behavior accordingly.
--
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-06 23:51 -0400 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] |
| Message-ID | <jlBZI.26979$gc3.17520@fx12.iad> |
| In reply to | #39026 |
On 9/6/21 11:05 PM, olcott wrote:
> On 9/6/2021 9:56 PM, Richard Damon wrote:
>> On 9/6/21 10:17 PM, olcott wrote:
>>> 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:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 9/6/2021 5:55 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 9/6/2021 3:58 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/5/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ... Ĥ includes an exact copy of H embedded at its state
>>>>>>>>>>>>>>>>>>> Ĥ.qx
>>>>>>>>>>>>
>>>>>>>>>>>>>>> You don't understand operating system process context
>>>>>>>>>>>>>>> switching.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Change the subject. Good plan!
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am not changing the subject. I am enumerating the key
>>>>>>>>>>>>> prerequisite
>>>>>>>>>>>>> knowledge that you are lacking, to understand what I am
>>>>>>>>>>>>> saying.
>>>>>>>>>>>> Your claimed knowledge of process context switching is no
>>>>>>>>>>>> excuse for not
>>>>>>>>>>>> knowing what Linz is saying about TMs.
>>>>>>>>>>>> H^ contains an almost identical copy if H embedded in at the
>>>>>>>>>>>> state you
>>>>>>>>>>>> call H^.qx. Fortunately, the small differences don't prevent
>>>>>>>>>>>> you from
>>>>>>>>>>>> being wrong, so I will use your word and call it an "exact
>>>>>>>>>>>> copy".
>>>>>>>>>>>> You have accepted that, when construed as an input to your H,
>>>>>>>>>>>> the string
>>>>>>>>>>>> <H^><H^> encodes a halting computation. If your H has any
>>>>>>>>>>>> pretensions
>>>>>>>>>>>> of being a halt decider, it should accept that string:
>>>>>>>>>>>>
>>>>>>>>>>>> H.q0 <H^><H^> |- H.qy
>>>>>>>>>>>
>>>>>>>>>>> I have already said that a bunch of times yet you did not notice
>>>>>>>>>>> because you diligently want to remain focused in disagreement
>>>>>>>>>>> mode.
>>>>>>>>>>
>>>>>>>>>> I am happy you think you've said it lots of times. I could not
>>>>>>>>>> find any
>>>>>>>>>> but I also know not to bother asking you for references.
>>>>>>>>>>
>>>>>>>>>>>> But you keep telling us that, in fact, the "exact copy" of H
>>>>>>>>>>>> embedded in
>>>>>>>>>>>> H^ transitions to H^.qn when run with just <H^><H^> on the
>>>>>>>>>>>> tape:
>>>>>>>>>>>>
>>>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>>>>
>>>>>>>>>>>> An "exact copy" of H can't make an transitions that H can't
>>>>>>>>>>>> take, and in
>>>>>>>>>>>> fact pretty much everything you've said up until now confirms
>>>>>>>>>>>> that your
>>>>>>>>>>>> H in fact rejects the string <H^><H^>. All you effort has
>>>>>>>>>>>> been put to
>>>>>>>>>>>> explaining why the wrong answer is in fact the right one.
>>>>>>>>>>>
>>>>>>>>>>> Like I said (and this is beyond your technical competence)
>>>>>>>>>>> int main() { H1(P,P) }; is the precise analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>
>>>>>>>>>> Ah, proof by analogy won't fly. This line
>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>> shows that your H is wrong. It's a simple as that.
>>>>>>>>>
>>>>>>>>> Not at all distinctly different computations can have different
>>>>>>>>> results.
>>>>>>>> You tell me they are the same computation.
>>>>>>>
>>>>>>> No I never ever said that.
>>>>>>> I ALWAYS ALWAYS SAY THAT THEY ARE DISTINCTLY DIFFERENT COMPUTATONS.
>>>>>>
>>>>>> Identical TMs with identical inputs are computationally
>>>>>> equivalent. We
>>>>>> know that
>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>> so the same TM (H), run with the same input (<H^><H^>), cannot
>>>>>> transition to the sate you say it should. One of your claims is
>>>>>> wrong.
>>>>>> (I can't possibly know which, but they can't both be ture.)
>>>>>>
>>>>>>>> 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.Just
>>>
>>> Because H is simulating Ĥ it can see what H is doing and change its
>>> behavior in a way that H cannot do.
>>>
>>> If the theory of computation says that this cannot occur then the theory
>>> of computation must be updated because it is occurring.
>>>
>>
>> As I have said, just proves that H isn't a computation, and thus not
>> qualified to be a decider.
>>
>
> What part of this makes either one or both not a computation?
>
> Because H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it can see whatever Ĥ does and change its
> own behavior accordingly.
>
> Because Ĥ is simulated by H it cannot see anything that H does
> or change its own behavior accordingly.
>
Neither of those makes things not a computation. The latter is FALSE
because H^ includes a copy of H's algorithm in it, it know EXACTLY what
H is going to answer, so it CAN change its behavior to match whatever
the simulating decider will decide to do.
If H doesn't do what the copy in H^ sees it will do, then THAT shows H
isn't a computation.
The point that makes H not a computation is that you claim that the
machine represented by <H^> <H^> when given to H represents a DIFFERENT
machine than the H^(<H^>) that is run independently.
That implies that H^ isn't a computation, and the only place H^ can fail
to be a computation is inside its copy of H, so if H^ isn't a
computation, then we know that H isn't.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-06 22:59 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] |
| Message-ID | <172dncSVzPkmfqv8nZ2dnUU7-eXNnZ2d@giganews.com> |
| In reply to | #39037 |
On 9/6/2021 10:51 PM, Richard Damon wrote:
> On 9/6/21 11:05 PM, olcott wrote:
>> On 9/6/2021 9:56 PM, Richard Damon wrote:
>>> On 9/6/21 10:17 PM, olcott wrote:
>>>> 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:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 9/6/2021 5:55 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 9/6/2021 3:58 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/5/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ... Ĥ includes an exact copy of H embedded at its state
>>>>>>>>>>>>>>>>>>>> Ĥ.qx
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You don't understand operating system process context
>>>>>>>>>>>>>>>> switching.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Change the subject. Good plan!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am not changing the subject. I am enumerating the key
>>>>>>>>>>>>>> prerequisite
>>>>>>>>>>>>>> knowledge that you are lacking, to understand what I am
>>>>>>>>>>>>>> saying.
>>>>>>>>>>>>> Your claimed knowledge of process context switching is no
>>>>>>>>>>>>> excuse for not
>>>>>>>>>>>>> knowing what Linz is saying about TMs.
>>>>>>>>>>>>> H^ contains an almost identical copy if H embedded in at the
>>>>>>>>>>>>> state you
>>>>>>>>>>>>> call H^.qx. Fortunately, the small differences don't prevent
>>>>>>>>>>>>> you from
>>>>>>>>>>>>> being wrong, so I will use your word and call it an "exact
>>>>>>>>>>>>> copy".
>>>>>>>>>>>>> You have accepted that, when construed as an input to your H,
>>>>>>>>>>>>> the string
>>>>>>>>>>>>> <H^><H^> encodes a halting computation. If your H has any
>>>>>>>>>>>>> pretensions
>>>>>>>>>>>>> of being a halt decider, it should accept that string:
>>>>>>>>>>>>>
>>>>>>>>>>>>> H.q0 <H^><H^> |- H.qy
>>>>>>>>>>>>
>>>>>>>>>>>> I have already said that a bunch of times yet you did not notice
>>>>>>>>>>>> because you diligently want to remain focused in disagreement
>>>>>>>>>>>> mode.
>>>>>>>>>>>
>>>>>>>>>>> I am happy you think you've said it lots of times. I could not
>>>>>>>>>>> find any
>>>>>>>>>>> but I also know not to bother asking you for references.
>>>>>>>>>>>
>>>>>>>>>>>>> But you keep telling us that, in fact, the "exact copy" of H
>>>>>>>>>>>>> embedded in
>>>>>>>>>>>>> H^ transitions to H^.qn when run with just <H^><H^> on the
>>>>>>>>>>>>> tape:
>>>>>>>>>>>>>
>>>>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> An "exact copy" of H can't make an transitions that H can't
>>>>>>>>>>>>> take, and in
>>>>>>>>>>>>> fact pretty much everything you've said up until now confirms
>>>>>>>>>>>>> that your
>>>>>>>>>>>>> H in fact rejects the string <H^><H^>. All you effort has
>>>>>>>>>>>>> been put to
>>>>>>>>>>>>> explaining why the wrong answer is in fact the right one.
>>>>>>>>>>>>
>>>>>>>>>>>> Like I said (and this is beyond your technical competence)
>>>>>>>>>>>> int main() { H1(P,P) }; is the precise analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>
>>>>>>>>>>> Ah, proof by analogy won't fly. This line
>>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>>> shows that your H is wrong. It's a simple as that.
>>>>>>>>>>
>>>>>>>>>> Not at all distinctly different computations can have different
>>>>>>>>>> results.
>>>>>>>>> You tell me they are the same computation.
>>>>>>>>
>>>>>>>> No I never ever said that.
>>>>>>>> I ALWAYS ALWAYS SAY THAT THEY ARE DISTINCTLY DIFFERENT COMPUTATONS.
>>>>>>>
>>>>>>> Identical TMs with identical inputs are computationally
>>>>>>> equivalent. We
>>>>>>> know that
>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>> so the same TM (H), run with the same input (<H^><H^>), cannot
>>>>>>> transition to the sate you say it should. One of your claims is
>>>>>>> wrong.
>>>>>>> (I can't possibly know which, but they can't both be ture.)
>>>>>>>
>>>>>>>>> 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.Just
>>>>
>>>> Because H is simulating Ĥ it can see what H is doing and change its
>>>> behavior in a way that H cannot do.
>>>>
>>>> If the theory of computation says that this cannot occur then the theory
>>>> of computation must be updated because it is occurring.
>>>>
>>>
>>> As I have said, just proves that H isn't a computation, and thus not
>>> qualified to be a decider.
>>>
>>
>> What part of this makes either one or both not a computation?
>>
>> Because H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it can see whatever Ĥ does and change its
>> own behavior accordingly.
>>
>> Because Ĥ is simulated by H it cannot see anything that H does
>> or change its own behavior accordingly.
>>
>
> Neither of those makes things not a computation. The latter is FALSE
> because H^ includes a copy of H's algorithm in it, it know EXACTLY what
> H is going to answer,
H sees that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts because it sees Ĥ.qx transition to Ĥ.qn
Ĥ does not see that its input halts.
You can ignore the fact that execution order makes a difference.
This only makes you look foolish.
> so it CAN change its behavior to match whatever
> the simulating decider will decide to do.
>
> If H doesn't do what the copy in H^ sees it will do, then THAT shows H
> isn't a computation.
>
> The point that makes H not a computation is that you claim that the
> machine represented by <H^> <H^> when given to H represents a DIFFERENT
> machine than the H^(<H^>) that is run independently.
>
> That implies that H^ isn't a computation, and the only place H^ can fail
> to be a computation is inside its copy of H, so if H^ isn't a
> computation, then we know that H isn't.
>
--
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-07 06:28 -0400 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] |
| Message-ID | <i9HZI.10012$2e3.986@fx29.iad> |
| In reply to | #39040 |
On 9/6/21 11:59 PM, olcott wrote:
> On 9/6/2021 10:51 PM, Richard Damon wrote:
>> On 9/6/21 11:05 PM, olcott wrote:
>>> On 9/6/2021 9:56 PM, Richard Damon wrote:
>>>> On 9/6/21 10:17 PM, olcott wrote:
>>>>> 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:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 9/6/2021 5:55 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/6/2021 3:58 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/5/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ... Ĥ includes an exact copy of H embedded at its
>>>>>>>>>>>>>>>>>>>>> state
>>>>>>>>>>>>>>>>>>>>> Ĥ.qx
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You don't understand operating system process context
>>>>>>>>>>>>>>>>> switching.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Change the subject. Good plan!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am not changing the subject. I am enumerating the key
>>>>>>>>>>>>>>> prerequisite
>>>>>>>>>>>>>>> knowledge that you are lacking, to understand what I am
>>>>>>>>>>>>>>> saying.
>>>>>>>>>>>>>> Your claimed knowledge of process context switching is no
>>>>>>>>>>>>>> excuse for not
>>>>>>>>>>>>>> knowing what Linz is saying about TMs.
>>>>>>>>>>>>>> H^ contains an almost identical copy if H embedded in at the
>>>>>>>>>>>>>> state you
>>>>>>>>>>>>>> call H^.qx. Fortunately, the small differences don't prevent
>>>>>>>>>>>>>> you from
>>>>>>>>>>>>>> being wrong, so I will use your word and call it an "exact
>>>>>>>>>>>>>> copy".
>>>>>>>>>>>>>> You have accepted that, when construed as an input to your H,
>>>>>>>>>>>>>> the string
>>>>>>>>>>>>>> <H^><H^> encodes a halting computation. If your H has any
>>>>>>>>>>>>>> pretensions
>>>>>>>>>>>>>> of being a halt decider, it should accept that string:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H.q0 <H^><H^> |- H.qy
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have already said that a bunch of times yet you did not
>>>>>>>>>>>>> notice
>>>>>>>>>>>>> because you diligently want to remain focused in disagreement
>>>>>>>>>>>>> mode.
>>>>>>>>>>>>
>>>>>>>>>>>> I am happy you think you've said it lots of times. I could not
>>>>>>>>>>>> find any
>>>>>>>>>>>> but I also know not to bother asking you for references.
>>>>>>>>>>>>
>>>>>>>>>>>>>> But you keep telling us that, in fact, the "exact copy" of H
>>>>>>>>>>>>>> embedded in
>>>>>>>>>>>>>> H^ transitions to H^.qn when run with just <H^><H^> on the
>>>>>>>>>>>>>> tape:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> An "exact copy" of H can't make an transitions that H can't
>>>>>>>>>>>>>> take, and in
>>>>>>>>>>>>>> fact pretty much everything you've said up until now confirms
>>>>>>>>>>>>>> that your
>>>>>>>>>>>>>> H in fact rejects the string <H^><H^>. All you effort has
>>>>>>>>>>>>>> been put to
>>>>>>>>>>>>>> explaining why the wrong answer is in fact the right one.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Like I said (and this is beyond your technical competence)
>>>>>>>>>>>>> int main() { H1(P,P) }; is the precise analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>
>>>>>>>>>>>> Ah, proof by analogy won't fly. This line
>>>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>>>> shows that your H is wrong. It's a simple as that.
>>>>>>>>>>>
>>>>>>>>>>> Not at all distinctly different computations can have different
>>>>>>>>>>> results.
>>>>>>>>>> You tell me they are the same computation.
>>>>>>>>>
>>>>>>>>> No I never ever said that.
>>>>>>>>> I ALWAYS ALWAYS SAY THAT THEY ARE DISTINCTLY DIFFERENT
>>>>>>>>> COMPUTATONS.
>>>>>>>>
>>>>>>>> Identical TMs with identical inputs are computationally
>>>>>>>> equivalent. We
>>>>>>>> know that
>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>> so the same TM (H), run with the same input (<H^><H^>), cannot
>>>>>>>> transition to the sate you say it should. One of your claims is
>>>>>>>> wrong.
>>>>>>>> (I can't possibly know which, but they can't both be ture.)
>>>>>>>>
>>>>>>>>>> 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.Just
>>>>>
>>>>> Because H is simulating Ĥ it can see what H is doing and change its
>>>>> behavior in a way that H cannot do.
>>>>>
>>>>> If the theory of computation says that this cannot occur then the
>>>>> theory
>>>>> of computation must be updated because it is occurring.
>>>>>
>>>>
>>>> As I have said, just proves that H isn't a computation, and thus not
>>>> qualified to be a decider.
>>>>
>>>
>>> What part of this makes either one or both not a computation?
>>>
>>> Because H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it can see whatever Ĥ does and change its
>>> own behavior accordingly.
>>>
>>> Because Ĥ is simulated by H it cannot see anything that H does
>>> or change its own behavior accordingly.
>>>
>>
>> Neither of those makes things not a computation. The latter is FALSE
>> because H^ includes a copy of H's algorithm in it, it know EXACTLY what
>> H is going to answer,
>
> H sees that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts because it sees Ĥ.qx transition to Ĥ.qn
None of your traces of *H* ever show it actually seeing H^(H^) ever
getting to H^.qn and returning.
Yes, H1 sees this, but not H.
This is why H answer non-Halting incorrectly.
>
> Ĥ does not see that its input halts.
Why does the copy of H i H^ see anything different then the copy that is
in H? The have the exact same code and input?
>
> You can ignore the fact that execution order makes a difference.
> This only makes you look foolish.
But in this sense it doesn't. If you are going to bake a cake, do you
have to change the recipe just because you made a pie before it instead
of a roast?
Yes, if you change the order of steps INSIDE the recipe, that will
change it, but then you are following different orders.
If your instructions aren't complete and you use something leftover from
before, yes you can get a different result, but that just says you don't
have a complete Computation, and it depends on something not in its
instructions or part of its input.
You don't seem to know the basics of Computer Programming. Do you not
make sure to initialize you variables so you don't use the random values
that the got from before?
>
>> so it CAN change its behavior to match whatever
>> the simulating decider will decide to do.
>>
>> If H doesn't do what the copy in H^ sees it will do, then THAT shows H
>> isn't a computation.
>>
>> The point that makes H not a computation is that you claim that the
>> machine represented by <H^> <H^> when given to H represents a DIFFERENT
>> machine than the H^(<H^>) that is run independently.
>>
>> That implies that H^ isn't a computation, and the only place H^ can fail
>> to be a computation is inside its copy of H, so if H^ isn't a
>> computation, then we know that H isn't.
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-09-07 11:54 +0100 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] |
| Message-ID | <8735qghd0n.fsf@bsb.me.uk> |
| In reply to | #39017 |
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. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-07 09:07 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] |
| Message-ID | <I8CdnRjxopOR76r8nZ2dnUU7-T3NnZ2d@giganews.com> |
| In reply to | #39051 |
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. How are you going to weasel out of that one to protect your ego? -- 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-07 16:31 +0100 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ] |
| Message-ID | <87mtooflmy.fsf@bsb.me.uk> |
| In reply to | #39055 |
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. > How are you going to weasel out of that one to protect your ego? I'm not sure what you think I'd want to weasel out of. I'd like you to address your primary mistake. 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. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-07 10:51 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <DOednQ8sJI_uF6r8nZ2dnUU7-TXNnZ2d@giganews.com> |
| In reply to | #39061 |
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!");
>> How are you going to weasel out of that one to protect your ego?
>
> I'm not sure what you think I'd want to weasel out of. I'd like you to
> address your primary mistake. 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.
>
--
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 01:42 +0100 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <8735qfgao5.fsf@bsb.me.uk> |
| In reply to | #39066 |
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.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-07 20:08 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <SZydnWpugKqLkKX8nZ2dnUU78d3NnZ2d@giganews.com> |
| In reply to | #39098 |
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/Ĥ.
--
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-07 21:12 -0400 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <g6UZI.3337$IO1.878@fx19.iad> |
| In reply to | #39105 |
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.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-07 20:28 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <FvqdnVkVcaQrjKX8nZ2dnUU7-LPNnZ2d@giganews.com> |
| In reply to | #39107 |
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.
--
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-07 21:55 -0400 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <hKUZI.148$ol1.140@fx42.iad> |
| In reply to | #39110 |
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.
And H^ needs to have basically identical code to H embedded in it (the
only difference is in a state we don't get to).
If you are now admitting the actual code is different, that shows that
your argument isn't valid any more.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-07 21:18 -0500 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <qaqdnaRnIMHogKX8nZ2dnUU7-N_NnZ2d@giganews.com> |
| In reply to | #39113 |
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...
> 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.
>
--
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-07 22:27 -0400 |
| Subject | Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ] |
| Message-ID | <BcVZI.26449$tA2.12435@fx02.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...
If H1 and H have the same code and get the same input then they MUST
behave the same. That is FUNDAMENTAL to how computers work.
To act different, they need some input that is different. (maybe this
master / slave relationship).
Since their formal inputs are the same, that means there is some other
input that is not a formal input that makes a difference, and thus they
fail to be a Computation, and thus not eligible to be a Decider.
You have just voided you whole argument.
H is admitted to not be a pure function of its defined inputs, thus not
eligable to be a Halt Decider.
FAIL.
(You just keep digging yourself in deeper).
>
>> And H^ needs to have basically identical code to H embedded in it (the
>> only difference is in a state we don't get to).
>>
>> If you are now admitting the actual code is different, that shows that
>> your argument isn't valid any more.
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-07 21:53 -0500 |
| Subject | H1(P,P) is a halt decider for P(P) [ Refuting Rice's Theorem ] |
| Message-ID | <5q2dnb_8xqUnuKX8nZ2dnUU7-KvNnZ2d@giganews.com> |
| In reply to | #39117 |
On 9/7/2021 9:27 PM, Richard Damon wrote:
> On 9/7/21 10:18 PM, olcott wrote:
>> On 9/7/2021 8:55 PM, Richard Damon wrote:
>>> On 9/7/21 9:28 PM, olcott wrote:
>>>> On 9/7/2021 8:12 PM, Richard Damon wrote:
>>>>> On 9/7/21 9:08 PM, olcott wrote:
>>>>>> On 9/7/2021 7:42 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/7/2021 10:31 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 9/7/2021 5:54 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 9/6/2021 8:57 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/6/2021 8:09 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 9/6/2021 7:40 PM, Ben Bacarisse wrote:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> TM at H^.qx is an "exact
>>>>>>>>>>>>>>>>> copy" of H. How can two TMs that are exact copies of each
>>>>>>>>>>>>>>>>> other make
>>>>>>>>>>>>>>>>> different transitions given the same input?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That H1 calls H means that H1 can see what H does.
>>>>>>>>>>>>>>>> The H is called by H1 means that H does not even know
>>>>>>>>>>>>>>>> that H1
>>>>>>>>>>>>>>>> exists.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> TMs don't call each other.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ creates a master slave relationship
>>>>>>>>>>>>>> between H and Ĥ.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The master can see exactly what the slave is doing.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The slave it totally unaware of the existence of the master.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The master can change its behavior on the basis of what the
>>>>>>>>>>>>>> slave does.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The slave cannot change its behavior on the basis of what the
>>>>>>>>>>>>>> master does.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thus the master slave relationship can and does cause an
>>>>>>>>>>>>>> identical
>>>>>>>>>>>>>> function with the same input to have different behavior
>>>>>>>>>>>>>> even if
>>>>>>>>>>>>>> no one
>>>>>>>>>>>>>> ever noticed this before.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Function? Have you been only pretending to be talking about
>>>>>>>>>>>>> Turing
>>>>>>>>>>>>> machines the whole time? If you were not being deceitful, your
>>>>>>>>>>>>> H (the
>>>>>>>>>>>>> TM) is wrong because
>>>>>>>>>>>>>
>>>>>>>>>>>>> H.q0 <H^><H^> |- H.qn
>>>>>>>>>>>>
>>>>>>>>>>>> No matter how much you ignore the fact that the master slave
>>>>>>>>>>>> relationship where H is the master of Ĥ causes different
>>>>>>>>>>>> behavior:
>>>>>>>>>>>>
>>>>>>>>>>>> H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>> Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>
>>>>>>>>>>>> for two identical functions with the same input, this master
>>>>>>>>>>>> slave
>>>>>>>>>>>> relationship still causes differing behavior.
>>>>>>>>>>>
>>>>>>>>>>> Functions? You used the notation of Turing machines. Were you
>>>>>>>>>>> being
>>>>>>>>>>> deceptive? I am perfectly prepared to accept that you are
>>>>>>>>>>> cheating in
>>>>>>>>>>> some way with your hidden C functions, but you can't cheat with
>>>>>>>>>>> TMs.
>>>>>>>>>>> What you said using the notation of TMs was wrong (about TMs)
>>>>>>>>>>> because
>>>>>>>>>>> identical state transition functions produce the same transitions
>>>>>>>>>>> when
>>>>>>>>>>> given identical input. So your recent admission that your H
>>>>>>>>>>> should
>>>>>>>>>>> accept the string <H^><H^> means that
>>>>>>>>>>>
>>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>>>
>>>>>>>>>>> shows your H is wrong -- on your own terms. The facts of the
>>>>>>>>>>> matter
>>>>>>>>>>> come from you.
>>>>>>>>>>>
>>>>>>>>>>> I can stop posting if you admit you have been disingenuously
>>>>>>>>>>> using
>>>>>>>>>>> the
>>>>>>>>>>> notation of TMs to talk about your dodgy C code. If you want to
>>>>>>>>>>> keep
>>>>>>>>>>> talking about TMs you need to admit you are wrong. Identical
>>>>>>>>>>> state
>>>>>>>>>>> transition functions with identical inputs always generate the
>>>>>>>>>>> same
>>>>>>>>>>> sequence of machine configurations.
>>>>>>>>>>
>>>>>>>>>> So in other words you have another shortcoming in your technical
>>>>>>>>>> knowledge this time it is directly in the field of computer
>>>>>>>>>> science on
>>>>>>>>>> not in related fields such as software engineering.
>>>>>>>>>>
>>>>>>>>>> You seem to be unaware that the TM description being simulated
>>>>>>>>>> by a
>>>>>>>>>> UTM has no access to see the internal steps of its simulator
>>>>>>>>>> and yet
>>>>>>>>>> the UTM can directly see all of the steps of the TM description
>>>>>>>>>> that
>>>>>>>>>> it is simulating.
>>>>>>>>> So you are talking about TMs after all? Please use the correct
>>>>>>>>> language. TMs don't have "functions" and don't make "calls".
>>>>>>>>> Identical state transition functions with identical inputs always
>>>>>>>>> generate the same sequence of machine configurations so, the often
>>>>>>>>> quoted property of your H^:
>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>> shows that your H is wrong.
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>>>>>>>> OutputString("Pathological self-reference error!");
>>>>>>>> }
>>>>>>>>
>>>>>>>> if (H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ != Ĥ applied to ⟨Ĥ⟩)
>>>>>>>> OutputString("Pathological self-reference error!");
>>>>>>>
>>>>>>> You need to pay attention. I can't help you if you just put your
>>>>>>> fingers in your ears and chant.
>>>>>>>
>>>>>>>>> ... You tell us that H should accept <H^><H^>
>>>>>>>>> and you tell us that the TM at H^.qx is an "exact copy" of H and
>>>>>>>>> you
>>>>>>>>> tell us that H^.qx <H^><H^> |- H^.qn. You tell us everything we
>>>>>>>>> need to
>>>>>>>>> know that you are wrong. The only thing missing is an apology
>>>>>>>>> from you
>>>>>>>>> for ignoring these helpful explanations for so long.
>>>>>>>
>>>>>>> Is there anything here you don't understand? It's not hard.
>>>>>>> Identical
>>>>>>> state transition functions always generate the same computational
>>>>>>> steps
>>>>>>> when presented with the same input.
>>>>>>>
>>>>>>
>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>> // Strachey(1965) CPL translated to C
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> When the exact analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> int main() { H1(P,P); } is examined
>>>>>>
>>>>>> When code of the x86 H1 and H is identical and their input is the same
>>>>>> yet their behavior is different then we know that something is up.
>>>>>>
>>>>>> When we examine actual fully operational code we can't simply assume
>>>>>> that we imagined the behavior incorrectly.
>>>>>>
>>>>>> That only leaves the code and the input. The input is the same 32-bit
>>>>>> integer, that only leaves the code.
>>>>>>
>>>>>> It turns out that the most plausible explanation is that the code
>>>>>> is not
>>>>>> the same. The master / slave relationship between H1/H and H/Ĥ is hard
>>>>>> coded into the full H1/H and H/Ĥ computations.
>>>>>>
>>>>>> The fact that:
>>>>>> H1 simulates P that simulates H(P,P)
>>>>>> H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ that simulates ⟨Ĥ⟩ ⟨Ĥ⟩ at Ĥ.qx
>>>>>>
>>>>>> hard codes the master / slave relationships between H1/H and H/Ĥ.
>>>>>>
>>>>>>
>>>>>
>>>>> Just means that the code does not code an actual Computation, but
>>>>> somewhere is using data that is NOT part of its formal input to make
>>>>> the
>>>>> decision.
>>>>>
>>>>
>>>> If the code is identical and the input is identical then the behavior
>>>> must be identical. If the code is not identical and the input is
>>>> identical then the behavior need not be identical.
>>>>
>>>> Different code with the same input can derive different results as a
>>>> pure function of this input.
>>>>
>>>
>>> So you admit that they have different code?
>>>
>>> I thought your claim was that H and H1 had identical code.
>>>
>>
>> int main() { H1(P,P); } specifies that H1 is in a master slave
>> relationship with H(P,P) even though H1 and H have identical code.
>>
>> The master / slave relationship specified in main() defines H1 as a
>> distinctly different computation than H.
>>
>> The exact same thing works in reverse.
>> int main() { H(P,P); } that simulates P the calls H1...
>
> If H1 and H have the same code and get the same input then they MUST
> behave the same. That is FUNDAMENTAL to how computers work.
>
int main() { H1(P,P); } simulates P that calls H(P,P)
makes H1(P,P) a different computation than H(P,P).
The functions H and H1 behave differently when invoked with inputs that
refer to themselves than when their inputs do not refer to themselves.
That explains the difference in the behavior of H1 and H.
This makes H1/H a distinctly different computation than H1/H1 or H/H.
// This also explains how this is a
// pathological self-reference decider
// that refutes Rice's Theorem
//
int main()
{
if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
OutputString("Pathological self-reference error!");
}
> To act different, they need some input that is different. (maybe this
> master / slave relationship).
>
> Since their formal inputs are the same, that means there is some other
> input that is not a formal input that makes a difference, and thus they
> fail to be a Computation, and thus not eligible to be a Decider.
>
> You have just voided you whole argument.
>
> H is admitted to not be a pure function of its defined inputs, thus not
> eligable to be a Halt Decider.
>
> FAIL.
>
> (You just keep digging yourself in deeper).
>
>>
>>> And H^ needs to have basically identical code to H embedded in it (the
>>> only difference is in a state we don't get to).
>>>
>>> If you are now admitting the actual code is different, that shows that
>>> your argument isn't valid any more.
>>>
>>
>>
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
Page 26 of 37 — ← Prev page 1 … 24 25 [26] 27 28 … 37 Next page →
Back to top | Article view | comp.theory
csiph-web