Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #36666 > unrolled thread
| Started by | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| First post | 2021-07-19 21:46 +0100 |
| Last post | 2021-07-20 14:17 -0700 |
| Articles | 20 on this page of 525 — 16 participants |
Back to article view | Back to comp.theory
Black box halt decider is NOT a partial decider Mr Flibble <flibble@reddwarf.jmc> - 2021-07-19 21:46 +0100
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-19 14:03 -0700
Re: Black box halt decider is NOT a partial decider David Brown <david.brown@hesbynett.no> - 2021-07-20 21:06 +0200
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-20 13:43 -0700
Re: Black box halt decider is NOT a partial decider Richard Damon <Richard@Damon-Family.org> - 2021-07-20 13:56 -0700
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-20 14:16 -0700
Re: Black box halt decider is NOT a partial decider Richard Damon <Richard@Damon-Family.org> - 2021-07-20 14:50 -0700
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-20 22:33 -0700
Re: Black box halt decider is NOT a partial decider Richard Damon <Richard@Damon-Family.org> - 2021-07-20 23:30 -0700
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-21 13:17 +0100
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-22 13:35 -0700
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-22 22:10 +0100
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-23 14:22 -0700
Re: Black box halt decider is NOT a partial decider Richard Damon <Richard@Damon-Family.org> - 2021-07-23 14:30 -0700
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-23 23:15 +0100
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-23 15:28 -0700
Re: Black box halt decider is NOT a partial decider André G. Isaak <agisaak@gm.invalid> - 2021-07-23 16:49 -0600
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-23 16:09 -0700
Re: Black box halt decider is NOT a partial decider Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-24 02:34 +0100
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-04 21:53 -0700
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-04 21:54 -0700
Re: Black box halt decider is NOT a partial decider Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-08-05 15:37 +0100
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-05 17:08 +0100
Re: Black box halt decider is NOT a partial decider Jeff Barnett <jbb@notatt.com> - 2021-08-05 11:41 -0600
Re: Black box halt decider is NOT a partial decider Jeff Barnett <jbb@notatt.com> - 2021-08-05 11:48 -0600
Re: Black box halt decider is NOT a partial decider Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-08-05 20:30 +0100
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-05 13:55 -0700
Re: Black box halt decider is NOT a partial decider Jeff Barnett <jbb@notatt.com> - 2021-08-05 15:51 -0600
Re: Black box halt decider is NOT a partial decider Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-08-05 23:20 +0100
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-05 13:53 -0700
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-05 22:21 +0100
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-05 15:42 -0700
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-05 15:48 -0700
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-05 15:49 -0700
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-05 15:52 -0700
Re: Black box halt decider is NOT a partial decider wij <wyniijj@gmail.com> - 2021-08-05 21:58 -0700
Re: Black box halt decider is NOT a partial decider Richard Damon <Richard@Damon-Family.org> - 2021-07-23 16:10 -0700
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-23 16:14 -0700
Re: Black box halt decider is NOT a partial decider Richard Damon <Richard@Damon-Family.org> - 2021-07-23 16:40 -0700
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-24 12:50 -0700
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-24 00:54 +0100
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-23 16:59 -0700
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 00:42 +0100
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-25 12:55 -0700
Re: Black box halt decider is NOT a partial decider Richard Damon <Richard@Damon-Family.org> - 2021-07-25 13:13 -0700
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-25 14:08 -0700
Re: Black box halt decider is NOT a partial decider André G. Isaak <agisaak@gm.invalid> - 2021-07-24 18:07 -0600
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 01:50 +0100
Re: Black box halt decider is NOT a partial decider André G. Isaak <agisaak@gm.invalid> - 2021-07-24 20:58 -0600
Re: Black box halt decider is NOT a partial decider Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-25 04:03 +0100
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 04:22 +0100
Re: Black box halt decider is NOT a partial decider Andy Walker <anw@cuboid.co.uk> - 2021-07-25 13:34 +0100
Re: Black box halt decider is NOT a partial decider Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-25 17:14 +0100
Re: Black box halt decider is NOT a partial decider Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-25 10:40 -0700
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is always correct ] olcott <NoOne@NoWhere.com> - 2021-07-25 13:10 -0500
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is always correct ] Richard Damon <Richard@Damon-Family.org> - 2021-07-25 11:31 -0700
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is always correct ] olcott <NoOne@NoWhere.com> - 2021-07-25 13:22 -0500
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is always correct ] André G. Isaak <agisaak@gm.invalid> - 2021-07-25 12:43 -0600
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is always correct ] Richard Damon <Richard@Damon-Family.org> - 2021-07-25 12:25 -0700
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is always correct ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-25 12:46 -0700
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is always correct ] Richard Damon <Richard@Damon-Family.org> - 2021-07-25 13:04 -0700
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is always correct ] Jeff Barnett <jbb@notatt.com> - 2021-07-25 16:58 -0600
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is always correct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 20:38 +0100
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 20:52 +0100
Re: Black box halt decider is NOT a partial decider Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-25 13:54 -0700
Re: Black box halt decider is NOT a partial decider [ paradox rather than contradiction ] olcott <NoOne@NoWhere.com> - 2021-07-25 22:53 -0500
Re: Black box halt decider is NOT a partial decider [ paradox rather than contradiction ] Richard Damon <Richard@Damon-Family.org> - 2021-07-25 21:40 -0700
Re: Black box halt decider is NOT a partial decider [ paradox rather than contradiction ] André G. Isaak <agisaak@gm.invalid> - 2021-07-25 23:09 -0600
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-26 09:20 -0500
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-07-26 07:40 -0700
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-26 10:09 -0600
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-26 11:41 -0500
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-26 11:00 -0600
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-26 14:40 -0500
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-07-26 15:29 -0700
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] Jeff Barnett <jbb@notatt.com> - 2021-07-26 11:16 -0600
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-26 13:57 -0500
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-26 13:55 -0600
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-26 15:34 -0500
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-26 14:53 -0600
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-07-26 16:01 -0700
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-26 19:14 -0500
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-26 18:21 -0600
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-26 20:03 -0500
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-26 19:24 -0600
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-26 20:30 -0500
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-26 20:34 -0600
Re: Black box halt decider is NOT a partial decider [ André doesn't know Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-26 22:18 -0500
Re: Black box halt decider is NOT a partial decider [ André doesn't know Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-26 21:24 -0600
Re: Black box halt decider is NOT a partial decider [ André doesn't know Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-26 22:31 -0500
Re: Black box halt decider is NOT a partial decider [ André doesn't know Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-26 21:55 -0600
Re: Black box halt decider is NOT a partial decider [ André doesn't know Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-26 23:39 -0500
Re: Black box halt decider is NOT a partial decider [ André doesn't know Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-26 22:59 -0600
Re: Black box halt decider is NOT a partial decider [ André doesn't know Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-27 10:27 -0500
Re: Black box halt decider is NOT a partial decider [ André doesn't know Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-07-26 22:22 -0700
Re: Black box halt decider is NOT a partial decider [ André doesn't know Rice's Theorem ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-27 02:42 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] olcott <NoOne@NoWhere.com> - 2021-07-27 10:24 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] Richard Damon <Richard@Damon-Family.org> - 2021-07-27 08:54 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ]( finally quit lying ) olcott <NoOne@NoWhere.com> - 2021-07-27 11:05 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ]( finally quit lying ) Richard Damon <Richard@Damon-Family.org> - 2021-07-27 09:29 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ]( attention deficit disorder ) olcott <NoOne@NoWhere.com> - 2021-07-27 12:07 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ]( attention deficit disorder ) Richard Damon <Richard@Damon-Family.org> - 2021-07-27 11:17 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ]( attention deficit disorder ) olcott <NoOne@NoWhere.com> - 2021-07-27 13:29 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ]( attention deficit disorder ) Richard Damon <Richard@Damon-Family.org> - 2021-07-27 11:47 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ]( attention deficit disorder ) olcott <NoOne@NoWhere.com> - 2021-07-27 14:10 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ]( attention deficit disorder ) Richard Damon <news.x.richarddamon@xoxy.net> - 2021-07-27 12:58 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ]( attention deficit disorder ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-28 16:23 +0100
Re: André doesn't know Rice's Theorem [ Malcolm ]( attention deficit disorder ) olcott <NoOne@NoWhere.com> - 2021-07-28 11:01 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ]( attention deficit disorder ) Richard Damon <news.x.richarddamon@xoxy.net> - 2021-07-28 09:25 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ]( attention deficit disorder ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-28 21:38 +0100
Re: André doesn't know Rice's Theorem [ Malcolm ]( attention deficit disorder ) olcott <NoOne@NoWhere.com> - 2021-07-28 16:14 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ]( attention deficit disorder ) olcott <NoOne@NoWhere.com> - 2021-07-28 16:20 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ]( attention deficit disorder ) Richard Damon <news.x.richarddamon@xoxy.net> - 2021-07-28 15:04 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ]( attention deficit disorder ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-29 00:33 +0100
Re: André doesn't know Rice's Theorem [ Malcolm ] André G. Isaak <agisaak@gm.invalid> - 2021-07-27 11:16 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] olcott <NoOne@NoWhere.com> - 2021-07-27 12:31 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] André G. Isaak <agisaak@gm.invalid> - 2021-07-27 13:42 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] olcott <NoOne@NoWhere.com> - 2021-07-27 17:20 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] olcott <NoOne@NoWhere.com> - 2021-07-27 22:11 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] André G. Isaak <agisaak@gm.invalid> - 2021-07-27 21:39 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] olcott <NoOne@NoWhere.com> - 2021-07-28 09:09 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] André G. Isaak <agisaak@gm.invalid> - 2021-07-28 09:31 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] olcott <NoOne@NoWhere.com> - 2021-07-28 11:38 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] Richard Damon <Richard@Damon-Family.org> - 2021-07-28 10:08 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ PSR Decider is fully operational ] olcott <NoOne@NoWhere.com> - 2021-07-28 13:35 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ PSR Decider is fully operational ] André G. Isaak <agisaak@gm.invalid> - 2021-07-28 12:47 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] [ PSR Decider is fully operational ] olcott <NoOne@NoWhere.com> - 2021-07-28 14:07 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ PSR Decider is fully operational ] Richard Damon <Richard@Damon-Family.org> - 2021-07-28 12:56 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ PSR Decider is fully operational ] André G. Isaak <agisaak@gm.invalid> - 2021-07-28 17:25 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] [ PSR Decider is fully operational ] olcott <NoOne@NoWhere.com> - 2021-07-28 22:25 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ PSR Decider is fully operational ] André G. Isaak <agisaak@gm.invalid> - 2021-07-28 21:36 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] [ PSR Decider is fully operational ] olcott <NoOne@NoWhere.com> - 2021-07-28 23:09 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ PSR Decider is fully operational ] Richard Damon <Richard@Damon-Family.org> - 2021-07-28 21:50 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ PSR Decider is fully operational ] olcott <NoOne@NoWhere.com> - 2021-07-28 23:57 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ PSR Decider is fully operational ] André G. Isaak <agisaak@gm.invalid> - 2021-07-28 23:10 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] [ PSR Decider is fully operational ] olcott <NoOne@NoWhere.com> - 2021-07-29 13:07 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ PSR Decider is fully operational ] Richard Damon <Richard@Damon-Family.org> - 2021-07-29 11:52 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ PSR Decider is fully operational ] André G. Isaak <agisaak@gm.invalid> - 2021-07-29 13:52 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] [ PSR Decider is fully operational ] Richard Damon <Richard@Damon-Family.org> - 2021-07-28 22:35 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] André G. Isaak <agisaak@gm.invalid> - 2021-07-28 12:40 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] [ self-contradiction must be treated differently ] olcott <NoOne@NoWhere.com> - 2021-07-28 15:06 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ self-contradiction must be treated differently ] Richard Damon <news.x.richarddamon@xoxy.net> - 2021-07-28 13:35 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ self-contradiction must be treated differently ] André G. Isaak <agisaak@gm.invalid> - 2021-07-28 17:36 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] [ self-contradiction must be treated differently ] olcott <NoOne@NoWhere.com> - 2021-07-28 22:51 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ self-contradiction must be treated differently ] Richard Damon <Richard@Damon-Family.org> - 2021-07-28 21:08 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ self-contradiction must be treated differently ] André G. Isaak <agisaak@gm.invalid> - 2021-07-28 22:15 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] [ self-contradiction must be treated differently ] olcott <NoOne@NoWhere.com> - 2021-07-28 23:31 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ self-contradiction must be treated differently ] André G. Isaak <agisaak@gm.invalid> - 2021-07-28 23:00 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] [ self-contradiction must be treated differently ] olcott <NoOne@NoWhere.com> - 2021-07-29 12:39 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ self-contradiction must be treated differently ] Richard Damon <Richard@Damon-Family.org> - 2021-07-29 12:15 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ self-contradiction must be treated differently ] André G. Isaak <agisaak@gm.invalid> - 2021-07-29 13:50 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] [ self-contradiction must be treated differently ] Richard Damon <Richard@Damon-Family.org> - 2021-07-28 22:18 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-29 13:15 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <Richard@Damon-Family.org> - 2021-07-29 12:25 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] André G. Isaak <agisaak@gm.invalid> - 2021-07-29 13:55 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-29 17:50 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] André G. Isaak <agisaak@gm.invalid> - 2021-07-29 16:58 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-29 18:27 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] André G. Isaak <agisaak@gm.invalid> - 2021-07-29 18:25 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-29 19:54 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <news.x.richarddamon@xoxy.net> - 2021-07-29 18:08 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] André G. Isaak <agisaak@gm.invalid> - 2021-07-29 19:25 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-29 23:34 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <Richard@Damon-Family.org> - 2021-07-29 22:44 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-30 20:42 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <Richard@Damon-Family.org> - 2021-07-30 18:57 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-30 21:08 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <Richard@Damon-Family.org> - 2021-07-30 20:54 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-31 09:14 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] wij <wyniijj@gmail.com> - 2021-07-31 08:02 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-31 10:20 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <Richard@Damon-Family.org> - 2021-07-31 08:41 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-31 12:00 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <Richard@Damon-Family.org> - 2021-07-31 11:25 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-31 13:52 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <Richard@Damon-Family.org> - 2021-07-31 12:14 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-31 14:41 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <Richard@Damon-Family.org> - 2021-07-31 12:54 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-31 15:39 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <Richard@Damon-Family.org> - 2021-07-31 15:11 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <news.x.richarddamon@xoxy.net> - 2021-07-31 15:37 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <Richard@Damon-Family.org> - 2021-07-31 08:26 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-31 11:35 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <Richard@Damon-Family.org> - 2021-07-31 11:31 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-31 13:57 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <Richard@Damon-Family.org> - 2021-07-31 12:23 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ][ How can H ignore own behavior? ] olcott <NoOne@NoWhere.com> - 2021-07-31 14:52 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ][ How can H ignore own behavior? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-31 13:02 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ][ How can H ignore own behavior? ] olcott <NoOne@NoWhere.com> - 2021-07-31 15:43 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ][ How can H ignore own behavior? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-31 15:18 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] André G. Isaak <agisaak@gm.invalid> - 2021-07-30 08:54 -0600
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] olcott <NoOne@NoWhere.com> - 2021-07-30 10:58 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <Richard@Damon-Family.org> - 2021-07-30 13:23 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ] Richard Damon <news.x.richarddamon@xoxy.net> - 2021-07-29 16:15 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] Richard Damon <Richard@Damon-Family.org> - 2021-07-28 09:34 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-28 02:41 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] olcott <NoOne@NoWhere.com> - 2021-07-28 08:56 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] Richard Damon <Richard@Damon-Family.org> - 2021-07-28 09:37 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-28 22:04 +0100
Re: André doesn't know Rice's Theorem [ Malcolm ] olcott <NoOne@NoWhere.com> - 2021-07-28 16:22 -0500
Re: André doesn't know Rice's Theorem [ Malcolm ] Richard Damon <news.x.richarddamon@xoxy.net> - 2021-07-28 15:06 -0700
Re: André doesn't know Rice's Theorem [ Malcolm ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-28 21:54 +0100
Re: André doesn't know Rice's Theorem [ Malcolm ] Jeff Barnett <jbb@notatt.com> - 2021-07-27 11:21 -0600
Re: Black box halt decider is NOT a partial decider [ André doesn't know Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-07-26 21:17 -0700
Re: Black box halt decider is NOT a partial decider [ André doesn't know Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-07-26 20:25 -0700
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-07-26 19:36 -0700
Re: Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-07-26 18:03 -0700
Re: Black box halt decider is NOT a partial decider Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-25 21:28 +0100
Re: Black box halt decider is NOT a partial decider Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-25 21:46 +0100
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 23:42 +0100
Re: Black box halt decider is NOT a partial decider Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-26 01:08 +0100
Re: Black box halt decider is NOT a partial decider Richard Damon <Richard@Damon-Family.org> - 2021-07-25 18:20 -0700
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is correct ] olcott <NoOne@NoWhere.com> - 2021-07-26 09:32 -0500
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is correct ] Richard Damon <Richard@Damon-Family.org> - 2021-07-26 07:57 -0700
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is correct ] André G. Isaak <agisaak@gm.invalid> - 2021-07-26 09:57 -0600
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is correct ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-27 02:17 +0100
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is correct ] olcott <NoOne@NoWhere.com> - 2021-07-26 20:41 -0500
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is correct ] Richard Damon <Richard@Damon-Family.org> - 2021-07-26 19:57 -0700
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is correct ] olcott <NoOne@NoWhere.com> - 2021-07-26 09:38 -0500
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is correct ] Richard Damon <Richard@Damon-Family.org> - 2021-07-26 08:03 -0700
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is correct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-27 00:48 +0100
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is correct ] olcott <NoOne@NoWhere.com> - 2021-07-26 20:06 -0500
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is correct ] Richard Damon <Richard@Damon-Family.org> - 2021-07-26 19:40 -0700
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is correct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-28 22:44 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] olcott <NoOne@NoWhere.com> - 2021-07-28 17:08 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] Richard Damon <Richard@Damon-Family.org> - 2021-07-28 15:22 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] olcott <NoOne@NoWhere.com> - 2021-07-28 18:21 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] Richard Damon <Richard@Damon-Family.org> - 2021-07-28 20:52 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-29 00:22 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] olcott <NoOne@NoWhere.com> - 2021-07-28 18:35 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-29 01:58 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] olcott <NoOne@NoWhere.com> - 2021-07-28 20:54 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] Richard Damon <Richard@Damon-Family.org> - 2021-07-28 20:56 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 01:30 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] olcott <NoOne@NoWhere.com> - 2021-07-29 20:00 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] Richard Damon <news.x.richarddamon@xoxy.net> - 2021-07-29 18:11 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 02:52 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] olcott <NoOne@NoWhere.com> - 2021-07-29 21:08 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 12:39 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] olcott <NoOne@NoWhere.com> - 2021-07-30 09:38 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 20:30 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] olcott <NoOne@NoWhere.com> - 2021-07-29 21:28 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] Richard Damon <Richard@Damon-Family.org> - 2021-07-29 19:38 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 13:39 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] olcott <NoOne@NoWhere.com> - 2021-07-30 09:54 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 20:58 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] olcott <NoOne@NoWhere.com> - 2021-07-30 20:16 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-31 23:08 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] olcott <NoOne@NoWhere.com> - 2021-07-31 21:20 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-01 11:54 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-01 05:12 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-01 13:41 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-01 07:25 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-01 16:30 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-01 11:41 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-01 20:26 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] olcott <NoOne@NoWhere.com> - 2021-08-01 14:45 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Richard Damon <Richard@Damon-Family.org> - 2021-08-01 13:28 -0700
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn [ succinct ] olcott <NoOne@NoWhere.com> - 2021-08-01 11:02 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ][ GIGO ] olcott <NoOne@NoWhere.com> - 2021-08-01 10:02 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ][ GIGO ] Richard Damon <Richard@Damon-Family.org> - 2021-08-01 08:21 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ][ GIGO ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-01 17:00 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ][ GIGO ] olcott <NoOne@NoWhere.com> - 2021-08-04 10:48 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ][ GIGO ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-04 19:51 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ][ GIGO ] olcott <NoOne@NoWhere.com> - 2021-08-04 17:31 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ][ GIGO ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-05 00:23 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ][ GIGO ] olcott <NoOne@NoWhere.com> - 2021-08-04 22:33 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ][ GIGO ] Richard Damon <Richard@Damon-Family.org> - 2021-08-04 22:56 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ][ GIGO ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-05 23:12 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ][ GIGO ] olcott <NoOne@NoWhere.com> - 2021-08-05 20:17 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ][ GIGO ] Richard Damon <Richard@Damon-Family.org> - 2021-08-05 20:30 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ][ GIGO ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-06 03:36 +0100
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-05 21:50 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-08 01:34 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ][ GIGO ] Richard Damon <Richard@Damon-Family.org> - 2021-08-04 19:05 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] olcott <NoOne@NoWhere.com> - 2021-08-01 09:45 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Richard Damon <Richard@Damon-Family.org> - 2021-08-01 08:24 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] olcott <NoOne@NoWhere.com> - 2021-08-01 22:45 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Richard Damon <Richard@Damon-Family.org> - 2021-08-01 22:12 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-02 20:10 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] olcott <NoOne@NoWhere.com> - 2021-08-02 15:53 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-03 01:11 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] olcott <NoOne@NoWhere.com> - 2021-08-02 19:55 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-03 02:45 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] olcott <NoOne@NoWhere.com> - 2021-08-02 21:11 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Richard Damon <Richard@Damon-Family.org> - 2021-08-02 21:57 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-04 13:53 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] olcott <NoOne@NoWhere.com> - 2021-08-04 11:15 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-04 20:22 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] olcott <NoOne@NoWhere.com> - 2021-08-04 17:38 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-05 00:22 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] olcott <NoOne@NoWhere.com> - 2021-08-04 22:18 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Richard Damon <Richard@Damon-Family.org> - 2021-08-04 23:05 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-05 02:02 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] olcott <NoOne@NoWhere.com> - 2021-08-05 07:07 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Richard Damon <Richard@Damon-Family.org> - 2021-08-05 20:35 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-05 23:15 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] olcott <NoOne@NoWhere.com> - 2021-08-05 20:48 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-06 03:35 +0100
Page 6 conclusively proves that H(P,P)==0 is correct. olcott <NoOne@NoWhere.com> - 2021-08-05 21:46 -0500
Re: Page 6 conclusively proves that H(P,P)==0 is correct. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-08 01:38 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Richard Damon <Richard@Damon-Family.org> - 2021-08-05 22:01 -0500
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-05 22:13 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Richard Damon <Richard@Damon-Family.org> - 2021-08-05 22:29 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Richard Damon <Richard@Damon-Family.org> - 2021-08-04 20:21 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] olcott <NoOne@NoWhere.com> - 2021-08-03 22:23 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] Richard Damon <Richard@Damon-Family.org> - 2021-08-03 21:44 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] André G. Isaak <agisaak@gm.invalid> - 2021-08-03 21:56 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] olcott <NoOne@NoWhere.com> - 2021-08-03 23:00 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] wij <wyniijj@gmail.com> - 2021-08-03 21:12 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] André G. Isaak <agisaak@gm.invalid> - 2021-08-03 22:16 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] olcott <NoOne@NoWhere.com> - 2021-08-03 23:25 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] André G. Isaak <agisaak@gm.invalid> - 2021-08-03 22:36 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] olcott <NoOne@NoWhere.com> - 2021-08-03 23:38 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] olcott <NoOne@NoWhere.com> - 2021-08-03 23:55 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] André G. Isaak <agisaak@gm.invalid> - 2021-08-03 23:36 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] olcott <NoOne@NoWhere.com> - 2021-08-04 10:14 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] Richard Damon <Richard@Damon-Family.org> - 2021-08-04 21:05 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-04 07:13 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ]( Honest Dialogue ) olcott <NoOne@NoWhere.com> - 2021-08-04 10:11 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] Richard Damon <Richard@Damon-Family.org> - 2021-08-04 20:29 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] Richard Damon <Richard@Damon-Family.org> - 2021-08-03 22:35 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-04 19:37 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] olcott <NoOne@NoWhere.com> - 2021-08-04 15:37 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-04 23:23 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] olcott <NoOne@NoWhere.com> - 2021-08-04 22:37 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] Richard Damon <Richard@Damon-Family.org> - 2021-08-04 22:48 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-05 23:14 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] olcott <NoOne@NoWhere.com> - 2021-08-05 20:21 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] Richard Damon <Richard@Damon-Family.org> - 2021-08-05 20:41 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ Only Inputs Count ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-06 03:36 +0100
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-05 21:54 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Richard Damon <Richard@Damon-Family.org> - 2021-08-05 22:37 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-05 22:44 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Richard Damon <news.x.richarddamon@xoxy.net> - 2021-08-05 22:51 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-08 01:34 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-09 17:32 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Richard Damon <Richard@Damon-Family.org> - 2021-08-09 21:14 -0400
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-11 01:42 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-10 19:46 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-10 20:06 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-11 02:41 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-10 20:53 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-11 03:26 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-10 21:40 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-11 16:04 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-11 10:10 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-11 10:15 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-12 00:04 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-11 18:16 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-12 02:20 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-11 21:03 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-12 21:09 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben's key param agreement ] olcott <NoOne@NoWhere.com> - 2021-08-11 21:08 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Jeff Barnett <jbb@notatt.com> - 2021-08-11 17:32 -0600
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-11 18:40 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Jeff Barnett <jbb@notatt.com> - 2021-08-11 23:11 -0600
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-12 01:36 -0700
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-12 07:24 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-12 08:40 -0700
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-12 10:50 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-13 01:58 -0700
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-13 08:30 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Richard Damon <Richard@Damon-Family.org> - 2021-08-12 22:01 -0400
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-12 16:15 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-12 10:29 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. (fixed type) olcott <NoOne@NoWhere.com> - 2021-08-10 21:42 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. // fixed typo (link added) olcott <NoOne@NoWhere.com> - 2021-08-10 23:36 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Is Ben a Liar or simply woefully ignorant? ] olcott <NoOne@NoWhere.com> - 2021-08-11 09:28 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Is Ben a Liar or simply woefully ignorant? ] olcott <NoOne@NoWhere.com> - 2021-08-11 09:58 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Is Ben a Liar or simply woefully ignorant? ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-11 17:10 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Is Ben a Liar or simply woefully ignorant? ] olcott <NoOne@NoWhere.com> - 2021-08-11 11:52 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Is Ben a Liar or simply woefully ignorant? ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-12 01:35 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] olcott <NoOne@NoWhere.com> - 2021-08-11 19:40 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-11 19:44 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-12 21:00 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-12 15:36 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-12 22:10 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-12 16:26 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-13 00:00 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-12 18:28 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-12 18:33 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-13 01:26 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-12 19:49 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-13 02:05 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-12 20:19 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) Richard Damon <Richard@Damon-Family.org> - 2021-08-12 21:44 -0400
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-13 02:49 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-12 21:20 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-13 10:01 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-13 08:35 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-13 21:20 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-13 15:56 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-13 22:28 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-13 16:33 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-13 23:06 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-13 17:12 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-13 23:25 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-13 17:47 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. "dklei...@gmail.com" <dkleinecke@gmail.com> - 2021-08-13 16:54 -0700
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-13 22:35 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-14 13:22 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) Richard Damon <Richard@Damon-Family.org> - 2021-08-13 20:41 -0400
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (another typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-13 17:24 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-13 01:53 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-12 20:14 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-13 02:51 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-12 21:21 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) Richard Damon <Richard@Damon-Family.org> - 2021-08-12 22:57 -0400
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-13 09:53 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) olcott <NoOne@NoWhere.com> - 2021-08-13 08:31 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) Richard Damon <Richard@Damon-Family.org> - 2021-08-12 21:38 -0400
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Ben accepts one point? ] (typo fixed ) Richard Damon <Richard@Damon-Family.org> - 2021-08-12 22:09 -0400
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Is Ben a Liar or simply woefully ignorant? ] olcott <NoOne@NoWhere.com> - 2021-08-11 14:53 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Is Ben a Liar or simply woefully ignorant? ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-12 01:01 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Is Ben a Liar or simply woefully ignorant? ] olcott <NoOne@NoWhere.com> - 2021-08-11 19:26 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Is Ben a Liar or simply woefully ignorant? ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-12 02:28 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. olcott <NoOne@NoWhere.com> - 2021-08-11 18:07 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-12 02:35 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Halting Problem is solved for Ĥ on ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-08-11 21:14 -0500
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Is Ben a Liar or simply woefully ignorant? ] Richard Damon <Richard@Damon-Family.org> - 2021-08-12 07:49 -0400
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-10 23:40 -0700
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-11 11:48 +0100
Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-11 04:09 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] olcott <NoOne@NoWhere.com> - 2021-08-01 22:56 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Richard Damon <Richard@Damon-Family.org> - 2021-08-01 22:13 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-02 20:11 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Richard Damon <Richard@Damon-Family.org> - 2021-08-04 20:38 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] Richard Damon <news.x.richarddamon@xoxy.net> - 2021-07-31 15:47 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-07-28 21:52 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 02:18 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-07-29 21:05 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 12:00 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-07-30 09:35 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 20:22 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-07-30 19:42 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Richard Damon <news.x.richarddamon@xoxy.net> - 2021-07-30 18:27 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-31 22:54 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-07-31 16:57 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Richard Damon <news.x.richarddamon@xoxy.net> - 2021-07-31 15:48 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-01 11:39 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-08-01 22:17 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Richard Damon <Richard@Damon-Family.org> - 2021-08-01 20:36 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-02 17:31 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-08-02 13:16 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-08-02 13:25 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-03 01:20 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-08-02 20:01 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Richard Damon <Richard@Damon-Family.org> - 2021-08-02 22:03 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-02 22:29 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-08-03 08:00 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-03 07:33 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-08-03 10:21 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) André G. Isaak <agisaak@gm.invalid> - 2021-08-03 11:11 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-08-03 14:26 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) André G. Isaak <agisaak@gm.invalid> - 2021-08-03 14:08 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-08-03 15:47 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) André G. Isaak <agisaak@gm.invalid> - 2021-08-03 14:56 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-08-03 16:03 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) André G. Isaak <agisaak@gm.invalid> - 2021-08-03 15:26 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-08-03 16:50 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) André G. Isaak <agisaak@gm.invalid> - 2021-08-03 16:35 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-08-03 19:42 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) André G. Isaak <agisaak@gm.invalid> - 2021-08-03 19:00 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-08-03 20:24 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) André G. Isaak <agisaak@gm.invalid> - 2021-08-03 21:00 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-08-03 22:30 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) André G. Isaak <agisaak@gm.invalid> - 2021-08-03 22:00 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-08-03 23:03 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Richard Damon <Richard@Damon-Family.org> - 2021-08-03 22:08 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-04 10:48 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Richard Damon <Richard@Damon-Family.org> - 2021-08-03 21:52 -0600
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? )[ Only: H(P,P)==0 ] olcott <NoOne@NoWhere.com> - 2021-08-04 09:38 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? )[ Only: H(P,P)==0 ] Richard Damon <Richard@Damon-Family.org> - 2021-08-04 20:43 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? )[ Only: H(P,P)==0 ][ André refuses an honest dialogue ] olcott <NoOne@NoWhere.com> - 2021-08-05 09:04 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? )[ Only: H(P,P)==0 ][ André refuses an honest dialogue ] Richard Damon <Richard@Damon-Family.org> - 2021-08-05 20:41 -0500
H(P,P)==0 is proven to be correct [ André refuses an honest dialogue ] olcott <NoOne@NoWhere.com> - 2021-08-05 09:07 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Richard Damon <Richard@Damon-Family.org> - 2021-08-03 07:36 -0700
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Andy Walker <anw@cuboid.co.uk> - 2021-07-31 23:53 +0100
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) olcott <NoOne@NoWhere.com> - 2021-07-31 21:47 -0500
Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) Richard Damon <Richard@Damon-Family.org> - 2021-07-31 20:07 -0700
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is correct ] olcott <NoOne@NoWhere.com> - 2021-07-26 09:46 -0500
Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is correct ] Richard Damon <Richard@Damon-Family.org> - 2021-07-26 08:05 -0700
Re: Black box halt decider is NOT a partial decider Andy Walker <anw@cuboid.co.uk> - 2021-07-25 21:32 +0100
Re: Black box halt decider is NOT a partial decider Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-25 15:10 +0100
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 15:26 +0100
Re: Black box halt decider is NOT a partial decider Andy Walker <anw@cuboid.co.uk> - 2021-07-25 16:56 +0100
Re: Black box halt decider is NOT a partial decider Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-25 23:21 +0100
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 23:44 +0100
Re: Black box halt decider is NOT a partial decider Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-25 17:18 +0100
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 19:15 +0100
Re: Black box halt decider is NOT a partial decider Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-25 23:04 +0100
Re: Black box halt decider is NOT a partial decider Alan Mackenzie <acm@muc.de> - 2021-07-26 11:06 +0000
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-26 14:17 +0100
Re: Black box halt decider is NOT a partial decider Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-26 06:29 -0700
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-26 14:32 +0100
Re: Black box halt decider is NOT a partial decider Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-26 07:08 -0700
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-26 15:36 +0100
Re: Black box halt decider is NOT a partial decider Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-26 08:32 -0700
Re: Black box halt decider is NOT a partial decider Andy Walker <anw@cuboid.co.uk> - 2021-07-26 18:08 +0100
Re: Black box halt decider is NOT a partial decider Jeff Barnett <jbb@notatt.com> - 2021-07-26 11:38 -0600
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-26 19:31 +0100
Re: Black box halt decider is NOT a partial decider Jeff Barnett <jbb@notatt.com> - 2021-07-26 13:42 -0600
Re: Black box halt decider is NOT a partial decider Peter <peterxpercival@hotmail.com> - 2021-07-26 22:49 +0100
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-26 23:57 +0100
Re: Black box halt decider is NOT a partial decider Peter <peterxpercival@hotmail.com> - 2021-07-27 13:47 +0100
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-26 23:16 +0100
Re: Black box halt decider is NOT a partial decider Andy Walker <anw@cuboid.co.uk> - 2021-07-27 12:10 +0100
Re: Black box halt decider is NOT a partial decider Jeff Barnett <jbb@notatt.com> - 2021-07-27 12:48 -0600
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-28 17:25 +0100
Re: Black box halt decider is NOT a partial decider Jeff Barnett <jbb@notatt.com> - 2021-07-28 11:32 -0600
Re: Black box halt decider is NOT a partial decider Peter <peterxpercival@hotmail.com> - 2021-07-26 15:13 +0100
Re: Black box halt decider is NOT a partial decider wij <wyniijj@gmail.com> - 2021-07-24 20:35 -0700
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 10:54 +0100
Re: Black box halt decider is NOT a partial decider wij <wyniijj@gmail.com> - 2021-07-25 07:10 -0700
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-25 12:56 -0700
Re: Black box halt decider is NOT a partial decider Richard Damon <Richard@Damon-Family.org> - 2021-07-22 14:52 -0700
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-23 14:20 -0700
Re: Black box halt decider is NOT a partial decider Richard Damon <Richard@Damon-Family.org> - 2021-07-23 14:34 -0700
Re: Black box halt decider is NOT a partial decider Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-21 05:46 -0700
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-21 14:12 +0100
Re: Black box halt decider is NOT a partial decider Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-21 06:27 -0700
Re: Black box halt decider is NOT a partial decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-21 16:28 +0100
Re: Black box halt decider is NOT a partial decider Jeff Barnett <jbb@notatt.com> - 2021-07-20 15:14 -0600
Re: Black box halt decider is NOT a partial decider "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-20 14:17 -0700
Page 22 of 27 — ← Prev page 1 … 20 21 [22] 23 24 … 27 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-08-12 07:49 -0400 |
| Subject | Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Is Ben a Liar or simply woefully ignorant? ] |
| Message-ID | <PU7RI.916$xM2.307@fx22.iad> |
| In reply to | #37787 |
On 8/11/21 10:28 AM, olcott wrote: > On 8/10/2021 9:26 PM, Ben Bacarisse wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> On 8/10/2021 8:41 PM, Ben Bacarisse wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> On 8/10/2021 7:42 PM, Ben Bacarisse wrote: >>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>> >>>>>>> On 8/7/2021 7:34 PM, Ben Bacarisse wrote: >>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>> >>>>>>>>> On 8/5/2021 9:36 PM, Ben Bacarisse wrote: >>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>> >>>>>>>>>>> On 8/5/2021 5:14 PM, Ben Bacarisse wrote: >>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>> >>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>> >>>>>>>>>>>>> The question is not: Does Ĥ halt on its input? >>>>>>>>>>>> Yes it is. >>>>>>>>>>> >>>>>>>>>>> The question is: >>>>>>>>>>> Does the Ĥ specified by the first ⟨Ĥ⟩ halt on its input ⟨Ĥ⟩ ? >>>>>>>>>>> The ansswer to this question is provably no! >>>>>>>>>> The question is: does Ĥ applied to ⟨Ĥ⟩ halt. It does: >>>>>>>>>> >>>>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn THIS IS NOT A CONTRADICTION >>>>>>>>>> Indeed. There is no contradiction. Just an Ĥ that does not >>>>>>>>>> meet Linz >>>>>>>>>> spec. >>>>>>>>> >>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. >>>>>>>>> Because it is correct it meets the Linz spec. >>>>>>>> I find it startling that you think that, but then it seems you >>>>>>>> don't yet >>>>>>>> know what the key words mean: >>>>>>>> >>>>>>>>> if M applied to wM does not halt >>>>>>>>> means if the execution of the machine of the first ⟨Ĥ⟩ on its >>>>>>>>> input of >>>>>>>>> the seocond ⟨Ĥ⟩ does not halt then ⊢* Ĥ.qn >>>>>>>> No. Would you like to know "what M applied to wM does not halt" >>>>>>>> means? >>>>>>>> Do you need help to see that "Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn" is clearly a >>>>>>>> case of "M >>>>>>>> applied to wM halts"? >>>>>>> >>>>>>> the Turing machine halting problem. Simply stated, the >>>>>>> problem >>>>>>> is: given the description of a Turing machine M and an >>>>>>> input w, >>>>>>> does M, when started in the initial configuration q0w, >>>>>>> perform a >>>>>>> computation that eventually halts? (Linz:1990:317). >>>>>> Yes. I was offering to help you understand the key words in that >>>>>> text. >>>>>> >>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞ >>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn >>>>>> You've missed off the key lines yet again. Is that deliberate? They >>>>>> are the lines that show you are wrong so I am suspicious that you >>>>>> keep >>>>>> omitting them. >>>>>> >>>>>>> When Ĥ is applied to ⟨Ĥ⟩ the description of the Turing Machine >>>>>>> and its >>>>>>> input are specified as: ⟨Ĥ⟩ ⟨Ĥ⟩ for the embedded halt decider at >>>>>>> Ĥ.qx. >>>>>> Ungrammatical. >>>>>> >>>>>>> When Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn this is not a final state of the simulated >>>>>>> input it is a final state of the executed Ĥ. >>>>>> Yes. You don't seem to know why that's wrong. >>>>> >>>>> What is your basis for believing that is wrong? >>>> Ah, a question about what I'm saying. I can help there. The basis is >>>> what Linz says about Ĥ. He says that (translating to your notation) >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn >>>> should be the case "if Ĥ applied to ⟨Ĥ⟩ does not halt". But, as you >>>> can >>>> see, your Ĥ does halt when applied to ⟨Ĥ⟩ (qn is a halting or final >>>> state). Your Ĥ is not doing what it should in this one crucial case. >>>> >>> >>> the Turing machine halting problem. Simply stated, the problem >>> is: given the description of a Turing machine M and an input w, >>> does M, when started in the initial configuration q0w, perform a >>> computation that eventually halts? (Linz:1990:317). >> >> and so on. Same old stuff. >> > > When the challenge to support one's assertion with reasoning is simply > ignored as you are ignoring it right now one can reasonably construe a > deceptive intent. > > -- the Turing machine halting problem. Simply stated, the problem > -- is: given the description of a Turing machine M and an input w, > -- does M, when started in the initial configuration q0w, perform a > -- computation that eventually halts? (Linz:1990:317). > > PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H > PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H > PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H > PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H > > The input to H will be the description (encoded in some form) of M, say > WM, as well as the input w. (Linz:1990:318) > > H.q0 WM w ⊢* H.qn > if M applied to W does not halt. > > becomes > > H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn > if Ĥ applied to ⟨Ĥ⟩ does not halt. > > > Pages of the Linz text to verify the above quotes in their full context: > http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf > > M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx > M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx > M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx > M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx > > Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn > if M applied to wM does not halt > > When we know that M refers to the Turing machine specified by the first > wM then when Ĥ transitions to its final state of Ĥ.qn there is no direct > contradiction formed. > > Can you admit when you are wrong when you really are wrong? > Can you admit when you are wrong when you really are wrong? > Can you admit when you are wrong when you really are wrong? > Can you admit when you are wrong when you really are wrong? > > if M applied to wM does not halt (see above for definition of M) > means when the Turing machine of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt. > > Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn > Ĥ.qx correctly transitions to its final state when the Ĥ.qx acts as a > UTM and simulates ⟨Ĥ⟩ ⟨Ĥ⟩ and determines that this input never halts. > > https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation > > But that input is also supposed to be the representation of H^, as that is basic question being asked in the proof, can H give the right answer for predicting what the machine H^(<H^>) does. Since from the run of H^, we see that starting at H^.q0 <H^> we end up at the halting state of H^.qn, we KNOW that H^(<H^>) is a Halting computation, and thus that the input given to H represents a Halting computation, thus the fact that H.q0 <H^> <H^> ends up at H.qn is a wrong answer. The fact that H's simulation did not reach the halting state is irrelevant, since H did not complete its simulation but aborted it. It is a FACT that if we continue simulating that exact same computation, it WILL stop, as was show by the actual running of the actual machine represented by that input. Either the input to H represents that same machine, and thus we know it will act the same, or the machines were setup wrong an the proof is void. You don't seem to understand that the fact that H doesn't reach the final halting state before it aborts doesn't actually prove anything. Only a truely pure simulator that never reaches a halting state proves that, but a truely pure simulator is one that NEVER stops until it does reach the halting state of the machine it is simulating. A machine tht doesn't stop its simulation until it does stop its simulation doesn't meet that definition. If you think so, please play your local athorites for all the red lights you didn't stop at until you did, as obviously you never did.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2021-08-10 23:40 -0700 |
| Subject | Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. |
| Message-ID | <00857ac3-32b7-46c5-a5a7-9cd6f6ec1561n@googlegroups.com> |
| In reply to | #37773 |
On Wednesday, 11 August 2021 at 02:41:04 UTC+1, Ben Bacarisse wrote: > > It is trivial to write a TM J from which a Ĵ can be derived that has the > properties of your Ĥ. Every student learning this material for the first > time should be able to come up with one a few minutes. There is nothing > interesting about a TM with > > Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qn > if Ĵ applied to ⟨Ĵ⟩ halts. > It's trivial to write a J with these characteristics. But that doesn't mean that every such J will be trivial or uninteresting. It just won't be a counter-example to an established theorem.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-08-11 11:48 +0100 |
| Subject | Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. |
| Message-ID | <87zgtogsus.fsf@bsb.me.uk> |
| In reply to | #37781 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Wednesday, 11 August 2021 at 02:41:04 UTC+1, Ben Bacarisse wrote: >> >> It is trivial to write a TM J from which a Ĵ can be derived that has the >> properties of your Ĥ. Every student learning this material for the first >> time should be able to come up with one a few minutes. There is nothing >> interesting about a TM with >> >> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qn >> if Ĵ applied to ⟨Ĵ⟩ halts. >> > It's trivial to write a J with these characteristics. > But that doesn't mean that every such J will be trivial or > uninteresting. It just won't be a counter-example to an established > theorem. That's an odd thing to point out, but of course it's true. Deciders for all sort of sets might have this property: shortest paths through a network, numbered digits of pi, integer factorisations... Some will and some won't, but a very large proportion of interesting and non-trivial TMs will have this property. That's probably not what you meant though, but I don't know what you are hinting at. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2021-08-11 04:09 -0700 |
| Subject | Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. |
| Message-ID | <3dde3011-0e46-45b0-87aa-1b7889506d0bn@googlegroups.com> |
| In reply to | #37784 |
On Wednesday, 11 August 2021 at 11:48:14 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > On Wednesday, 11 August 2021 at 02:41:04 UTC+1, Ben Bacarisse wrote: > >> > >> It is trivial to write a TM J from which a Ĵ can be derived that has the > >> properties of your Ĥ. Every student learning this material for the first > >> time should be able to come up with one a few minutes. There is nothing > >> interesting about a TM with > >> > >> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qn > >> if Ĵ applied to ⟨Ĵ⟩ halts. > >> > > It's trivial to write a J with these characteristics. > > But that doesn't mean that every such J will be trivial or > > uninteresting. It just won't be a counter-example to an established > > theorem. > That's an odd thing to point out, but of course it's true. Deciders for > all sort of sets might have this property: shortest paths through a > network, numbered digits of pi, integer factorisations... Some will and > some won't, but a very large proportion of interesting and non-trivial > TMs will have this property. > > That's probably not what you meant though, but I don't know what you are > hinting at. > No, that's exactly what I meant. You can't build a halt decider that decides every instance correctly. But you can build an interesting TM that has lesser ambitions. Which is what some people should maybe be focusing on.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-08-01 22:56 -0500 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] |
| Message-ID | <ktidnbuI6J5g8Zr8nZ2dnUU7-XfNnZ2d@giganews.com> |
| In reply to | #37443 |
On 8/1/2021 5:54 AM, Ben Bacarisse wrote: > olcott <NoOne@NoWhere.com> writes: > >> On 7/31/2021 5:08 PM, Ben Bacarisse wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> On 7/30/2021 2:58 PM, Ben Bacarisse wrote: >>>>> olcott <NoOne@NoWhere.com> writes: >>>>> >>>>>> On 7/30/2021 7:39 AM, Ben Bacarisse wrote: >>>>> >>>>>>> Any chance you will now say if >>>>>>> >>>>>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) >>>>>>> >>>>>>> transitions to Ĥ.qn or Ĥ.qy? If you find this question difficult, >>>>>>> please ask for some help in understanding it. >>>>>> >>>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn >>>>> >>>>> An answer. Thank you. >>>>> >>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>> >>>>> For Ĥ to be "exactly and precisely as in Linz" this, then, is the clause >>>>> that applies to your H and Ĥ: >>>> >>>> There is no H in the relevant last paragraph of the Linz proof that >>>> forms the basis for the Linz conclusion. >>> Distraction. Everything you ignore below is about the proof and refers >>> only to Ĥ. >>> >>>>>>>>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn >>>>>>>>>>>>>>>> if M applied to wM does not halt >>>>> >>>>> so Ĥ (M) applied to ⟨Ĥ⟩ (wM) does not halt, but you have just told me >>>>> that it does. That is what this full (but abbreviated) state transition >>>>> sequence means: >>>>> >>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>> >>>>> Which is it? >>>> >>>> Ĥ0.q0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then Ĥ0.qx simulates Ĥ1 with the >>>> ⟨Ĥ2⟩ copy then >>>> Ĥ1.q0 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then Ĥ1.qx simulates Ĥ2 with the >>>> ⟨Ĥ3⟩ copy then >>>> Ĥ2.q0 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then Ĥ2.qx simulates Ĥ3 with the >>>> ⟨Ĥ4⟩ copy then ... >>> This is an abuse of the notation (but I know what you mean). There is >>> no Ĥ1 or Ĥ2. If you think it helps to show which copy of ⟨Ĥ⟩ your >>> simulating "decider" is either running and/or currently looking at, you >>> need to come up with a notation that does that. >> >> A better notation is what I have in my PDF actual subscripts but >> people here tel me that their newsreader makes sure to totally ignore >> posts with HTML so that do even see the post at all. > > I am happy you have a notation you like. Are you prepared to address > that fact that your H^ is not "as in Linz"? > >>> At least I know what >>> this "math poem" means, because you've been saying this "it's a >>> simulator until" stuff for years. >>> >>>> The outermost Ĥ0.qx correctly decides that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) >>>> can't possibly ever reach its final state. Then it transitions to >>>> Ĥ0.qn causing the outermost Ĥ0 to halt. >>> Apart from the bad notation, yes. All those copies and tests and >>> eventual deciding are neatly summed up in the last ⊢* Ĥ.qn of >>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>> >>>> Because the outermost Ĥ0.qx did not decide that Ĥ0 would never halt >>>> and it is self evident that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't possibly >>>> ever reach its final state there is no contradiction or paradox and it >>>> decided correctly. >>> You are free to define "decide correctly" in any way you like provided >>> you are honest about it. But you hooked people in by saying that your Ĥ >>> is "exactly and precisely as in Linz", and you quoted, even now, what >>> Linz has to say about such TMs: >>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn >>> if M applied to wM does not halt >>> This is your quote. You brought it up. You claimed your Ĥ was as Linz >>> states -- that Ĥ.q0 wM ⊢* Ĥ.qn if and only if M applied to wM does not >>> halt. Linz makes no exceptions based on why the transitions from Ĥ.q0 >>> wM to Ĥ.qn occur. Linz does not say >>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn >>> if M applied to wM does not halt or if M applied wM only halts >>> because... >>> Are you now saying that your TM was not "as in Linz"? (You should, >>> because you've admitted that elsewhere.) >> >> Ĥ[0] is to be interpreted to mean Ĥ<sub>0</sub> >> [0] Means the actual Turing machine and not a TM description. >> [1] Means the first TM description parameter >> [2] Means a copy of the the first TM description parameter >> >> Now I am saying that when the actual unmodified Linz Ĥ is understood >> to have a UTM/Halt-Decider at Ĥ[0].qx that this Ĥ[0].qx does correctly >> decide that its input: (⟨Ĥ[1]⟩, ⟨Ĥ[2]⟩) can't possibly ever reach its >> final state of Ĥ[1].qn or Ĥ[2].qn, therefore we know that its input >> never halts therefore we know that a state transition from Ĥ[0].qx to >> Ĥ0.qn is necessarily correct. > > We all know you are declaring that to be correct. Here's why your Ĥ is > not "as in Linz". Linz requires that > > Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn > if M applied to wM does not halt > > Any Ĥ that eventually transitions to Ĥ.qn on input wM must do so > if, and only if, the encoded M applied to wM does not halt. But you've > given us a case where your Ĥ is not like this: > > Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn *This did not show up in my other news server so I am pointing it again* And when we eliminate the fallacy of equivocation error we have Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ ⊢* Ĥ[0].qn The way that you do it when your twin bother commits a crime that makes you guilty. Ĥ[0].q0 ⟨Ĥ[1]⟩ only halts because the simulation of the the input to Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ was aborted. (a) The simulation of the input to Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ was aborted because neither ⟨Ĥ[1]⟩ nor ⟨Ĥ[2]⟩ could ever possibly reach their final states. (b) Because neither ⟨Ĥ[1]⟩ nor ⟨Ĥ[2]⟩ could ever possibly reach their final states we know that they never halt. (c) Because they never halt we know that Ĥ[0].qx correctly decided that its input never halts. This is the same as: X > Y & Y > Z therefore X > Z I do seem to have a correct chain of inference. I do not think that you can point to any error in this chain of inference. In an honest dialogue when you would disagree that a chain of inference derives a correct conclusion you would point to a specific error in this chain of inference. What is the error in (a)(b)(c) ? > Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's > behaviour "correct". You can call it anything you like. But it's not > "as in Linz". It does not say anything about Linz's proof. It does not > do anything people would call impossible or even interesting. > > Presumably, you will simply explain, yet again, why you choose to call > it correct. You might even, yet again, quote the symbols from Linz that > don't apply to your Ĥ in order to make you posts seem relevant. > -- 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-08-01 22:13 -0700 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] |
| Message-ID | <N9LNI.98023$VU3.62903@fx46.iad> |
| In reply to | #37486 |
On 8/1/21 8:56 PM, olcott wrote: > On 8/1/2021 5:54 AM, Ben Bacarisse wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> On 7/31/2021 5:08 PM, Ben Bacarisse wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> On 7/30/2021 2:58 PM, Ben Bacarisse wrote: >>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>> >>>>>>> On 7/30/2021 7:39 AM, Ben Bacarisse wrote: >>>>>> >>>>>>>> Any chance you will now say if >>>>>>>> >>>>>>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) >>>>>>>> >>>>>>>> transitions to Ĥ.qn or Ĥ.qy? If you find this question difficult, >>>>>>>> please ask for some help in understanding it. >>>>>>> >>>>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn >>>>>> >>>>>> An answer. Thank you. >>>>>> >>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>> >>>>>> For Ĥ to be "exactly and precisely as in Linz" this, then, is the >>>>>> clause >>>>>> that applies to your H and Ĥ: >>>>> >>>>> There is no H in the relevant last paragraph of the Linz proof that >>>>> forms the basis for the Linz conclusion. >>>> Distraction. Everything you ignore below is about the proof and refers >>>> only to Ĥ. >>>> >>>>>>>>>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn >>>>>>>>>>>>>>>>> if M applied to wM does not halt >>>>>> >>>>>> so Ĥ (M) applied to ⟨Ĥ⟩ (wM) does not halt, but you have just told me >>>>>> that it does. That is what this full (but abbreviated) state >>>>>> transition >>>>>> sequence means: >>>>>> >>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>> >>>>>> Which is it? >>>>> >>>>> Ĥ0.q0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then Ĥ0.qx simulates Ĥ1 with the >>>>> ⟨Ĥ2⟩ copy then >>>>> Ĥ1.q0 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then Ĥ1.qx simulates Ĥ2 with the >>>>> ⟨Ĥ3⟩ copy then >>>>> Ĥ2.q0 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then Ĥ2.qx simulates Ĥ3 with the >>>>> ⟨Ĥ4⟩ copy then ... >>>> This is an abuse of the notation (but I know what you mean). There is >>>> no Ĥ1 or Ĥ2. If you think it helps to show which copy of ⟨Ĥ⟩ your >>>> simulating "decider" is either running and/or currently looking at, you >>>> need to come up with a notation that does that. >>> >>> A better notation is what I have in my PDF actual subscripts but >>> people here tel me that their newsreader makes sure to totally ignore >>> posts with HTML so that do even see the post at all. >> >> I am happy you have a notation you like. Are you prepared to address >> that fact that your H^ is not "as in Linz"? >> >>>> At least I know what >>>> this "math poem" means, because you've been saying this "it's a >>>> simulator until" stuff for years. >>>> >>>>> The outermost Ĥ0.qx correctly decides that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) >>>>> can't possibly ever reach its final state. Then it transitions to >>>>> Ĥ0.qn causing the outermost Ĥ0 to halt. >>>> Apart from the bad notation, yes. All those copies and tests and >>>> eventual deciding are neatly summed up in the last ⊢* Ĥ.qn of >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>> >>>>> Because the outermost Ĥ0.qx did not decide that Ĥ0 would never halt >>>>> and it is self evident that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't possibly >>>>> ever reach its final state there is no contradiction or paradox and it >>>>> decided correctly. >>>> You are free to define "decide correctly" in any way you like provided >>>> you are honest about it. But you hooked people in by saying that >>>> your Ĥ >>>> is "exactly and precisely as in Linz", and you quoted, even now, what >>>> Linz has to say about such TMs: >>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn >>>> if M applied to wM does not halt >>>> This is your quote. You brought it up. You claimed your Ĥ was as Linz >>>> states -- that Ĥ.q0 wM ⊢* Ĥ.qn if and only if M applied to wM does not >>>> halt. Linz makes no exceptions based on why the transitions from Ĥ.q0 >>>> wM to Ĥ.qn occur. Linz does not say >>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn >>>> if M applied to wM does not halt or if M applied wM only halts >>>> because... >>>> Are you now saying that your TM was not "as in Linz"? (You should, >>>> because you've admitted that elsewhere.) >>> >>> Ĥ[0] is to be interpreted to mean Ĥ<sub>0</sub> >>> [0] Means the actual Turing machine and not a TM description. >>> [1] Means the first TM description parameter >>> [2] Means a copy of the the first TM description parameter >>> >>> Now I am saying that when the actual unmodified Linz Ĥ is understood >>> to have a UTM/Halt-Decider at Ĥ[0].qx that this Ĥ[0].qx does correctly >>> decide that its input: (⟨Ĥ[1]⟩, ⟨Ĥ[2]⟩) can't possibly ever reach its >>> final state of Ĥ[1].qn or Ĥ[2].qn, therefore we know that its input >>> never halts therefore we know that a state transition from Ĥ[0].qx to >>> Ĥ0.qn is necessarily correct. >> >> We all know you are declaring that to be correct. Here's why your Ĥ is >> not "as in Linz". Linz requires that >> >> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn >> if M applied to wM does not halt >> >> Any Ĥ that eventually transitions to Ĥ.qn on input wM must do so >> if, and only if, the encoded M applied to wM does not halt. But you've >> given us a case where your Ĥ is not like this: >> >> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn > > *This did not show up in my other news server so I am pointing it again* > > And when we eliminate the fallacy of equivocation error we have > > Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ ⊢* Ĥ[0].qn > > The way that you do it when your twin bother commits a crime that makes > you guilty. > > Ĥ[0].q0 ⟨Ĥ[1]⟩ only halts because the simulation of the > the input to Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ was aborted. > > (a) The simulation of the input to Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ > was aborted because neither ⟨Ĥ[1]⟩ nor ⟨Ĥ[2]⟩ could > ever possibly reach their final states. > > (b) Because neither ⟨Ĥ[1]⟩ nor ⟨Ĥ[2]⟩ could ever possibly reach > their final states we know that they never halt. > > (c) Because they never halt we know that Ĥ[0].qx correctly decided > that its input never halts. > > This is the same as: X > Y & Y > Z therefore X > Z > I do seem to have a correct chain of inference. > I do not think that you can point to any error in > this chain of inference. > > In an honest dialogue when you would disagree that a > chain of inference derives a correct conclusion you > would point to a specific error in this chain of inference. > > What is the error in (a)(b)(c) ? > > See my rebuttal to your other message. >> Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's >> behaviour "correct". You can call it anything you like. But it's not >> "as in Linz". It does not say anything about Linz's proof. It does not >> do anything people would call impossible or even interesting. >> >> Presumably, you will simply explain, yet again, why you choose to call >> it correct. You might even, yet again, quote the symbols from Linz that >> don't apply to your Ĥ in order to make you posts seem relevant. >> > >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-08-02 20:11 +0100 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] |
| Message-ID | <87h7g764rb.fsf@bsb.me.uk> |
| In reply to | #37486 |
olcott <NoOne@NoWhere.com> writes: > *This did not show up in my other news server so I am pointing it > again* It did in mine and I replied. I won't reply again. With luck you won't see my reply. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-08-04 20:38 -0500 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] |
| Message-ID | <kiHOI.2713$5O.1928@fx10.iad> |
| In reply to | #37486 |
On 8/1/21 9:56 PM, olcott wrote: > On 8/1/2021 5:54 AM, Ben Bacarisse wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> On 7/31/2021 5:08 PM, Ben Bacarisse wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> On 7/30/2021 2:58 PM, Ben Bacarisse wrote: >>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>> >>>>>>> On 7/30/2021 7:39 AM, Ben Bacarisse wrote: >>>>>> >>>>>>>> Any chance you will now say if >>>>>>>> >>>>>>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) >>>>>>>> >>>>>>>> transitions to Ĥ.qn or Ĥ.qy? If you find this question difficult, >>>>>>>> please ask for some help in understanding it. >>>>>>> >>>>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn >>>>>> >>>>>> An answer. Thank you. >>>>>> >>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>> >>>>>> For Ĥ to be "exactly and precisely as in Linz" this, then, is the >>>>>> clause >>>>>> that applies to your H and Ĥ: >>>>> >>>>> There is no H in the relevant last paragraph of the Linz proof that >>>>> forms the basis for the Linz conclusion. >>>> Distraction. Everything you ignore below is about the proof and refers >>>> only to Ĥ. >>>> >>>>>>>>>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn >>>>>>>>>>>>>>>>> if M applied to wM does not halt >>>>>> >>>>>> so Ĥ (M) applied to ⟨Ĥ⟩ (wM) does not halt, but you have just told me >>>>>> that it does. That is what this full (but abbreviated) state >>>>>> transition >>>>>> sequence means: >>>>>> >>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>> >>>>>> Which is it? >>>>> >>>>> Ĥ0.q0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then Ĥ0.qx simulates Ĥ1 with the >>>>> ⟨Ĥ2⟩ copy then >>>>> Ĥ1.q0 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then Ĥ1.qx simulates Ĥ2 with the >>>>> ⟨Ĥ3⟩ copy then >>>>> Ĥ2.q0 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then Ĥ2.qx simulates Ĥ3 with the >>>>> ⟨Ĥ4⟩ copy then ... >>>> This is an abuse of the notation (but I know what you mean). There is >>>> no Ĥ1 or Ĥ2. If you think it helps to show which copy of ⟨Ĥ⟩ your >>>> simulating "decider" is either running and/or currently looking at, you >>>> need to come up with a notation that does that. >>> >>> A better notation is what I have in my PDF actual subscripts but >>> people here tel me that their newsreader makes sure to totally ignore >>> posts with HTML so that do even see the post at all. >> >> I am happy you have a notation you like. Are you prepared to address >> that fact that your H^ is not "as in Linz"? >> >>>> At least I know what >>>> this "math poem" means, because you've been saying this "it's a >>>> simulator until" stuff for years. >>>> >>>>> The outermost Ĥ0.qx correctly decides that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) >>>>> can't possibly ever reach its final state. Then it transitions to >>>>> Ĥ0.qn causing the outermost Ĥ0 to halt. >>>> Apart from the bad notation, yes. All those copies and tests and >>>> eventual deciding are neatly summed up in the last ⊢* Ĥ.qn of >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>> >>>>> Because the outermost Ĥ0.qx did not decide that Ĥ0 would never halt >>>>> and it is self evident that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't possibly >>>>> ever reach its final state there is no contradiction or paradox and it >>>>> decided correctly. >>>> You are free to define "decide correctly" in any way you like provided >>>> you are honest about it. But you hooked people in by saying that >>>> your Ĥ >>>> is "exactly and precisely as in Linz", and you quoted, even now, what >>>> Linz has to say about such TMs: >>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn >>>> if M applied to wM does not halt >>>> This is your quote. You brought it up. You claimed your Ĥ was as Linz >>>> states -- that Ĥ.q0 wM ⊢* Ĥ.qn if and only if M applied to wM does not >>>> halt. Linz makes no exceptions based on why the transitions from Ĥ.q0 >>>> wM to Ĥ.qn occur. Linz does not say >>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn >>>> if M applied to wM does not halt or if M applied wM only halts >>>> because... >>>> Are you now saying that your TM was not "as in Linz"? (You should, >>>> because you've admitted that elsewhere.) >>> >>> Ĥ[0] is to be interpreted to mean Ĥ<sub>0</sub> >>> [0] Means the actual Turing machine and not a TM description. >>> [1] Means the first TM description parameter >>> [2] Means a copy of the the first TM description parameter >>> >>> Now I am saying that when the actual unmodified Linz Ĥ is understood >>> to have a UTM/Halt-Decider at Ĥ[0].qx that this Ĥ[0].qx does correctly >>> decide that its input: (⟨Ĥ[1]⟩, ⟨Ĥ[2]⟩) can't possibly ever reach its >>> final state of Ĥ[1].qn or Ĥ[2].qn, therefore we know that its input >>> never halts therefore we know that a state transition from Ĥ[0].qx to >>> Ĥ0.qn is necessarily correct. >> >> We all know you are declaring that to be correct. Here's why your Ĥ is >> not "as in Linz". Linz requires that >> >> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn >> if M applied to wM does not halt >> >> Any Ĥ that eventually transitions to Ĥ.qn on input wM must do so >> if, and only if, the encoded M applied to wM does not halt. But you've >> given us a case where your Ĥ is not like this: >> >> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn > > *This did not show up in my other news server so I am pointing it again* > > And when we eliminate the fallacy of equivocation error we have > > Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ ⊢* Ĥ[0].qn > > The way that you do it when your twin bother commits a crime that makes > you guilty. Except for Turing Machines, you do every thing your 'twin brother' does, so if he commits a crime, so did you, so you ARE guilty. > > Ĥ[0].q0 ⟨Ĥ[1]⟩ only halts because the simulation of the > the input to Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ was aborted. > > (a) The simulation of the input to Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ > was aborted because neither ⟨Ĥ[1]⟩ nor ⟨Ĥ[2]⟩ could > ever possibly reach their final states. > > (b) Because neither ⟨Ĥ[1]⟩ nor ⟨Ĥ[2]⟩ could ever possibly reach > their final states we know that they never halt. > > (c) Because they never halt we know that Ĥ[0].qx correctly decided > that its input never halts. > > This is the same as: X > Y & Y > Z therefore X > Z > I do seem to have a correct chain of inference. > I do not think that you can point to any error in > this chain of inference. > > In an honest dialogue when you would disagree that a > chain of inference derives a correct conclusion you > would point to a specific error in this chain of inference. > > What is the error in (a)(b)(c) ? Because that isn't the definition of Halting. The definition is what the ACTUAL machine does, and by the definition of a UTM what the simulaion by a REAL UTM would do. A simulator that aborts its simulation is NOT a UTM -- PERIOD. The fact that H^[1] is aborted before it reaches the state that H^[0] is KNOWN AND ADMITTED to reach, we know that H^[1] WILL do exactly the same thing if allowed to continue. The fact that H make the error and aborts its simulation too soon doesn't change this fact. THe fact that UTM((H^[1]), (H^[2])) will halts (since this IS the identical computation to H^[0]((H^[1]) since all (H^[i]) are identical. > > >> Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's >> behaviour "correct". You can call it anything you like. But it's not >> "as in Linz". It does not say anything about Linz's proof. It does not >> do anything people would call impossible or even interesting. >> >> Presumably, you will simply explain, yet again, why you choose to call >> it correct. You might even, yet again, quote the symbols from Linz that >> don't apply to your Ĥ in order to make you posts seem relevant. >> > >
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2021-07-31 15:47 -0700 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ] |
| Message-ID | <se4ju8$sha$1@dont-email.me> |
| In reply to | #37387 |
On 7/30/21 6:16 PM, olcott wrote: > On 7/30/2021 2:58 PM, Ben Bacarisse wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> On 7/30/2021 7:39 AM, Ben Bacarisse wrote: >> >>>> Any chance you will now say if >>>> >>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) >>>> >>>> transitions to Ĥ.qn or Ĥ.qy? If you find this question difficult, >>>> please ask for some help in understanding it. >>> >>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn >> >> An answer. Thank you. >> >> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >> For Ĥ to be "exactly and precisely as in Linz" this, then, is the >> clause >> that applies to your H and Ĥ: >> > > There is no H in the relevant last paragraph of the Linz proof that > forms the basis for the Linz conclusion. > >>>>>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn >>>>>>>>>>>>> if M applied to wM does not halt >> >> so Ĥ (M) applied to ⟨Ĥ⟩ (wM) does not halt, but you have just told me >> that it does. That is what this full (but abbreviated) state transition >> sequence means: >> >> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >> >> Which is it? >> > > Ĥ0.q0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then Ĥ0.qx simulates Ĥ1 with the > ⟨Ĥ2⟩ copy then > Ĥ1.q0 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then Ĥ1.qx simulates Ĥ2 with the > ⟨Ĥ3⟩ copy then > Ĥ2.q0 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then Ĥ2.qx simulates Ĥ3 with the > ⟨Ĥ4⟩ copy then ... As Ben says, this is incorrect. H^0.q0 copies its input (H^1) to (H^2) the goes to H^0.qx which starts a simulaiton of H^1 of H^2, this simulation then simulates the running of H1^ which starts at the simulated state H^1.q0 and simulates its copying of H^2 to H^3, and then simulates it going to H^1.qx and then it simulates the simulation of H^2. The Simulation of the Simulation of state H^2.q0 then simulates the simulation of the copying of H^3 to H^4 ... > > The outermost Ĥ0.qx correctly decides that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't > possibly ever reach its final state. Then it transitions to Ĥ0.qn > causing the outermost Ĥ0 to halt. The actual simulation that started at H^0.qx then INcorrect decides that its input H^1,H^2 can't possible reach its final state, tansitioning to H^0.qn where the machine Halts, show that H^(H^) is a Halting Computation and thus that the copy of H at H^0.qx was wrong in deciding that H^1(H^2) would never halt. > > Because the outermost Ĥ0.qx did not decide that Ĥ0 would never halt and > it is self evident that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't possibly ever > reach its final state there is no contradiction or paradox and it > decided correctly. > Since H^0 is the same computaiton as H^1 as H^2 etc, ALL these machines WILL behave the same, so H^0 deciding that H^1(H^2) is exactly the same as the 'generic' statement that H(H^,H^) decided none halting when H^(H^) is shown to be halting. If H^1 behaves differently then H^0, you built your system incorrectly.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-28 21:52 -0500 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) |
| Message-ID | <x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com> |
| In reply to | #37236 |
On 7/28/2021 7:58 PM, Ben Bacarisse wrote: > olcott <NoOne@NoWhere.com> writes: > >> On 7/28/2021 6:22 PM, Ben Bacarisse wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> On 7/26/2021 6:48 PM, Ben Bacarisse wrote: >>>>> olcott <NoOne@NoWhere.com> writes: >>>>> >>>>>> While the input to H(P,P) is simulated in pure simulation mode it >>>>>> cannot possibly ever reach a final state thus conclusively proving >>>>>> that this input never halts. >>>>> Who cares? H(P,P) == 0 and P(P) halts so H is not a halt decider. You >>>>> once claimed something "interesting" i.e. that you had >>>>> "encoded all of the ... Linz Turing machine H that correctly decides >>>>> halting for its fully encoded input pair: (Ĥ, Ĥ)" >>>>> and you insisted that >>>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz >>>>> specs does not exist. I now have a fully encoded pair of Turing >>>>> Machines H / Ĥ proving them wrong." >>>>> Does that "Linz Turing machine H" accept or reject the "fully encoded >>>>> input pair (H^, H^)", and what is the halting status if H^ when given H^ >>>>> (encoded)? If, as now, H rejects (H^, H^) but H^ halts when given H^ >>>>> then there was never anything interesting about what you were claiming, >>>>> but it was at least about Turing machines and the proof you have fixated >>>>> on. >>>>> But you also said your TMs H and H^ are "exactly and precisely as in >>>>> Linz", so really either >>>>> (1) H rejects (H^, H^) and H^ does not halt on input H^, or >>>>> (2) H accepts (H^, H^) and H^ halts on input H^ >>>>> should be the case. So, come clean. Which was the case back then: >>>>> (1) H rejects (H^, H^) and H^ does not halt in input H^, or >>>>> (2) H accepts (H^, H^) and H^ halts on input H^, or >>>>> (3) H rejects (H^, H^) and H^ halts on input H^. >>>>> Without the comfort blanket of your huge pile of junk x86 code, I >>>>> suspect you won't dare say. >>>> >>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞ >>>> if M applied to wM halts, and >>>> >>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn >>>> if M applied to wM does not halt >>>> >>>> When we apply Ĥ to its own TM description ⟨Ĥ⟩ >>> If you didn't understand the question, I might be able to explain it >>> some other way. If you are just avoiding answering it, then just say so >>> and I'll stop asking. >> >> I totally ignored the convoluted mess of your question... > > Would you like to know what I was asking, or do you just want to keep > posting stuff for your entertainment? It's simpler for me if you are > not interested in knowing what I was asking, and I think it helps other > readers form an opinion as well. > I would prefer to move away from division and animosity to achieve an honest dialogue striving for mutual agreement, are you game? -- 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-07-30 02:18 +0100 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) |
| Message-ID | <87mtq438ge.fsf@bsb.me.uk> |
| In reply to | #37238 |
olcott <NoOne@NoWhere.com> writes:
(I answered your other belligerent reply before I read this.)
> I would prefer to move away from division and animosity to achieve an
> honest dialogue striving for mutual agreement, are you game?
Sure. Here are some other things about which I would like to seek
mutual agreement:
(1) A TM, M, halts on input s if the sequence of machine configurations
generated by M's state transition function, along with the input s,
is finite. M is said to accept s if the final state is an accepting
state. Otherwise M is said to reject the input s.
(2) A halt decider is a TM, D, that accepts only and all inputs of the
form <m,s> where m encodes a TM that halts on input s. D rejects
all others inputs.
(3) Did you have, back in Dec 2018, a Turing machine (as the term is
defined in any of the usual textbooks) that you called H to which
Linz's "hat" constriction could be applied to get another TM, H^?
(4) Using [X] to denote the string that encodes TM X, did your Dec 2018
H^ halt on input [H^]?
(5) Did your Dec 2018 H accept or reject the string <[H^],[H^]>?
Of course, if your answer to (3) is no, then (4) and (5) are irrelevant.
Either way you should post what you had in Dec 2018. Your conflicting
claims about what it was are one of the biggest obstacles to honest
dialogue. With what you had out in the open, we could get some
agreement on modified versions of (4) and (5).
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-29 21:05 -0500 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) |
| Message-ID | <PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com> |
| In reply to | #37310 |
On 7/29/2021 8:18 PM, Ben Bacarisse wrote: > olcott <NoOne@NoWhere.com> writes: > > (I answered your other belligerent reply before I read this.) > >> I would prefer to move away from division and animosity to achieve an >> honest dialogue striving for mutual agreement, are you game? > > Sure. Here are some other things about which I would like to seek > mutual agreement: > > (1) A TM, M, halts on input s if the sequence of machine configurations > generated by M's state transition function, along with the input s, > is finite. I like André's reaches one of its own finite states better. Is this OK with you? > M is said to accept s if the final state is an accepting > state. Otherwise M is said to reject the input s. > Yes > (2) A halt decider is a TM, D, that accepts only and all inputs of the > form <m,s> where m encodes a TM that halts on input s. D rejects > all others inputs. Yes with André's definition of halting. Is this OK with you? > > (3) Did you have, back in Dec 2018, a Turing machine (as the term is > defined in any of the usual textbooks) that you called H to which > Linz's "hat" constriction could be applied to get another TM, H^? I never had a Turing machine. I had what I still consider to be computationally equivalent to the key partial halt deciding aspect of the Linz H correctly deciding the the simplest possible single example of the Linz Ĥ (no copying of the input) as never halting. The 2018 version was encoded to correctly recognize one instance of infinitely nested simulation. It was encoded in nearly complete C. > > (4) Using [X] to denote the string that encodes TM X, did your Dec 2018 > H^ halt on input [H^]? > > (5) Did your Dec 2018 H accept or reject the string <[H^],[H^]>? > > Of course, if your answer to (3) is no, then (4) and (5) are irrelevant. > > Either way you should post what you had in Dec 2018. Your conflicting > claims about what it was are one of the biggest obstacles to honest > dialogue. With what you had out in the open, we could get some > agreement on modified versions of (4) and (5). > It is on a single piece of hand-written paper. I don't think that I ever scanned it. -- 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-07-30 12:00 +0100 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) |
| Message-ID | <87tukc12yh.fsf@bsb.me.uk> |
| In reply to | #37316 |
olcott <NoOne@NoWhere.com> writes:
> On 7/29/2021 8:18 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>> (I answered your other belligerent reply before I read this.)
>>
>>> I would prefer to move away from division and animosity to achieve an
>>> honest dialogue striving for mutual agreement, are you game?
>> Sure. Here are some other things about which I would like to seek
>> mutual agreement:
>> (1) A TM, M, halts on input s if the sequence of machine configurations
>> generated by M's state transition function, along with the input s,
>> is finite.
>
> I like André's reaches one of its own finite states better.
> Is this OK with you?
What you say here is too vague. If you can write it clearly and
formally, I'm sure we could agree on it, but I suspect you can't. In
the spirit of reaching an agreement, is there anything you object to in
my definition?
>> M is said to accept s if the final state is an accepting
>> state. Otherwise M is said to reject the input s.
>>
> Yes
>
>> (2) A halt decider is a TM, D, that accepts only and all inputs of the
>> form <m,s> where m encodes a TM that halts on input s. D rejects
>> all others inputs.
>
> Yes with André's definition of halting.
> Is this OK with you?
Not unless you can write it clearly, no.
>> (3) Did you have, back in Dec 2018, a Turing machine (as the term is
>> defined in any of the usual textbooks) that you called H to which
>> Linz's "hat" constriction could be applied to get another TM, H^?
>
> I never had a Turing machine.
OK, thanks. That's clear.
> It was encoded in nearly complete C.
This raises lots of questions:
(3a) What are "the exact TMD instructions of the Linz Turing machine H"
that you had encoded by Dec 14th in relation to this C code?
(3b) What does "I provide the exact ⊢* wildcard states after the Linz
H.q0 and after Ĥ.qx ... showing exactly how the actual Linz H would
correctly decide the actual Linz (Ĥ, Ĥ)" mean for C code?
Given that you had C code, the "UTM in C++" that you were writing that
would allow you to "execute H on the input pair: (Ĥ, Ĥ)" is a C
interpreter.
(3c) Did you really think you could write a C interpreter in "a week or
two"?
(3d) Why write an interpreter when C code is better compiled and a
debugger can then be used to give any required level of detail
about the execution?
In the spirit of mutual understanding, I hope you can see that these
mysterious quotes will have led everyone away from the truth (that you
had C code) while re-forcing the mistaken impression that you had what
you had said you had: an actual Turing machine.
>> (4) Using [X] to denote the string that encodes TM X, did your Dec 2018
>> H^ halt on input [H^]?
>> (5) Did your Dec 2018 H accept or reject the string <[H^],[H^]>?
>> Of course, if your answer to (3) is no, then (4) and (5) are irrelevant.
>> Either way you should post what you had in Dec 2018. Your conflicting
>> claims about what it was are one of the biggest obstacles to honest
>> dialogue. With what you had out in the open, we could get some
>> agreement on modified versions of (4) and (5).
These become
(4) Did your Dec 2018 C code for H^ halt on H^?
(5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did your
Dec 2018 code come to about "(Ĥ, Ĥ)"?
> It is on a single piece of hand-written paper. I don't think that I
> ever scanned it.
Unless you post it, we can't reach a mutual understanding about your
claim to have something that everyone else says is impossible. Maybe
you just had some C that does something entirely possible and
unsurprising. That is certainly the case now.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-30 09:35 -0500 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) |
| Message-ID | <e6OdnW_rdvusk5n8nZ2dnUU7-dPNnZ2d@giganews.com> |
| In reply to | #37331 |
On 7/30/2021 6:00 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/29/2021 8:18 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>> (I answered your other belligerent reply before I read this.)
>>>
>>>> I would prefer to move away from division and animosity to achieve an
>>>> honest dialogue striving for mutual agreement, are you game?
>>> Sure. Here are some other things about which I would like to seek
>>> mutual agreement:
>>> (1) A TM, M, halts on input s if the sequence of machine configurations
>>> generated by M's state transition function, along with the input s,
>>> is finite.
>>
>> I like André's reaches one of its own finite states better.
>> Is this OK with you?
>
> What you say here is too vague. If you can write it clearly and
> formally, I'm sure we could agree on it, but I suspect you can't. In
> the spirit of reaching an agreement, is there anything you object to in
> my definition?
>
Your definition seems to be ambiguous when the simulation of a
computation has been aborted, André's definition is not ambiguous in
this case.
The input to H(P,P) cannot possibly ever reach its final state whether
or not its simulation is aborted.
>>> M is said to accept s if the final state is an accepting
>>> state. Otherwise M is said to reject the input s.
>>>
>> Yes
>>
>>> (2) A halt decider is a TM, D, that accepts only and all inputs of the
>>> form <m,s> where m encodes a TM that halts on input s. D rejects
>>> all others inputs.
>>
>> Yes with André's definition of halting.
>> Is this OK with you?
>
> Not unless you can write it clearly, no.
We can work on this.
The input to my partial halt decider is always a complete function
compiled from C and complete functions always have the explicit final
state of their last address.
>>> (3) Did you have, back in Dec 2018, a Turing machine (as the term is
>>> defined in any of the usual textbooks) that you called H to which
>>> Linz's "hat" constriction could be applied to get another TM, H^?
>>
>> I never had a Turing machine.
>
> OK, thanks. That's clear.
>
>> It was encoded in nearly complete C.
>
> This raises lots of questions:
>
> (3a) What are "the exact TMD instructions of the Linz Turing machine H"
> that you had encoded by Dec 14th in relation to this C code?
>
Like I said I did not have a Turing Machine.
> (3b) What does "I provide the exact ⊢* wildcard states after the Linz
> H.q0 and after Ĥ.qx ... showing exactly how the actual Linz H would
> correctly decide the actual Linz (Ĥ, Ĥ)" mean for C code?
>
the proof ...is so short and simple that
it may be of interest to casual readers.
The version below uses CPL...
rec routine P
§L:if T[P] go to L
Return §
Strachey, C 1965. An impossible program The Computer Journal, Volume 7,
Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
In the same way that Strachey claims that his little CPL program sums up
the entire proof my premise is that this C code sums up the entire proof.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
What I had in 2018 was a crude way that code determined that the above
does specify infinitely nested simulation.
"the exact ⊢* wildcard states" refers to this code.
> Given that you had C code, the "UTM in C++" that you were writing that
> would allow you to "execute H on the input pair: (Ĥ, Ĥ)" is a C
> interpreter.
>
It was not a C interpreter. It is an x86 emulator.
> (3c) Did you really think you could write a C interpreter in "a week or
> two"?
>
What I thought that I could do in a week or two was write a very simple
virtual machine language lacking all high level control flow structure.
Since I have done this before in two weeks I new that I could do it again.
> (3d) Why write an interpreter when C code is better compiled and a
> debugger can then be used to give any required level of detail
> about the execution?
>
I never wrote a C interpreter. I never intended to write a C
interpreter. The initial idea was to write a compiler for a tiny subset
of C that is compiled into a very simple virtual machine language.
> In the spirit of mutual understanding, I hope you can see that these
> mysterious quotes will have led everyone away from the truth (that you
> had C code) while re-forcing the mistaken impression that you had what
> you had said you had: an actual Turing machine.
>
>>> (4) Using [X] to denote the string that encodes TM X, did your Dec 2018
>>> H^ halt on input [H^]?
>>> (5) Did your Dec 2018 H accept or reject the string <[H^],[H^]>?
>>> Of course, if your answer to (3) is no, then (4) and (5) are irrelevant.
>>> Either way you should post what you had in Dec 2018. Your conflicting
>>> claims about what it was are one of the biggest obstacles to honest
>>> dialogue. With what you had out in the open, we could get some
>>> agreement on modified versions of (4) and (5).
>
> These become
>
> (4) Did your Dec 2018 C code for H^ halt on H^?
>
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
What I had in 2018 was a crude way that code determined that the above
does specify infinitely nested simulation. I was only concerned with
H(P,P) where P is always aborted and can't ever possibly halt.
> (5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did your
> Dec 2018 code come to about "(Ĥ, Ĥ)"?
>
The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that
H(P,P)==0 now except that the never halting criteria is much more
elaborate. The initial criteria was very crude.
>> It is on a single piece of hand-written paper. I don't think that I
>> ever scanned it.
>
> Unless you post it, we can't reach a mutual understanding about your
> claim to have something that everyone else says is impossible. Maybe
> you just had some C that does something entirely possible and
> unsurprising. That is certainly the case now.
>
It is what I have now that counts. What I had years ago has been
superseded by newer technology.
--
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-07-30 20:22 +0100 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) |
| Message-ID | <875ywrmwsr.fsf@bsb.me.uk> |
| In reply to | #37346 |
I lost internet connection after writing a reply to this so it's
possible both versions will appear. I hope not...
olcott <NoOne@NoWhere.com> writes:
> On 7/30/2021 6:00 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/29/2021 8:18 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>> (I answered your other belligerent reply before I read this.)
>>>>
>>>>> I would prefer to move away from division and animosity to achieve an
>>>>> honest dialogue striving for mutual agreement, are you game?
>>>> Sure. Here are some other things about which I would like to seek
>>>> mutual agreement:
>>>> (1) A TM, M, halts on input s if the sequence of machine configurations
>>>> generated by M's state transition function, along with the input s,
>>>> is finite.
>>>
>>> I like André's reaches one of its own finite states better.
>>> Is this OK with you?
>> What you say here is too vague. If you can write it clearly and
>> formally, I'm sure we could agree on it, but I suspect you can't. In
>> the spirit of reaching an agreement, is there anything you object to in
>> my definition?
>
> Your definition seems to be ambiguous when the simulation of a
> computation has been aborted, André's definition is not ambiguous in
> this case.
It's not ambiguous. On the other hand, your definition (I won't call
it André's unless he says you've got it right) uses too many vague
words. If you can write it formally, we may be able to agree on it.
>>>> M is said to accept s if the final state is an accepting
>>>> state. Otherwise M is said to reject the input s.
>>>>
>>> Yes
>>>
>>>> (2) A halt decider is a TM, D, that accepts only and all inputs of the
>>>> form <m,s> where m encodes a TM that halts on input s. D rejects
>>>> all others inputs.
>>>
>>> Yes with André's definition of halting.
>>> Is this OK with you?
>> Not unless you can write it clearly, no.
>
> We can work on this.
Well, I can't. You can have another go at saying what you mean, but
I've already had my say. I don't want to change my definition though
I'll add to it if you think some parts need more explanation. By the
way, it's the one with which you agreed before.
> The input to my partial halt decider is always a complete function
> compiled from C and complete functions always have the explicit final
> state of their last address.
I'm talking about Turing machines. If you want to talk about the
halting theorem, you should be prepared to discuss a formal model of
computation. It would take a lot of work for you to pin down
a C-based model of computation and I don't think you want to do that
work.
>>>> (3) Did you have, back in Dec 2018, a Turing machine (as the term is
>>>> defined in any of the usual textbooks) that you called H to which
>>>> Linz's "hat" constriction could be applied to get another TM, H^?
>>>
>>> I never had a Turing machine.
>> OK, thanks. That's clear.
>>
>>> It was encoded in nearly complete C.
>> This raises lots of questions:
>> (3a) What are "the exact TMD instructions of the Linz Turing machine H"
>> that you had encoded by Dec 14th in relation to this C code?
>
> Like I said I did not have a Turing Machine.
Right, so why did you say words that make no sense in relation to what
you did have? I'm trying to build trust so we can reach some mutual
understanding, but that means I need to know why you repeatedly tried to
make it seem as if you had what you incorrectly said you had, rather
than what you did have.
>> (3b) What does "I provide the exact ⊢* wildcard states after the Linz
>> H.q0 and after Ĥ.qx ... showing exactly how the actual Linz H would
>> correctly decide the actual Linz (Ĥ, Ĥ)" mean for C code?
>
> the proof ...is so short and simple that
> it may be of interest to casual readers.
> The version below uses CPL...
>
> rec routine P
> §L:if T[P] go to L
> Return §
>
> Strachey, C 1965. An impossible program The Computer Journal, Volume
> 7, Issue 4, January 1965, Page 313,
> https://doi.org/10.1093/comjnl/7.4.313
>
> In the same way that Strachey claims that his little CPL program sums
> up the entire proof my premise is that this C code sums up the entire
> proof.
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
> What I had in 2018 was a crude way that code determined that the above
> does specify infinitely nested simulation. "the exact ⊢* wildcard
> states" refers to this code.
Is this the best, most diligent answer to (3b) that you have? I must
say it does not come close to explaining what these "exact states after
the Linz H.q0 and after Ĥ.qx" are, nor does it explain why you used the
⊢* notation when you did not have a Turing machine. Was that a poetic
usage as well, like the license you used to call your C code an "actual
Turing machine"?
>> Given that you had C code, the "UTM in C++" that you were writing that
>> would allow you to "execute H on the input pair: (Ĥ, Ĥ)" is a C
>> interpreter.
>
> It was not a C interpreter. It is an x86 emulator.
Below you say it was not an x86 emulator but I not you say "is" not
"was". I'm asking about what the "UTM in C++" that you planned to write
was. You do explain that below.
>> (3c) Did you really think you could write a C interpreter in "a week or
>> two"?
>
> What I thought that I could do in a week or two was write a very
> simple virtual machine language lacking all high level control flow
> structure. Since I have done this before in two weeks I new that I
> could do it again.
Ah, I see. Why call is a UTM? And why, when I offered to write the UTM
for you in a couple of days did you not say "sorry, I don't have a
Turing machine but C code"? Your poetic license seems to extend over
many posts and many terms. From my position it looks like you meant
what you wrote.
>> (3d) Why write an interpreter when C code is better compiled and a
>> debugger can then be used to give any required level of detail
>> about the execution?
>
> I never wrote a C interpreter. I never intended to write a C
> interpreter. The initial idea was to write a compiler for a tiny
> subset of C that is compiled into a very simple virtual machine
> language.
That's an odd way to run C code, but maybe when you post it (you will
post it, yes?) it will be clear why you can't just tidy up the details
and run it, using existing tools to get traces if you need them.
>> In the spirit of mutual understanding, I hope you can see that these
>> mysterious quotes will have led everyone away from the truth (that you
>> had C code) while re-forcing the mistaken impression that you had what
>> you had said you had: an actual Turing machine.
>>
>>>> (4) Using [X] to denote the string that encodes TM X, did your Dec 2018
>>>> H^ halt on input [H^]?
>>>> (5) Did your Dec 2018 H accept or reject the string <[H^],[H^]>?
>>>> Of course, if your answer to (3) is no, then (4) and (5) are irrelevant.
>>>> Either way you should post what you had in Dec 2018. Your conflicting
>>>> claims about what it was are one of the biggest obstacles to honest
>>>> dialogue. With what you had out in the open, we could get some
>>>> agreement on modified versions of (4) and (5).
>> These become
>> (4) Did your Dec 2018 C code for H^ halt on H^?
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
> What I had in 2018 was a crude way that code determined that the above
> does specify infinitely nested simulation. I was only concerned with
> H(P,P) where P is always aborted and can't ever possibly halt.
Are you able and willing to answer (4)? If you can't, can I help by
explaining the question?
>> (5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did your
>> Dec 2018 code come to about "(Ĥ, Ĥ)"?
>
> The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that
> H(P,P)==0 now except that the never halting criteria is much more
> elaborate. The initial criteria was very crude.
Ah, so you never had H and H^ that do anything that anyone would say is
impossible. Had you said, back in Dec 2018, "I have C code such that
H(H^,H^) == 0 but H^(H^) halts" no one would have been interested.
I think you owe everyone an apology. Even if there was no indent to
deceive, your words back then did everything possible to suggest some
impossible Turing machine. And you wouldn't say, even when explicitly
asked, what decision H came to.
>>> It is on a single piece of hand-written paper. I don't think that I
>>> ever scanned it.
>> Unless you post it, we can't reach a mutual understanding about your
>> claim to have something that everyone else says is impossible. Maybe
>> you just had some C that does something entirely possible and
>> unsurprising. That is certainly the case now.
>
> It is what I have now that counts. What I had years ago has been
> superseded by newer technology.
Being honest about what you had back then is important if you want
people to trust you. And the technology is immaterial. You are
challenging a mathematical theorem. You must bring mathematical
arguments to the table.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-30 19:42 -0500 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) |
| Message-ID | <GtmdnfBrysPrAZn8nZ2dnUU7-L_NnZ2d@giganews.com> |
| In reply to | #37358 |
On 7/30/2021 2:22 PM, Ben Bacarisse wrote:
> I lost internet connection after writing a reply to this so it's
> possible both versions will appear. I hope not...
>
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/30/2021 6:00 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/29/2021 8:18 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>> (I answered your other belligerent reply before I read this.)
>>>>>
>>>>>> I would prefer to move away from division and animosity to achieve an
>>>>>> honest dialogue striving for mutual agreement, are you game?
>>>>> Sure. Here are some other things about which I would like to seek
>>>>> mutual agreement:
>>>>> (1) A TM, M, halts on input s if the sequence of machine configurations
>>>>> generated by M's state transition function, along with the input s,
>>>>> is finite.
>>>>
>>>> I like André's reaches one of its own finite states better.
>>>> Is this OK with you?
>>> What you say here is too vague. If you can write it clearly and
>>> formally, I'm sure we could agree on it, but I suspect you can't. In
>>> the spirit of reaching an agreement, is there anything you object to in
>>> my definition?
>>
>> Your definition seems to be ambiguous when the simulation of a
>> computation has been aborted, André's definition is not ambiguous in
>> this case.
>
> It's not ambiguous. On the other hand, your definition (I won't call
> it André's unless he says you've got it right) uses too many vague
> words. If you can write it formally, we may be able to agree on it.
>
_P()
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // 2nd Param
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // 1st Param
[00000c30](05) e820fdffff call 00000955 // call H
[00000c35](03) 83c408 add esp,+08
[00000c38](02) 85c0 test eax,eax
[00000c3a](02) 7402 jz 00000c3e
[00000c3c](02) ebfe jmp 00000c3c
[00000c3e](01) 5d pop ebp
[00000c3f](01) c3 ret
Size in bytes:(0027) [00000c3f]
All of the inputs to H are complete functions that were translated by
the Microsoft C compiler have well-defined final states. The above
function has 0xc3f as its sole final state. If it reaches this final
state it halts. If its execution trace proves that it can never reach
this final state then it never halts.
>>>>> M is said to accept s if the final state is an accepting
>>>>> state. Otherwise M is said to reject the input s.
>>>>>
>>>> Yes
>>>>
>>>>> (2) A halt decider is a TM, D, that accepts only and all inputs of the
>>>>> form <m,s> where m encodes a TM that halts on input s. D rejects
>>>>> all others inputs.
>>>>
>>>> Yes with André's definition of halting.
>>>> Is this OK with you?
>>> Not unless you can write it clearly, no.
>>
>> We can work on this.
>
> Well, I can't. You can have another go at saying what you mean, but
> I've already had my say. I don't want to change my definition though
> I'll add to it if you think some parts need more explanation. By the
> way, it's the one with which you agreed before.
>
We must have a perfectly definitive way of dividing inputs that stop
running because their computation has fully completed from inputs that
stop running for any other reason.
>> The input to my partial halt decider is always a complete function
>> compiled from C and complete functions always have the explicit final
>> state of their last address.
>
> I'm talking about Turing machines. If you want to talk about the
> halting theorem, you should be prepared to discuss a formal model of
> computation. It would take a lot of work for you to pin down
> a C-based model of computation and I don't think you want to do that
> work.
>
Because it is utterly impossible to specify all of the relevant details
in the TM model of computation I created the x86utm system. All of the
formal proofs leave out most of the relevant details because these key
details cannot be specified in any reasonably compact and concise form.
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
if M applied to wM halts, and
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
The second ⊢* wildcard state has millions of unspecified steps that are
mere hand-waving. Because all of the conventional proofs are mostly
hand-waving it never occurred to anyone that a simulating halt decider
at Ĥ.qx would correctly decide that it must stop the simulation of its
input thus proving that its input never halts.
>>>>> (3) Did you have, back in Dec 2018, a Turing machine (as the term is
>>>>> defined in any of the usual textbooks) that you called H to which
>>>>> Linz's "hat" constriction could be applied to get another TM, H^?
>>>>
>>>> I never had a Turing machine.
>>> OK, thanks. That's clear.
>>>
>>>> It was encoded in nearly complete C.
>>> This raises lots of questions:
>>> (3a) What are "the exact TMD instructions of the Linz Turing machine H"
>>> that you had encoded by Dec 14th in relation to this C code?
>>
>> Like I said I did not have a Turing Machine.
>
> Right, so why did you say words that make no sense in relation to what
> you did have? I'm trying to build trust so we can reach some mutual
> understanding, but that means I need to know why you repeatedly tried to
> make it seem as if you had what you incorrectly said you had, rather
> than what you did have.
>
I had the essence of the computational equivalent of what I claimed and
would have simply claimed that I has the essence of he computational
equivalent if I had known that TM equivalence was a thing that other
people knew about and not just private knowledge that I had.
At the end of 2018 I had only heard of TM complete and I knew that this
required unlimited memory. TM equivalence for a subset of computations
still seems to be a thing that no one else knows about. C is equivalent
to a TM for the subset of computations where it has all the memory that
it needs. I don't think that anyone else beside me says this.
>>> (3b) What does "I provide the exact ⊢* wildcard states after the Linz
>>> H.q0 and after Ĥ.qx ... showing exactly how the actual Linz H would
>>> correctly decide the actual Linz (Ĥ, Ĥ)" mean for C code?
>>
>> the proof ...is so short and simple that
>> it may be of interest to casual readers.
>> The version below uses CPL...
>>
>> rec routine P
>> §L:if T[P] go to L
>> Return §
>>
>> Strachey, C 1965. An impossible program The Computer Journal, Volume
>> 7, Issue 4, January 1965, Page 313,
>> https://doi.org/10.1093/comjnl/7.4.313
>>
>> In the same way that Strachey claims that his little CPL program sums
>> up the entire proof my premise is that this C code sums up the entire
>> proof.
>>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>>
>> What I had in 2018 was a crude way that code determined that the above
>> does specify infinitely nested simulation. "the exact ⊢* wildcard
>> states" refers to this code.
>
> Is this the best, most diligent answer to (3b) that you have? I must
> say it does not come close to explaining what these "exact states after
> the Linz H.q0 and after Ĥ.qx" are,
I was a crude kludge that worked.
> nor does it explain why you used the
> ⊢* notation when you did not have a Turing machine.
So you are not aware that all comutations have state transitions?
I count the x86 state transition as moving from one instruction to the
next.
> Was that a poetic
> usage as well, like the license you used to call your C code an "actual
> Turing machine"?
>
>>> Given that you had C code, the "UTM in C++" that you were writing that
>>> would allow you to "execute H on the input pair: (Ĥ, Ĥ)" is a C
>>> interpreter.
>>
>> It was not a C interpreter. It is an x86 emulator.
>
> Below you say it was not an x86 emulator but I not you say "is" not
> "was". I'm asking about what the "UTM in C++" that you planned to write
> was. You do explain that below.
>
It matters not what I had. It only matters what I have. If you are
sincere about an honest dialogue then we must quit focusing on details
of obsolete technology.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2021-07-30 18:27 -0700 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) |
| Message-ID | <se28uf$nm2$1@dont-email.me> |
| In reply to | #37386 |
On 7/30/21 5:42 PM, olcott wrote:
> On 7/30/2021 2:22 PM, Ben Bacarisse wrote:
>> I lost internet connection after writing a reply to this so it's
>> possible both versions will appear. I hope not...
>>
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/30/2021 6:00 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/29/2021 8:18 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>> (I answered your other belligerent reply before I read this.)
>>>>>>
>>>>>>> I would prefer to move away from division and animosity to
>>>>>>> achieve an
>>>>>>> honest dialogue striving for mutual agreement, are you game?
>>>>>> Sure. Here are some other things about which I would like to seek
>>>>>> mutual agreement:
>>>>>> (1) A TM, M, halts on input s if the sequence of machine
>>>>>> configurations
>>>>>> generated by M's state transition function, along with the
>>>>>> input s,
>>>>>> is finite.
>>>>>
>>>>> I like André's reaches one of its own finite states better.
>>>>> Is this OK with you?
>>>> What you say here is too vague. If you can write it clearly and
>>>> formally, I'm sure we could agree on it, but I suspect you can't. In
>>>> the spirit of reaching an agreement, is there anything you object to in
>>>> my definition?
>>>
>>> Your definition seems to be ambiguous when the simulation of a
>>> computation has been aborted, André's definition is not ambiguous in
>>> this case.
>>
>> It's not ambiguous. On the other hand, your definition (I won't call
>> it André's unless he says you've got it right) uses too many vague
>> words. If you can write it formally, we may be able to agree on it.
>>
>
> _P()
> [00000c25](01) 55 push ebp
> [00000c26](02) 8bec mov ebp,esp
> [00000c28](03) 8b4508 mov eax,[ebp+08]
> [00000c2b](01) 50 push eax // 2nd Param
> [00000c2c](03) 8b4d08 mov ecx,[ebp+08]
> [00000c2f](01) 51 push ecx // 1st Param
> [00000c30](05) e820fdffff call 00000955 // call H
> [00000c35](03) 83c408 add esp,+08
> [00000c38](02) 85c0 test eax,eax
> [00000c3a](02) 7402 jz 00000c3e
> [00000c3c](02) ebfe jmp 00000c3c
> [00000c3e](01) 5d pop ebp
> [00000c3f](01) c3 ret
> Size in bytes:(0027) [00000c3f]
>
> All of the inputs to H are complete functions that were translated by
> the Microsoft C compiler have well-defined final states. The above
> function has 0xc3f as its sole final state. If it reaches this final
> state it halts. If its execution trace proves that it can never reach
> this final state then it never halts.
But the execution trace of main calling P(P) directly shows that P(P)
itself WILL halt, the problem is that H makes the mistake of thinking it
won't and stops it too soon. Thus H is wrong.
Behavior of the machine the input represent is the REAL ACTUAL
DEFINITION of Halting.
If you claim H can be right here, then we can just define a differnt
decider that immediately aborts the simulation and declair its input
never reached a halting state, and thus is non-halting.
FAIL.
>
>>>>>> M is said to accept s if the final state is an accepting
>>>>>> state. Otherwise M is said to reject the input s.
>>>>>>
>>>>> Yes
>>>>>
>>>>>> (2) A halt decider is a TM, D, that accepts only and all inputs of
>>>>>> the
>>>>>> form <m,s> where m encodes a TM that halts on input s. D
>>>>>> rejects
>>>>>> all others inputs.
>>>>>
>>>>> Yes with André's definition of halting.
>>>>> Is this OK with you?
>>>> Not unless you can write it clearly, no.
>>>
>>> We can work on this.
>>
>> Well, I can't. You can have another go at saying what you mean, but
>> I've already had my say. I don't want to change my definition though
>> I'll add to it if you think some parts need more explanation. By the
>> way, it's the one with which you agreed before.
>>
>
> We must have a perfectly definitive way of dividing inputs that stop
> running because their computation has fully completed from inputs that
> stop running for any other reason.
WHY?
And we do, we run the machines that the input represents and see what
they do. P(P) Halts. There is NO requirement that H needs to be able to
get the answer right, just that there IS a correct answer to the ACTUAL
question, does P(I) reach a halting state in a finite number of steps.
>
>>> The input to my partial halt decider is always a complete function
>>> compiled from C and complete functions always have the explicit final
>>> state of their last address.
>>
>> I'm talking about Turing machines. If you want to talk about the
>> halting theorem, you should be prepared to discuss a formal model of
>> computation. It would take a lot of work for you to pin down
>> a C-based model of computation and I don't think you want to do that
>> work.
>>
>
> Because it is utterly impossible to specify all of the relevant details
> in the TM model of computation I created the x86utm system. All of the
> formal proofs leave out most of the relevant details because these key
> details cannot be specified in any reasonably compact and concise form.
But it isn't. Maybe for you it is, but by the Turing Equivalence Theorem
you are using, if your machine actually is the Computational Equivalent
of a Turing Machine, such a Turing Machine can be made.
If you REALLY mean that can't be done, then it says your 'program' isn't
a computation and thus doesn't fullfil the requirements.
>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
> if M applied to wM halts, and
>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> if M applied to wM does not halt
>
> The second ⊢* wildcard state has millions of unspecified steps that are
> mere hand-waving. Because all of the conventional proofs are mostly
> hand-waving it never occurred to anyone that a simulating halt decider
> at Ĥ.qx would correctly decide that it must stop the simulation of its
> input thus proving that its input never halts.
They aren't hand waving, YOU do hand waving.
Note, you in effect are admitting to your flaw, because a simulator
stopping its simulation NEVER actual PROVES anything.
UNSOUND LOGIC, FAIL.
>
>>>>>> (3) Did you have, back in Dec 2018, a Turing machine (as the term is
>>>>>> defined in any of the usual textbooks) that you called H to
>>>>>> which
>>>>>> Linz's "hat" constriction could be applied to get another
>>>>>> TM, H^?
>>>>>
>>>>> I never had a Turing machine.
>>>> OK, thanks. That's clear.
>>>>
>>>>> It was encoded in nearly complete C.
>>>> This raises lots of questions:
>>>> (3a) What are "the exact TMD instructions of the Linz Turing machine H"
>>>> that you had encoded by Dec 14th in relation to this C code?
>>>
>>> Like I said I did not have a Turing Machine.
>>
>> Right, so why did you say words that make no sense in relation to what
>> you did have? I'm trying to build trust so we can reach some mutual
>> understanding, but that means I need to know why you repeatedly tried to
>> make it seem as if you had what you incorrectly said you had, rather
>> than what you did have.
>>
>
> I had the essence of the computational equivalent of what I claimed and
> would have simply claimed that I has the essence of he computational
> equivalent if I had known that TM equivalence was a thing that other
> people knew about and not just private knowledge that I had.
>
> At the end of 2018 I had only heard of TM complete and I knew that this
> required unlimited memory. TM equivalence for a subset of computations
> still seems to be a thing that no one else knows about. C is equivalent
> to a TM for the subset of computations where it has all the memory that
> it needs. I don't think that anyone else beside me says this.
I.E you didn't and still don't understand what a Turing Machine actually
is, and are just lying out of your a** when you make claims about them.
>
>>>> (3b) What does "I provide the exact ⊢* wildcard states after the Linz
>>>> H.q0 and after Ĥ.qx ... showing exactly how the actual Linz H
>>>> would
>>>> correctly decide the actual Linz (Ĥ, Ĥ)" mean for C code?
>>>
>>> the proof ...is so short and simple that
>>> it may be of interest to casual readers.
>>> The version below uses CPL...
>>>
>>> rec routine P
>>> §L:if T[P] go to L
>>> Return §
>>>
>>> Strachey, C 1965. An impossible program The Computer Journal, Volume
>>> 7, Issue 4, January 1965, Page 313,
>>> https://doi.org/10.1093/comjnl/7.4.313
>>>
>>> In the same way that Strachey claims that his little CPL program sums
>>> up the entire proof my premise is that this C code sums up the entire
>>> proof.
>>>
>>> void P(u32 x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> }
>>>
>>> What I had in 2018 was a crude way that code determined that the above
>>> does specify infinitely nested simulation. "the exact ⊢* wildcard
>>> states" refers to this code.
>>
>> Is this the best, most diligent answer to (3b) that you have? I must
>> say it does not come close to explaining what these "exact states after
>> the Linz H.q0 and after Ĥ.qx" are,
>
> I was a crude kludge that worked.
No, it didn't. Maybe it was good enough to gaslight you.
>
>> nor does it explain why you used the
>> ⊢* notation when you did not have a Turing machine.
>
> So you are not aware that all comutations have state transitions?
> I count the x86 state transition as moving from one instruction to the
> next.
An H^(H^) reaches its terminal state when directly run in a finite
number of them, so is halting.
>
>> Was that a poetic
>> usage as well, like the license you used to call your C code an "actual
>> Turing machine"?
>>
>>>> Given that you had C code, the "UTM in C++" that you were writing that
>>>> would allow you to "execute H on the input pair: (Ĥ, Ĥ)" is a C
>>>> interpreter.
>>>
>>> It was not a C interpreter. It is an x86 emulator.
>>
>> Below you say it was not an x86 emulator but I not you say "is" not
>> "was". I'm asking about what the "UTM in C++" that you planned to write
>> was. You do explain that below.
>>
>
> It matters not what I had. It only matters what I have. If you are
> sincere about an honest dialogue then we must quit focusing on details
> of obsolete technology.
>
You STILL have nothing. H^(H^) Halts, H(H^,H^) says not halting.
BY DEFINITION that is wrong.
Only by changing defintions and thus NOT working on the problem you are
claiming or by asuming untruee premises do you even come close to a
so-called proof.
IT IS UNSOUND.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-07-31 22:54 +0100 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) |
| Message-ID | <874kcakv3d.fsf@bsb.me.uk> |
| In reply to | #37386 |
olcott <NoOne@NoWhere.com> writes: > It matters not what I had. Because you can't justify it the honest debate you claim to want. > It only matters what I have. I.e. nothing of any interest. You make it plain in a previous reply that you've had nothing of interest going right back to the original deceptive claim. > If you are sincere about an honest dialogue then we must quit focusing > on details of obsolete technology. And yet you skipped the big picture part: >> (5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did your >> Dec 2018 code come to about "(Ĥ, Ĥ)"? > > The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that > H(P,P)==0 now except that the never halting criteria is much more > elaborate. The initial criteria was very crude. Ah, so you never had H and H_Hat that do anything that anyone would say is impossible. Had you said, back in Dec 2018, "I have C code such that H(H_Hat, H_Hat) == 0 but H_Hat(H_Hat) halts" no one would have been interested. I think you owe everyone an apology. Even if there was no indent to deceive, your words back then did everything possible to suggest some impossible Turing machine. And you wouldn't say, until recently, even when explicitly asked, what decision H came to. It was fishy from the start. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-31 16:57 -0500 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) |
| Message-ID | <-M-dnfsXl4WvWpj8nZ2dnUU7-IGdnZ2d@giganews.com> |
| In reply to | #37423 |
On 7/31/2021 4:54 PM, Ben Bacarisse wrote: > olcott <NoOne@NoWhere.com> writes: > >> It matters not what I had. > > Because you can't justify it the honest debate you claim to want. > >> It only matters what I have. > > I.e. nothing of any interest. You make it plain in a previous reply > that you've had nothing of interest going right back to the original > deceptive claim. > >> If you are sincere about an honest dialogue then we must quit focusing >> on details of obsolete technology. > > And yet you skipped the big picture part: > >>> (5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did your >>> Dec 2018 code come to about "(Ĥ, Ĥ)"? >> >> The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that >> H(P,P)==0 now except that the never halting criteria is much more >> elaborate. The initial criteria was very crude. > > Ah, so you never had H and H_Hat that do anything that anyone would say > is impossible. Had you said, back in Dec 2018, "I have C code such that > H(H_Hat, H_Hat) == 0 but H_Hat(H_Hat) halts" no one would have been > interested. > If you are sincere about an honest dialogue then we must quit focusing on details of obsolete technology. If you are sincere about an honest dialogue then we must quit focusing on details of obsolete technology. If you are sincere about an honest dialogue then we must quit focusing on details of obsolete technology. > I think you owe everyone an apology. Even if there was no indent to > deceive, your words back then did everything possible to suggest some > impossible Turing machine. And you wouldn't say, until recently, even > when explicitly asked, what decision H came to. It was fishy from the > start. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2021-07-31 15:48 -0700 |
| Subject | Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? ) |
| Message-ID | <se4k0i$sha$2@dont-email.me> |
| In reply to | #37424 |
On 7/31/21 2:57 PM, olcott wrote: > On 7/31/2021 4:54 PM, Ben Bacarisse wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> It matters not what I had. >> >> Because you can't justify it the honest debate you claim to want. >> >>> It only matters what I have. >> >> I.e. nothing of any interest. You make it plain in a previous reply >> that you've had nothing of interest going right back to the original >> deceptive claim. >> >>> If you are sincere about an honest dialogue then we must quit focusing >>> on details of obsolete technology. >> >> And yet you skipped the big picture part: >> >>>> (5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did >>>> your >>>> Dec 2018 code come to about "(Ĥ, Ĥ)"? >>> >>> The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that >>> H(P,P)==0 now except that the never halting criteria is much more >>> elaborate. The initial criteria was very crude. >> >> Ah, so you never had H and H_Hat that do anything that anyone would say >> is impossible. Had you said, back in Dec 2018, "I have C code such that >> H(H_Hat, H_Hat) == 0 but H_Hat(H_Hat) halts" no one would have been >> interested. >> > > If you are sincere about an honest dialogue then we must quit focusing > on details of obsolete technology. > > If you are sincere about an honest dialogue then we must quit focusing > on details of obsolete technology. > > If you are sincere about an honest dialogue then we must quit focusing > on details of obsolete technology. > What is obsolete? You have changed the NAME that you are calling H^, but it is still exactly the same machine, >> I think you owe everyone an apology. Even if there was no indent to >> deceive, your words back then did everything possible to suggest some >> impossible Turing machine. And you wouldn't say, until recently, even >> when explicitly asked, what decision H came to. It was fishy from the >> start. > > >
[toc] | [prev] | [next] | [standalone]
Page 22 of 27 — ← Prev page 1 … 20 21 [22] 23 24 … 27 Next page →
Back to top | Article view | comp.theory
csiph-web