Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #49506 > unrolled thread
| Started by | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| First post | 2022-05-02 16:47 +0100 |
| Last post | 2022-05-06 11:54 +0300 |
| Articles | 20 on this page of 215 — 14 participants |
Back to article view | Back to comp.theory
On recursion and infinite recursion (reprise) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-02 16:47 +0100
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-02 11:18 -0500
Re: On recursion and infinite recursion (reprise) Ben <ben.usenet@bsb.me.uk> - 2022-05-02 17:39 +0100
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-02 15:28 -0500
Re: On recursion and infinite recursion (reprise) Ben <ben.usenet@bsb.me.uk> - 2022-05-03 00:10 +0100
Re: H(P,P) == false is correct olcott <polcott2@gmail.com> - 2022-05-03 21:07 -0500
Re: H(P,P) == false is correct Ben <ben.usenet@bsb.me.uk> - 2022-05-04 15:16 +0100
Re: H(P,P) == false is correct olcott <polcott2@gmail.com> - 2022-05-04 14:27 -0500
Re: H(P,P) == false is correct Ben <ben.usenet@bsb.me.uk> - 2022-05-05 01:59 +0100
Re: H(P,P) == false is correct olcott <polcott2@gmail.com> - 2022-05-04 20:19 -0500
Re: H(P,P) == false is correct Ben <ben.usenet@bsb.me.uk> - 2022-05-05 03:28 +0100
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-04 21:55 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-04 19:59 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-04 22:09 -0500
Re: H(P,P) == false is correct [ verified facts ] André G. Isaak <agisaak@gm.invalid> - 2022-05-04 21:17 -0600
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-04 22:35 -0500
Re: H(P,P) == false is correct [ verified facts ] André G. Isaak <agisaak@gm.invalid> - 2022-05-04 21:38 -0600
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-04 22:42 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-04 20:50 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-04 22:58 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-04 21:07 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-04 23:48 -0500
Re: H(P,P) == false is correct [ verified facts ] Richard Damon <Richard@Damon-Family.org> - 2022-05-05 07:51 -0400
Re: H(P,P) == false is correct [ verified facts ] Richard Damon <Richard@Damon-Family.org> - 2022-05-05 07:50 -0400
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-05 04:57 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 13:01 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-05 11:03 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 13:45 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-05 11:50 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 16:43 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-04 20:20 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-04 22:38 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-04 20:43 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-04 22:54 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-04 21:12 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-04 23:49 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-05 04:54 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 11:12 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-05 09:20 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 13:32 -0500
Re: H(P,P) == false is correct [ verified facts ] Richard Damon <Richard@Damon-Family.org> - 2022-05-05 07:56 -0400
Re: H(P,P) == false is correct [ verified facts ] Richard Damon <Richard@Damon-Family.org> - 2022-05-05 07:54 -0400
Re: H(P,P) == false is correct [ verified facts ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-05 05:27 -0700
Re: H(P,P) == false is correct [ verified facts ] Ben <ben.usenet@bsb.me.uk> - 2022-05-05 14:14 +0100
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 16:53 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-05 15:11 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 17:31 -0500
Re: H(P,P) == false is correct [ verified facts ] Richard Damon <Richard@Damon-Family.org> - 2022-05-05 22:43 -0400
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 12:17 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-05 10:28 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 13:39 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-05 11:52 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 16:47 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-05 15:06 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 17:28 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-05 15:42 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 20:06 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-05 18:17 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 20:36 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-05 18:59 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 21:08 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-05 19:18 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 21:33 -0500
Re: H(P,P) == false is correct [ verified facts ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-05 19:50 -0700
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-06 01:35 -0500
Re: H(P,P) == false is correct [ verified facts ] Richard Damon <Richard@Damon-Family.org> - 2022-05-06 07:52 -0400
Re: H(P,P) == false is correct [ verified facts ] André G. Isaak <agisaak@gm.invalid> - 2022-05-05 20:51 -0600
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-06 14:07 -0500
Re: H(P,P) == false is correct [ verified facts ] André G. Isaak <agisaak@gm.invalid> - 2022-05-06 13:14 -0600
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-06 14:29 -0500
Re: H(P,P) == false is correct [ verified facts ] Richard Damon <Richard@Damon-Family.org> - 2022-05-05 07:46 -0400
Re: H(P,P) == false is correct [ verified facts ] Ben <ben.usenet@bsb.me.uk> - 2022-05-05 14:29 +0100
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 17:12 -0500
Re: H(P,P) == false is correct [ verified facts ] Python <python@example.invalid> - 2022-05-06 02:58 +0200
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 20:01 -0500
Re: H(P,P) == false is correct [ verified facts ] Python <python@example.invalid> - 2022-05-06 03:34 +0200
Re: H(P,P) == false is correct [ verified facts ] Ben <ben.usenet@bsb.me.uk> - 2022-05-06 03:35 +0100
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-05 21:57 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-05 22:29 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] Ben <ben.usenet@bsb.me.uk> - 2022-05-06 12:36 +0100
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-06 11:33 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] Ben <ben.usenet@bsb.me.uk> - 2022-05-07 02:57 +0100
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-06 21:22 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] Ben <ben.usenet@bsb.me.uk> - 2022-05-08 00:01 +0100
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <NoOne@NoWhere.com> - 2022-05-07 18:45 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] Ben <ben.usenet@bsb.me.uk> - 2022-05-08 00:59 +0100
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-07 12:31 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-05 23:48 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] André G. Isaak <agisaak@gm.invalid> - 2022-05-05 23:01 -0600
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-06 00:12 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] André G. Isaak <agisaak@gm.invalid> - 2022-05-06 07:36 -0600
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-06 10:32 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] André G. Isaak <agisaak@gm.invalid> - 2022-05-06 09:43 -0600
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-06 11:45 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] André G. Isaak <agisaak@gm.invalid> - 2022-05-06 11:01 -0600
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-06 13:03 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] André G. Isaak <agisaak@gm.invalid> - 2022-05-06 12:18 -0600
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-06 13:50 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] André G. Isaak <agisaak@gm.invalid> - 2022-05-06 13:05 -0600
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-06 14:19 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] André G. Isaak <agisaak@gm.invalid> - 2022-05-06 13:23 -0600
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-06 14:34 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] André G. Isaak <agisaak@gm.invalid> - 2022-05-06 13:37 -0600
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-06 14:48 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] Ben <ben.usenet@bsb.me.uk> - 2022-05-07 00:47 +0100
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-06 18:59 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] Ben <ben.usenet@bsb.me.uk> - 2022-05-07 03:04 +0100
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-06 21:26 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-06 23:03 -0500
Re: H(P,P) == false is correct [ Simple TM Interpreter ] olcott <polcott2@gmail.com> - 2022-05-06 00:55 -0500
Re: H(P,P) == false is correct [ verified facts ] Richard Damon <Richard@Damon-Family.org> - 2022-05-05 22:51 -0400
Re: H(P,P) == false is correct [ verified facts ] Mikko <mikko.levanto@iki.fi> - 2022-05-06 12:42 +0300
Re: H(P,P) == false is correct [ verified facts ] olcott <polcott2@gmail.com> - 2022-05-06 14:09 -0500
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-03 12:36 +0300
Re: On recursion and infinite recursion (reprise) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-03 04:08 -0700
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 09:33 -0500
Re: On recursion and infinite recursion (reprise) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-03 09:41 -0700
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 11:57 -0500
Re: On recursion and infinite recursion (reprise) Jeff Barnett <jbb@notatt.com> - 2022-05-03 12:53 -0600
Re: On recursion and infinite recursion (reprise) André G. Isaak <agisaak@gm.invalid> - 2022-05-03 13:02 -0600
Re: On recursion and infinite recursion (reprise) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-03 19:59 +0100
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 14:05 -0500
Re: On recursion and infinite recursion (reprise) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-03 14:51 -0700
Re: On recursion and infinite recursion (reprise) Jeff Barnett <jbb@notatt.com> - 2022-05-03 16:06 -0600
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 17:15 -0500
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 17:11 -0500
Re: On recursion and infinite recursion (reprise) Ben <ben.usenet@bsb.me.uk> - 2022-05-04 12:04 +0100
Re: On recursion and infinite recursion (reprise) Andy Walker <anw@cuboid.co.uk> - 2022-05-04 14:04 +0100
Re: On recursion and infinite recursion (reprise) Ben <ben.usenet@bsb.me.uk> - 2022-05-04 14:48 +0100
Re: On recursion and infinite recursion (reprise) Python <python@example.invalid> - 2022-05-04 00:21 +0200
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 17:40 -0500
Re: On recursion and infinite recursion (reprise) Python <python@example.invalid> - 2022-05-04 00:46 +0200
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 17:49 -0500
Re: On recursion and infinite recursion (reprise) Python <python@example.invalid> - 2022-05-04 01:05 +0200
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 18:48 -0500
Re: On recursion and infinite recursion (reprise) Ben <ben.usenet@bsb.me.uk> - 2022-05-04 12:15 +0100
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-04 11:24 -0500
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-04 18:51 -0400
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 09:38 -0500
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-03 20:17 +0300
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 13:06 -0500
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-04 10:19 +0300
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-04 12:57 -0500
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-04 18:53 -0400
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-05 12:37 +0300
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-05 12:52 -0500
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-06 12:23 +0300
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-06 14:14 -0500
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-07 11:42 +0300
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-07 11:16 -0500
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-08 11:21 +0300
Re: On recursion and infinite recursion (reprise) olcott <NoOne@NoWhere.com> - 2022-05-09 10:41 -0500
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-09 19:45 +0300
Re: On recursion and infinite recursion (reprise) olcott <NoOne@NoWhere.com> - 2022-05-09 12:11 -0500
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-09 19:21 -0400
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-10 10:34 +0300
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 13:13 -0500
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-03 21:58 -0400
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-02 18:32 -0400
Re: On recursion and infinite recursion (reprise) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-02 23:38 +0100
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-02 18:46 -0400
Re: On recursion and infinite recursion (reprise) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-02 23:47 +0100
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-02 19:16 -0400
Re: On recursion and infinite recursion (reprise) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-03 00:30 +0100
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-02 20:40 -0400
Re: On recursion and infinite recursion (reprise) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-03 20:06 +0100
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 14:17 -0500
Re: On recursion and infinite recursion (reprise) Python <python@example.invalid> - 2022-05-04 00:23 +0200
Re: On recursion and infinite recursion (reprise) Ben <ben.usenet@bsb.me.uk> - 2022-05-04 12:24 +0100
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-03 21:54 -0400
Re: On recursion and infinite recursion (reprise) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-04 17:40 +0100
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-04 12:46 -0500
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-04 19:23 -0400
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-02 19:35 -0500
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-02 20:48 -0400
Re: On recursion and infinite recursion (reprise) wij wij <wyniijj2@gmail.com> - 2022-05-03 05:12 -0700
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 09:31 -0500
Re: On recursion and infinite recursion (reprise) Dennis Bush <dbush.mobile@gmail.com> - 2022-05-03 07:47 -0700
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 10:19 -0500
Re: On recursion and infinite recursion (reprise) Dennis Bush <dbush.mobile@gmail.com> - 2022-05-03 08:36 -0700
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 11:39 -0500
Re: On recursion and infinite recursion (reprise) Dennis Bush <dbush.mobile@gmail.com> - 2022-05-03 14:49 -0700
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 17:08 -0500
Re: On recursion and infinite recursion (reprise) Dennis Bush <dbush.mobile@gmail.com> - 2022-05-03 15:21 -0700
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 17:32 -0500
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-03 21:47 -0400
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-03 12:31 +0300
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 09:42 -0500
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-03 20:27 +0300
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-03 13:13 -0500
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-03 21:38 -0400
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-09 19:58 +0300
Re: On recursion and infinite recursion (reprise) olcott <NoOne@NoWhere.com> - 2022-05-09 12:16 -0500
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-09 19:30 -0400
Re: On recursion and infinite recursion (reprise) wij <wyniijj2@gmail.com> - 2022-05-10 08:40 -0700
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-03 21:41 -0400
Re: On recursion and infinite recursion (reprise) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-03 19:26 +0100
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-04 10:31 +0300
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-04 13:09 -0500
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-08 11:09 +0300
Re: On recursion and infinite recursion (reprise) olcott <NoOne@NoWhere.com> - 2022-05-09 10:39 -0500
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-09 19:48 +0300
Re: On recursion and infinite recursion (reprise) olcott <NoOne@NoWhere.com> - 2022-05-09 12:12 -0500
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-05 12:19 +0300
Re: On recursion and infinite recursion (reprise) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-05 17:54 +0100
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-05 22:56 -0400
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-06 11:50 +0300
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-05 12:46 -0500
Re: On recursion and infinite recursion (reprise) Ben <ben.usenet@bsb.me.uk> - 2022-05-05 21:00 +0100
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-05 17:16 -0500
Re: On recursion and infinite recursion (reprise) Ben <ben.usenet@bsb.me.uk> - 2022-05-06 02:21 +0100
Re: On recursion and infinite recursion (reprise) olcott <polcott2@gmail.com> - 2022-05-05 20:37 -0500
Re: On recursion and infinite recursion (reprise) Ben <ben.usenet@bsb.me.uk> - 2022-05-06 03:46 +0100
Re: On recursion and infinite recursion (reprise) Richard Damon <Richard@Damon-Family.org> - 2022-05-05 18:41 -0400
Re: On recursion and infinite recursion (reprise) Mikko <mikko.levanto@iki.fi> - 2022-05-06 11:54 +0300
Page 1 of 11 [1] 2 3 … 11 Next page →
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-02 16:47 +0100 |
| Subject | On recursion and infinite recursion (reprise) |
| Message-ID | <20220502164732.00004e01@reddwarf.jmc> |
Not all infinitely recursive definitions are invalid however infinitely recursive definitions that arise out of a category error (as is the case with the halting problem) are invalid. The halting problem (as currently defined) is invalid due to the invalid "impossible program" [Strachey, 1965] that is actually impossible due to the category error present in its definition and *not* because of any function call-like recursion; confusion between these two types of recursion are why Olcott is having difficulty communicating his ideas with the rest of you shower. The categories involved in the category error are the decider and that which is being decided. Currently extant attempts to conflate the decider with that which is being decided are infinitely recursive and thus invalid. /Flibble
[toc] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-05-02 11:18 -0500 |
| Message-ID | <t4p08u$5ar$1@dont-email.me> |
| In reply to | #49506 |
On 5/2/2022 10:47 AM, Mr Flibble wrote:
> Not all infinitely recursive definitions are invalid however infinitely
> recursive definitions that arise out of a category error (as is the
> case with the halting problem) are invalid.
>
It seems to me that all infinitely recursive definitions are invalid and
I am having an excellent dialogue with some Prolog folks about this in
comp.lang.prolog.
> The halting problem (as currently defined) is invalid due to the
> invalid "impossible program" [Strachey, 1965] that is actually
> impossible due to the category error present in its definition and
> *not* because of any function call-like recursion; confusion between
> these two types of recursion are why Olcott is having difficulty
> communicating his ideas with the rest of you shower.
>
I created the x86 operating system taking at least a man-year so that I
could encode the HP counter-example P in C/x86 and then create a halt
decider H in C that examines the behavior of its correct simulation of P.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08]
[000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08]
[000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call 00000826 // call H
[000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[000009d6][00211368][0021136c] 55 push ebp // enter P
...[000009d7][00211368][0021136c] 8bec mov ebp,esp
...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
...[000009dc][00211364][000009d6] 50 push eax // Push P
...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
...[000009e0][00211360][000009d6] 51 push ecx // Push P
...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
...[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
...[000009dc][0025bd8c][000009d6] 50 push eax // Push P
...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
...[000009e0][0025bd88][000009d6] 51 push ecx // Push P
...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
It is clear that the input to H(P,P) specifies infinitely nested
simulation to H.
> The categories involved in the category error are the decider and that
> which is being decided. Currently extant attempts to conflate the
> decider with that which is being decided are infinitely
> recursive and thus invalid.
>
> /Flibble
>
I already applied your idea of category error to Gödel's Incompleteness
and Tarski Undefinability. In both of these cases the Gödel H and the
Tarski p are incorrectly placed in the category of truth bearer / logic
sentence. They cannot be correctly evaluated because they are
semantically incorrect.
Now in comp.lang.prolog we are getting Prolog to agree that they are
semantically ill-formed.
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-02 17:39 +0100 |
| Message-ID | <87wnf3ga8h.fsf@bsb.me.uk> |
| In reply to | #49508 |
olcott <polcott2@gmail.com> writes: > It is clear that the input to H(P,P) specifies infinitely nested > simulation to H. What two pointers must be passed to H for H to tell up about the halting of P(P)? If H can't report on the halting of the computation P(P) it is not a halt decider, and you have already told use that H(P,P) == false and that P(P) halts. You have nowhere to go with H, hence your switching topics to being wrong about Gödel again. -- Ben. "le génie humain a des limites, quand la bêtise humaine n’en a pas" Alexandre Dumas (fils)
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-05-02 15:28 -0500 |
| Message-ID | <t4pesp$d9n$1@dont-email.me> |
| In reply to | #49510 |
On 5/2/2022 11:39 AM, Ben wrote: > olcott <polcott2@gmail.com> writes: > >> It is clear that the input to H(P,P) specifies infinitely nested >> simulation to H. > > What two pointers must be passed to H for H to tell up about the halting > of P(P)? If H can't report on the halting of the computation P(P) it is > not a halt decider, and you have already told use that H(P,P) == false > and that P(P) halts. If H can report on the halting of non-input P(P) then it is not a decider because deciders only compute the mapping from inputs to final states. > > You have nowhere to go with H, hence your switching topics to being > wrong about Gödel again. > That you expect a halt decider to compute the mapping from non-inputs is a little nuts when you know that deciders can't possibly do this. It turns out that I can create a whole TM interpreter from scratch quicker than I can learn the extraneous complexity of the TM Interpreter http://www.lns.mit.edu/~dsw/turing/turing.html It will have the same eight-bit quintuples of the TM, The Turing Machine Interpreter. These will be at the beginning of the file, followed by BEGIN_TAPE on a line by itself. Followed by the initial tape as contiguous ASCII characters. It will output a full execution trace. The only parameter to the command line system with be filename.tm. This system is easily extended to 16-bits or 32-bits. These larger systems will use 4-8 hex digits for state / character representation. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-03 00:10 +0100 |
| Message-ID | <87fslrfs3t.fsf@bsb.me.uk> |
| In reply to | #49517 |
olcott <polcott2@gmail.com> writes: > On 5/2/2022 11:39 AM, Ben wrote: >> olcott <polcott2@gmail.com> writes: >> >>> It is clear that the input to H(P,P) specifies infinitely nested >>> simulation to H. >> What two pointers must be passed to H for H to tell up about the halting >> of P(P)? If H can't report on the halting of the computation P(P) it is >> not a halt decider, and you have already told use that H(P,P) == false >> and that P(P) halts. > > If H can report on the halting of non-input P(P) then it is not a > decider because deciders only compute the mapping from inputs to final > states. TM deciders compute mappings from inputs to final states /according to some property of the inputs/ -- whether the input represents, for example, an even number, a prime number or a halting computation. According to you there is no "input" (in reality a pair of pointers) that represents the halting computation P(P). Why should anyone care about this H if it does not decide what we want -- the halting of the function call represented by the two arguments to H? Whatever H is actually deciding is not interesting. Also, I wonder why you wasted so much time justifying the fact that H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not even supposed to be deciding the halting P(P). Well, we know, of course. You realised you were in a hole so you started to dig sideways. You used to know that H(X,Y) had to decide the halting of X(Y). You're now pretending it never did! > That you expect a halt decider to compute the mapping from non-inputs > is a little nuts when you know that deciders can't possibly do this. Don't be silly. They decide properties of inputs -- parity, halting and so on. You'd know this if you'd done even the warm-up exercises I set. How are they coming along? It looks like you have found an excuse to bail out again: > It turns out that I can create a whole TM interpreter from scratch > quicker than I can learn the extraneous complexity of the TM > Interpreter http://www.lns.mit.edu/~dsw/turing/turing.html I doubt it. But I suppose you think that's a reasonable excuse. Of course, some of us remember you saying writing such a thing would take about a week three years ago. I remember wondering how such a simple program could take you a week to write. Of course you don't need an interpreter to write E or specify P, but you must find some excuse for bailing out. -- Ben. "le génie humain a des limites, quand la bêtise humaine n’en a pas" Alexandre Dumas (fils)
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-05-03 21:07 -0500 |
| Subject | Re: H(P,P) == false is correct |
| Message-ID | <t4sn5q$9nr$1@dont-email.me> |
| In reply to | #49528 |
On 5/2/2022 6:10 PM, Ben wrote: > olcott <polcott2@gmail.com> writes: > >> On 5/2/2022 11:39 AM, Ben wrote: >>> olcott <polcott2@gmail.com> writes: >>> >>>> It is clear that the input to H(P,P) specifies infinitely nested >>>> simulation to H. >>> What two pointers must be passed to H for H to tell up about the halting >>> of P(P)? If H can't report on the halting of the computation P(P) it is >>> not a halt decider, and you have already told use that H(P,P) == false >>> and that P(P) halts. >> >> If H can report on the halting of non-input P(P) then it is not a >> decider because deciders only compute the mapping from inputs to final >> states. > > TM deciders compute mappings from inputs to final states /according to > some property of the inputs/ That par is exactly correct. > -- whether the input represents, for That part has been the key error of everyone in that they all believe that is can represent something other than what it actually specifies. The correct simulation of the input to H(P,P) specifies non-halting behavior. Clueless wonders that don't know the first thing about the x86 language assume that this simulation is incorrect even though is is nearly trivial to determine that the simulation is correct as a verified fact. That they contradict verified facts entirely one the basis that they are incompetent to verify that it is a fact is the worst hubris. > example, an even number, a prime number or a halting computation. > > According to you there is no "input" (in reality a pair of pointers) > that represents the halting computation P(P). Why should anyone care > about this H if it does not decide what we want -- the halting of the > function call represented by the two arguments to H? Whatever H is > actually deciding is not interesting. (a) H does correctly decide its input (b) H is only required to decide its input. (c) Therefore H(P,P) is entirely correct on the "impossible" input. > Also, I wonder why you wasted so much time justifying the fact that > H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not > even supposed to be deciding the halting P(P). Well, we know, of > course. You realised you were in a hole so you started to dig sideways. > You used to know that H(X,Y) had to decide the halting of X(Y). You're > now pretending it never did! > >> That you expect a halt decider to compute the mapping from non-inputs >> is a little nuts when you know that deciders can't possibly do this. > > Don't be silly. They decide properties of inputs -- parity, halting and > so on. You'd know this if you'd done even the warm-up exercises I set. The problem here is that you expect that the property of an input not be the actual property of the actual input but the property of a non-input. The halting property of the input to H(P,P) is the actual behavior of the correct simulation of this input and thus not at all what you simply imagine this property should be. > How are they coming along? It looks like you have found an excuse to > bail out again: > It is coming along great and it is wonderful fun. I think that it is a great idea to move in this direction. I may eventually convert C copy of the TM into a RASP machine. I probably won't begin to do that until after we finish our exercises. >> It turns out that I can create a whole TM interpreter from scratch >> quicker than I can learn the extraneous complexity of the TM >> Interpreter http://www.lns.mit.edu/~dsw/turing/turing.html > > I doubt it. But I suppose you think that's a reasonable excuse. Of > course, some of us remember you saying writing such a thing would take > about a week three years ago. I remember wondering how such a simple > program could take you a week to write. As soon as I complete the detailed design I should have an accurate estimate of the total time. It currently looks like < 4 hours. I have spent 15 minutes on the detailed design and it looks like it will take 45 more minutes. One thing that is great is that I have fully recovered from what could have been a life threatening infection. I was in the hospital getting IV antibiotics for nearly two days. Chemotherapy patients have a few days after chemotherapy where their immune system is very close to zero. > > Of course you don't need an interpreter to write E or specify P, but you > must find some excuse for bailing out. > It is much better (and more fun) if I make this totally concrete. One can not effectively debug code by desk checking. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-04 15:16 +0100 |
| Subject | Re: H(P,P) == false is correct |
| Message-ID | <874k25qt5y.fsf@bsb.me.uk> |
| In reply to | #49629 |
olcott <polcott2@gmail.com> writes: > On 5/2/2022 6:10 PM, Ben wrote: >> olcott <polcott2@gmail.com> writes: >> >>> On 5/2/2022 11:39 AM, Ben wrote: >>>> olcott <polcott2@gmail.com> writes: >>>> >>>>> It is clear that the input to H(P,P) specifies infinitely nested >>>>> simulation to H. >>>> What two pointers must be passed to H for H to tell up about the halting >>>> of P(P)? If H can't report on the halting of the computation P(P) it is >>>> not a halt decider, and you have already told use that H(P,P) == false >>>> and that P(P) halts. >>> >>> If H can report on the halting of non-input P(P) then it is not a >>> decider because deciders only compute the mapping from inputs to final >>> states. >> TM deciders compute mappings from inputs to final states /according to >> some property of the inputs/ > > That par is exactly correct. > >> -- whether the input represents, for > > That part has been the key error of everyone in that they all believe > that is can represent something other than what it actually specifies. So now, after thinking otherwise for years, you claim that there is no way to even specify the computation P(P) for you pseudo-C halt decider H. At least that is a clear admission that the halting of function calls like P(P) can not be decided because, apparently, passing P and P to H does not specify that computation, and you can't say what two arguments /would/ specify it. A clear and unambiguous statement that no D such that D(X,Y) == true if and only if X(Y) halts and false otherwise is possible would be the honest way to move things on. If you were clear about this, maybe someone will talk to you about whether it is that your H is deciding. >> example, an even number, a prime number or a halting computation. >> According to you there is no "input" (in reality a pair of pointers) >> that represents the halting computation P(P). Why should anyone care >> about this H if it does not decide what we want -- the halting of the >> function call represented by the two arguments to H? Whatever H is >> actually deciding is not interesting. > > (a) H does correctly decide its input But no one cares about that as it's not what we want a decider for. > (b) H is only required to decide its input. And it seems that you agree that no D such that D(X,Y) == true if and only if X(Y) halts and false otherwise is possible. That's the D that the world cares about. > (c) Therefore H(P,P) is entirely correct on the "impossible" input. It decides some property of the pair of pointers P and P, but not the one people care about: the halting or otherwise of the function call P(P). >> Also, I wonder why you wasted so much time justifying the fact that >> H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not >> even supposed to be deciding the halting P(P). Well, we know, of >> course. You realised you were in a hole so you started to dig sideways. >> You used to know that H(X,Y) had to decide the halting of X(Y). You're >> now pretending it never did! Why /did/ you waste so much time trying to convince us that H(P,P) == false was correct even though P(P) halted if you never intended H(P,P) to report on the halting of P(P)? >> You'd know this if you'd done even the warm-up exercises I set. <snip the usual waffle> >> How are they coming along? It looks like you have found an excuse to >> bail out again: > > It is coming along great and it is wonderful fun. It's good that it's fun, but it seems to be taking a long time. I'd expect students to be able to write E and specify P "live" in a tutorial -- i.e. it would take a couple of minutes and we could the discuss more interesting examples. The specification of TM's is your stumbling block, so you could be doing that in parallel. > I think that it is a great idea to move in this direction. > I may eventually convert C copy of the TM into a RASP machine. Do ever read what you write? What is a "C copy of the TM"? I think you mean the TM interpreter that you've decided to write so as to delay actually writing even a trivial TM. -- Ben. "le génie humain a des limites, quand la bêtise humaine n’en a pas" Alexandre Dumas (fils)
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-05-04 14:27 -0500 |
| Subject | Re: H(P,P) == false is correct |
| Message-ID | <t4uk3c$knu$1@dont-email.me> |
| In reply to | #49649 |
On 5/4/2022 9:16 AM, Ben wrote: > olcott <polcott2@gmail.com> writes: > >> On 5/2/2022 6:10 PM, Ben wrote: >>> olcott <polcott2@gmail.com> writes: >>> >>>> On 5/2/2022 11:39 AM, Ben wrote: >>>>> olcott <polcott2@gmail.com> writes: >>>>> >>>>>> It is clear that the input to H(P,P) specifies infinitely nested >>>>>> simulation to H. >>>>> What two pointers must be passed to H for H to tell up about the halting >>>>> of P(P)? If H can't report on the halting of the computation P(P) it is >>>>> not a halt decider, and you have already told use that H(P,P) == false >>>>> and that P(P) halts. >>>> >>>> If H can report on the halting of non-input P(P) then it is not a >>>> decider because deciders only compute the mapping from inputs to final >>>> states. >>> TM deciders compute mappings from inputs to final states /according to >>> some property of the inputs/ >> >> That par is exactly correct. >> >>> -- whether the input represents, for >> >> That part has been the key error of everyone in that they all believe >> that is can represent something other than what it actually specifies. > > So now, after thinking otherwise for years, you claim that there is no > way to even specify the computation P(P) for you pseudo-C halt decider > H. At least that is a clear admission that the halting of function > calls like P(P) can not be decided because, apparently, passing P and P > to H does not specify that computation, and you can't say what two > arguments /would/ specify it. > > A clear and unambiguous statement that no D such that D(X,Y) == true if > and only if X(Y) halts and false otherwise is possible would be the > honest way to move things on. If you were clear about this, maybe > someone will talk to you about whether it is that your H is deciding. > I adapted my system so that I could empirically test this: H1(P,P)==true is empirically proven to be correct H(P,P)==false is empirically proven to be correct Both deciders correctly report on the actual behavior of their actual input. This can be verified by carefully studying their execution trace. >>> example, an even number, a prime number or a halting computation. >>> According to you there is no "input" (in reality a pair of pointers) >>> that represents the halting computation P(P). Why should anyone care >>> about this H if it does not decide what we want -- the halting of the >>> function call represented by the two arguments to H? Whatever H is >>> actually deciding is not interesting. >> >> (a) H does correctly decide its input > > But no one cares about that as it's not what we want a decider for. > >> (b) H is only required to decide its input. > > And it seems that you agree that no D such that D(X,Y) == true if and > only if X(Y) halts and false otherwise is possible. That's the D that > the world cares about. > >> (c) Therefore H(P,P) is entirely correct on the "impossible" input. > > It decides some property of the pair of pointers P and P, but not the > one people care about: the halting or otherwise of the function call > P(P). > >>> Also, I wonder why you wasted so much time justifying the fact that >>> H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not >>> even supposed to be deciding the halting P(P). Well, we know, of >>> course. You realised you were in a hole so you started to dig sideways. >>> You used to know that H(X,Y) had to decide the halting of X(Y). You're >>> now pretending it never did! > > Why /did/ you waste so much time trying to convince us that H(P,P) == > false was correct even though P(P) halted if you never intended H(P,P) > to report on the halting of P(P)? > >>> You'd know this if you'd done even the warm-up exercises I set. > > <snip the usual waffle> > >>> How are they coming along? It looks like you have found an excuse to >>> bail out again: >> >> It is coming along great and it is wonderful fun. > > It's good that it's fun, but it seems to be taking a long time. I'd > expect students to be able to write E and specify P "live" in a tutorial > -- i.e. it would take a couple of minutes and we could the discuss more > interesting examples. I have had some serious health issues that could have killed me last week. > > The specification of TM's is your stumbling block, so you could be doing > that in parallel. I like to go through all of the best steps in order. Having a machine to execute TM's is the first step. (a) Deciding to get around to start this project took weeks when dealing with my other issues. (b) No setting up the tedious syntax of reading a file of text lines took much longer than usual, I usually cut-and-paste. (c) I studied enough of the http://www.lns.mit.edu/~dsw/turing/turing.html To realize it was a superb architecture yet an overly complex implementation. Other people can read much faster than me, yet they lose a lot of meaning when they read this fast. I usually read something over and over until I have 100% complete understanding. When I was reading the specs for how VISA changed their system so that I could adapt the bank's system to meet these changed specs I had to read the VISA material 17 times. I only had to read the Discover card changes three times. > >> I think that it is a great idea to move in this direction. >> I may eventually convert C copy of the TM into a RASP machine. > > Do ever read what you write? What is a "C copy of the TM"? I think you > mean the TM interpreter that you've decided to write so as to delay > actually writing even a trivial TM. > I am going to write a TM interpreter in C++. Sometime after I get done with this I may adapt it to becoming an RASP machine. I will keep the original TM interpreter and not simply overwrite it with the RASP machine. This requires that the changes must be to a copy of the TM interpreter. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-05 01:59 +0100 |
| Subject | Re: H(P,P) == false is correct |
| Message-ID | <87v8ukpzfi.fsf@bsb.me.uk> |
| In reply to | #49671 |
olcott <polcott2@gmail.com> writes: > On 5/4/2022 9:16 AM, Ben wrote: >> olcott <polcott2@gmail.com> writes: >> >>> On 5/2/2022 6:10 PM, Ben wrote: >>>> olcott <polcott2@gmail.com> writes: >>>> >>>>> On 5/2/2022 11:39 AM, Ben wrote: >>>>>> olcott <polcott2@gmail.com> writes: >>>>>> >>>>>>> It is clear that the input to H(P,P) specifies infinitely nested >>>>>>> simulation to H. >>>>>> What two pointers must be passed to H for H to tell up about the halting >>>>>> of P(P)? If H can't report on the halting of the computation P(P) it is >>>>>> not a halt decider, and you have already told use that H(P,P) == false >>>>>> and that P(P) halts. >>>>> >>>>> If H can report on the halting of non-input P(P) then it is not a >>>>> decider because deciders only compute the mapping from inputs to final >>>>> states. >>>> TM deciders compute mappings from inputs to final states /according to >>>> some property of the inputs/ >>> >>> That par is exactly correct. >>> >>>> -- whether the input represents, for >>> >>> That part has been the key error of everyone in that they all believe >>> that is can represent something other than what it actually specifies. >> >> So now, after thinking otherwise for years, you claim that there is no >> way to even specify the computation P(P) for you pseudo-C halt decider >> H. At least that is a clear admission that the halting of function >> calls like P(P) can not be decided because, apparently, passing P and P >> to H does not specify that computation, and you can't say what two >> arguments /would/ specify it. >> >> A clear and unambiguous statement that no D such that D(X,Y) == true if >> and only if X(Y) halts and false otherwise is possible would be the >> honest way to move things on. If you were clear about this, maybe >> someone will talk to you about [whatever] it is that your H is >> deciding. So you won't admit that no algorithm can do what D is specified to do? You are just going to pretend that no one cares about actual halting. I hope you see that by ignoring this point you are confirming that you know D can't exist. If you thought such a D was possible, you'd be shouting that from the roof tops since it's what everyone else says is impossible. > I adapted my system so that I could empirically test this: > H1(P,P)==true is empirically proven to be correct > H(P,P)==false is empirically proven to be correct But neither can tell us squat about the halting of P(P) -- the thing that H was originally supposed to decide. > Both deciders correctly report on the actual behavior of their actual > input. This can be verified by carefully studying their execution > trace. But neither can tell us what we want. Your H does not meet D's specification, but you are not brave enough to admit that you now know that D can't exist because denying that is what got you started down this rabbit hole 18 years ago. > >>>> example, an even number, a prime number or a halting computation. >>>> According to you there is no "input" (in reality a pair of pointers) >>>> that represents the halting computation P(P). Why should anyone care >>>> about this H if it does not decide what we want -- the halting of the >>>> function call represented by the two arguments to H? Whatever H is >>>> actually deciding is not interesting. >>> >>> (a) H does correctly decide its input >> But no one cares about that as it's not what we want a decider for. >> >>> (b) H is only required to decide its input. >> And it seems that you agree that no D such that D(X,Y) == true if and >> only if X(Y) halts and false otherwise is possible. That's the D that >> the world cares about. >> >>> (c) Therefore H(P,P) is entirely correct on the "impossible" input. >> It decides some property of the pair of pointers P and P, but not the >> one people care about: the halting or otherwise of the function call >> P(P). >> >>>> Also, I wonder why you wasted so much time justifying the fact that >>>> H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not >>>> even supposed to be deciding the halting P(P). Well, we know, of >>>> course. You realised you were in a hole so you started to dig sideways. >>>> You used to know that H(X,Y) had to decide the halting of X(Y). You're >>>> now pretending it never did! >> Why /did/ you waste so much time trying to convince us that H(P,P) == >> false was correct even though P(P) halted if you never intended H(P,P) >> to report on the halting of P(P)? >> >>>> You'd know this if you'd done even the warm-up exercises I set. >> <snip the usual waffle> >> >>>> How are they coming along? It looks like you have found an excuse to >>>> bail out again: >>> >>> It is coming along great and it is wonderful fun. >> It's good that it's fun, but it seems to be taking a long time. I'd >> expect students to be able to write E and specify P "live" in a tutorial >> -- i.e. it would take a couple of minutes and we could the discuss more >> interesting examples. > > I have had some serious health issues that could have killed me last > week. You have been able to write dozens of posts, so why not the few words needed to specify P, or the few states needed for E? And even now you've taken on a task that seems too much for you rather than get down to writing and specifying a TM. It looks like avoidance. >> The specification of TM's is your stumbling block, so you could be doing >> that in parallel. > > I like to go through all of the best steps in order. Having a machine > to execute TM's is the first step. The firsts step is to be able to specify a TM. You can't have anything to execute of you can't specify it. It's just avoidance. > (a) Deciding to get around to start this project took weeks when > dealing with my other issues. You decided to start weeks ago. Then you gave up. > (b) No setting up the tedious syntax of reading a file of text lines > took much longer than usual, I usually cut-and-paste. What? I thought you knew C++ and could write code. > (c) I studied enough of the > http://www.lns.mit.edu/~dsw/turing/turing.html > To realize it was a superb architecture yet an overly complex > implementation. I hate it, but you chose it /five years ago/. Five years ago I suggested a simple exercise and you bailed them. I'd forgotten that. I should learn, shouldn't I? -- Ben. "le génie humain a des limites, quand la bêtise humaine n’en a pas" Alexandre Dumas (fils)
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-05-04 20:19 -0500 |
| Subject | Re: H(P,P) == false is correct |
| Message-ID | <t4v8n3$5s1$1@dont-email.me> |
| In reply to | #49687 |
On 5/4/2022 7:59 PM, Ben wrote: > olcott <polcott2@gmail.com> writes: > >> On 5/4/2022 9:16 AM, Ben wrote: >>> olcott <polcott2@gmail.com> writes: >>> >>>> On 5/2/2022 6:10 PM, Ben wrote: >>>>> olcott <polcott2@gmail.com> writes: >>>>> >>>>>> On 5/2/2022 11:39 AM, Ben wrote: >>>>>>> olcott <polcott2@gmail.com> writes: >>>>>>> >>>>>>>> It is clear that the input to H(P,P) specifies infinitely nested >>>>>>>> simulation to H. >>>>>>> What two pointers must be passed to H for H to tell up about the halting >>>>>>> of P(P)? If H can't report on the halting of the computation P(P) it is >>>>>>> not a halt decider, and you have already told use that H(P,P) == false >>>>>>> and that P(P) halts. >>>>>> >>>>>> If H can report on the halting of non-input P(P) then it is not a >>>>>> decider because deciders only compute the mapping from inputs to final >>>>>> states. >>>>> TM deciders compute mappings from inputs to final states /according to >>>>> some property of the inputs/ >>>> >>>> That par is exactly correct. >>>> >>>>> -- whether the input represents, for >>>> >>>> That part has been the key error of everyone in that they all believe >>>> that is can represent something other than what it actually specifies. >>> >>> So now, after thinking otherwise for years, you claim that there is no >>> way to even specify the computation P(P) for you pseudo-C halt decider >>> H. At least that is a clear admission that the halting of function >>> calls like P(P) can not be decided because, apparently, passing P and P >>> to H does not specify that computation, and you can't say what two >>> arguments /would/ specify it. >>> >>> A clear and unambiguous statement that no D such that D(X,Y) == true if >>> and only if X(Y) halts and false otherwise is possible would be the >>> honest way to move things on. If you were clear about this, maybe >>> someone will talk to you about [whatever] it is that your H is >>> deciding. > > So you won't admit that no algorithm can do what D is specified to do? > You are just going to pretend that no one cares about actual halting. > > I hope you see that by ignoring this point you are confirming that you > know D can't exist. If you thought such a D was possible, you'd be > shouting that from the roof tops since it's what everyone else says is > impossible. > >> I adapted my system so that I could empirically test this: >> H1(P,P)==true is empirically proven to be correct >> H(P,P)==false is empirically proven to be correct > > But neither can tell us squat about the halting of P(P) -- the thing > that H was originally supposed to decide. > Are you simply wired to ignore my words so that you can disagree with everything that I say? H1(P,P)==true reports on the behavior of P(P). >> Both deciders correctly report on the actual behavior of their actual >> input. This can be verified by carefully studying their execution >> trace. > > But neither can tell us what we want. H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). H1(P,P)==true reports on the behavior of P(P). > Your H does not meet D's > specification, but you are not brave enough to admit that you now know > that D can't exist because denying that is what got you started down > this rabbit hole 18 years ago. > > >> >>>>> example, an even number, a prime number or a halting computation. >>>>> According to you there is no "input" (in reality a pair of pointers) >>>>> that represents the halting computation P(P). Why should anyone care >>>>> about this H if it does not decide what we want -- the halting of the >>>>> function call represented by the two arguments to H? Whatever H is >>>>> actually deciding is not interesting. >>>> >>>> (a) H does correctly decide its input >>> But no one cares about that as it's not what we want a decider for. >>> >>>> (b) H is only required to decide its input. >>> And it seems that you agree that no D such that D(X,Y) == true if and >>> only if X(Y) halts and false otherwise is possible. That's the D that >>> the world cares about. >>> >>>> (c) Therefore H(P,P) is entirely correct on the "impossible" input. >>> It decides some property of the pair of pointers P and P, but not the >>> one people care about: the halting or otherwise of the function call >>> P(P). >>> >>>>> Also, I wonder why you wasted so much time justifying the fact that >>>>> H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not >>>>> even supposed to be deciding the halting P(P). Well, we know, of >>>>> course. You realised you were in a hole so you started to dig sideways. >>>>> You used to know that H(X,Y) had to decide the halting of X(Y). You're >>>>> now pretending it never did! >>> Why /did/ you waste so much time trying to convince us that H(P,P) == >>> false was correct even though P(P) halted if you never intended H(P,P) >>> to report on the halting of P(P)? >>> >>>>> You'd know this if you'd done even the warm-up exercises I set. >>> <snip the usual waffle> >>> >>>>> How are they coming along? It looks like you have found an excuse to >>>>> bail out again: >>>> >>>> It is coming along great and it is wonderful fun. >>> It's good that it's fun, but it seems to be taking a long time. I'd >>> expect students to be able to write E and specify P "live" in a tutorial >>> -- i.e. it would take a couple of minutes and we could the discuss more >>> interesting examples. >> >> I have had some serious health issues that could have killed me last >> week. > > You have been able to write dozens of posts, so why not the few words > needed to specify P, or the few states needed for E? And even now > you've taken on a task that seems too much for you rather than get down > to writing and specifying a TM. It looks like avoidance. > >>> The specification of TM's is your stumbling block, so you could be doing >>> that in parallel. >> >> I like to go through all of the best steps in order. Having a machine >> to execute TM's is the first step. > > The firsts step is to be able to specify a TM. You can't have anything > to execute of you can't specify it. It's just avoidance. > I am a concrete thinker, abstractions are always far too vague. >> (a) Deciding to get around to start this project took weeks when >> dealing with my other issues. > > You decided to start weeks ago. Then you gave up. I am dead set on finishing it now. > >> (b) No setting up the tedious syntax of reading a file of text lines >> took much longer than usual, I usually cut-and-paste. > > What? I thought you knew C++ and could write code. > On this tedious syntax details I always cut-and-paste from working code. I hate tedious syntax details. Engineering algorithms is what I enjoy. >> (c) I studied enough of the >> http://www.lns.mit.edu/~dsw/turing/turing.html >> To realize it was a superb architecture yet an overly complex >> implementation. > > I hate it, but you chose it /five years ago/. Five years ago I > suggested a simple exercise and you bailed them. I'd forgotten that. I > should learn, shouldn't I? > I don't hate it, it does have a superb architecture that I will quickly implement. I don't want to have to always enter the tape initialization manually and want this in the machine description file. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-05 03:28 +0100 |
| Subject | Re: H(P,P) == false is correct |
| Message-ID | <87h764pvb7.fsf@bsb.me.uk> |
| In reply to | #49688 |
olcott <polcott2@gmail.com> writes:
> On 5/4/2022 7:59 PM, Ben wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> On 5/4/2022 9:16 AM, Ben wrote:
>>>> olcott <polcott2@gmail.com> writes:
>>>>
>>>>> On 5/2/2022 6:10 PM, Ben wrote:
>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>
>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>
>>>>>>>>> It is clear that the input to H(P,P) specifies infinitely nested
>>>>>>>>> simulation to H.
>>>>>>>> What two pointers must be passed to H for H to tell up about the halting
>>>>>>>> of P(P)? If H can't report on the halting of the computation P(P) it is
>>>>>>>> not a halt decider, and you have already told use that H(P,P) == false
>>>>>>>> and that P(P) halts.
>>>>>>>
>>>>>>> If H can report on the halting of non-input P(P) then it is not a
>>>>>>> decider because deciders only compute the mapping from inputs to final
>>>>>>> states.
>>>>>> TM deciders compute mappings from inputs to final states /according to
>>>>>> some property of the inputs/
>>>>>
>>>>> That par is exactly correct.
>>>>>
>>>>>> -- whether the input represents, for
>>>>>
>>>>> That part has been the key error of everyone in that they all believe
>>>>> that is can represent something other than what it actually specifies.
>>>>
>>>> So now, after thinking otherwise for years, you claim that there is no
>>>> way to even specify the computation P(P) for you pseudo-C halt decider
>>>> H. At least that is a clear admission that the halting of function
>>>> calls like P(P) can not be decided because, apparently, passing P and P
>>>> to H does not specify that computation, and you can't say what two
>>>> arguments /would/ specify it.
>>>>
>>>> A clear and unambiguous statement that no D such that D(X,Y) == true if
>>>> and only if X(Y) halts and false otherwise is possible would be the
>>>> honest way to move things on. If you were clear about this, maybe
>>>> someone will talk to you about [whatever] it is that your H is
>>>> deciding.
>> So you won't admit that no algorithm can do what D is specified to do?
>> You are just going to pretend that no one cares about actual halting.
>> I hope you see that by ignoring this point you are confirming that you
>> know D can't exist. If you thought such a D was possible, you'd be
>> shouting that from the roof tops since it's what everyone else says is
>> impossible.
>>
>>> I adapted my system so that I could empirically test this:
>>> H1(P,P)==true is empirically proven to be correct
>>> H(P,P)==false is empirically proven to be correct
>>
>> But neither can tell us squat about the halting of P(P) -- the thing
>> that H was originally supposed to decide.
>
> Are you simply wired to ignore my words so that you can disagree with
> everything that I say?
>
> H1(P,P)==true reports on the behavior of P(P).
I try to ignore that bits that are irrelevant. These two deciders
decide all halting instances between them:
bool H1(X, Y) { return true; }
bool H2(X, Y) { return false; }
Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
>>> Both deciders correctly report on the actual behavior of their actual
>>> input. This can be verified by carefully studying their execution
>>> trace.
>> But neither can tell us what we want.
>
> H1(P,P)==true reports on the behavior of P(P).
So what? That some functions gets the right answer for P is irrelevant.
H1 is just as wrong about it's "P" as H is. You know all this. We went
through it years ago.
Your H does not tell us about H_hat(H_hat), and your new mantra about
what it does tell us about is just an admission that fails to do what
the world correctly claims is impossible.
>> Your H does not meet D's
>> specification, but you are not brave enough to admit that you now know
>> that D can't exist because denying that is what got you started down
>> this rabbit hole 18 years ago.
Still nothing about this. You need to come clean and admit that your
mantra has nothing to do with what other people care about: a D such
that D(X,Y) == true if and only if X(Y) halts and false otherwise.
This is why you are wrong. You have nothing to say anymore about the
function the rest of the world is talking about.
>>> (a) Deciding to get around to start this project took weeks when
>>> dealing with my other issues.
>>
>> You decided to start weeks ago. Then you gave up.
>
> I am dead set on finishing it now.
But not yet. First, pointlessly re-implement an TM interpreter by
cutting and pasting code:
>>> (b) No setting up the tedious syntax of reading a file of text lines
>>> took much longer than usual, I usually cut-and-paste.
>>
>> What? I thought you knew C++ and could write code.
>
> On this tedious syntax details I always cut-and-paste from working
> code. I hate tedious syntax details. Engineering algorithms is what I
> enjoy.
--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-05-04 21:55 -0500 |
| Subject | Re: H(P,P) == false is correct [ verified facts ] |
| Message-ID | <t4vea8$u19$1@dont-email.me> |
| In reply to | #49689 |
On 5/4/2022 9:28 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 5/4/2022 7:59 PM, Ben wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> On 5/4/2022 9:16 AM, Ben wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>
>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> It is clear that the input to H(P,P) specifies infinitely nested
>>>>>>>>>> simulation to H.
>>>>>>>>> What two pointers must be passed to H for H to tell up about the halting
>>>>>>>>> of P(P)? If H can't report on the halting of the computation P(P) it is
>>>>>>>>> not a halt decider, and you have already told use that H(P,P) == false
>>>>>>>>> and that P(P) halts.
>>>>>>>>
>>>>>>>> If H can report on the halting of non-input P(P) then it is not a
>>>>>>>> decider because deciders only compute the mapping from inputs to final
>>>>>>>> states.
>>>>>>> TM deciders compute mappings from inputs to final states /according to
>>>>>>> some property of the inputs/
>>>>>>
>>>>>> That par is exactly correct.
>>>>>>
>>>>>>> -- whether the input represents, for
>>>>>>
>>>>>> That part has been the key error of everyone in that they all believe
>>>>>> that is can represent something other than what it actually specifies.
>>>>>
>>>>> So now, after thinking otherwise for years, you claim that there is no
>>>>> way to even specify the computation P(P) for you pseudo-C halt decider
>>>>> H. At least that is a clear admission that the halting of function
>>>>> calls like P(P) can not be decided because, apparently, passing P and P
>>>>> to H does not specify that computation, and you can't say what two
>>>>> arguments /would/ specify it.
>>>>>
>>>>> A clear and unambiguous statement that no D such that D(X,Y) == true if
>>>>> and only if X(Y) halts and false otherwise is possible would be the
>>>>> honest way to move things on. If you were clear about this, maybe
>>>>> someone will talk to you about [whatever] it is that your H is
>>>>> deciding.
>>> So you won't admit that no algorithm can do what D is specified to do?
>>> You are just going to pretend that no one cares about actual halting.
>>> I hope you see that by ignoring this point you are confirming that you
>>> know D can't exist. If you thought such a D was possible, you'd be
>>> shouting that from the roof tops since it's what everyone else says is
>>> impossible.
>>>
>>>> I adapted my system so that I could empirically test this:
>>>> H1(P,P)==true is empirically proven to be correct
>>>> H(P,P)==false is empirically proven to be correct
>>>
>>> But neither can tell us squat about the halting of P(P) -- the thing
>>> that H was originally supposed to decide.
>>
>> Are you simply wired to ignore my words so that you can disagree with
>> everything that I say?
>>
>> H1(P,P)==true reports on the behavior of P(P).
>
> I try to ignore that bits that are irrelevant. These two deciders
> decide all halting instances between them:
>
> bool H1(X, Y) { return true; }
> bool H2(X, Y) { return false; }
>
> Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
> maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
Both take the machine code of P as input parameters and are provably
correct simulations of this same input yet one correctly determines that
its input halts and the other correctly determines that its input does
not halt. ALL THESE THINGS ARE VERIFIED FACTS !
I know that you can't verify that these are facts yet imagine they are
the facts. In that case I have totally proved that I am correct.
Other people can look at in this in my paper:
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
There is enough material in my first paper to verify that everything in
the first paragraph is a fact for people having sufficient expertise in
the x86 language and good familiarity with the halting problem.
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Dennis Bush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2022-05-04 19:59 -0700 |
| Subject | Re: H(P,P) == false is correct [ verified facts ] |
| Message-ID | <a588de5e-d0ee-4f93-939c-f73931e840ecn@googlegroups.com> |
| In reply to | #49692 |
On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
> On 5/4/2022 9:28 PM, Ben wrote:
> > olcott <polc...@gmail.com> writes:
> >
> >> On 5/4/2022 7:59 PM, Ben wrote:
> >>> olcott <polc...@gmail.com> writes:
> >>>
> >>>> On 5/4/2022 9:16 AM, Ben wrote:
> >>>>> olcott <polc...@gmail.com> writes:
> >>>>>
> >>>>>> On 5/2/2022 6:10 PM, Ben wrote:
> >>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>
> >>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
> >>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>
> >>>>>>>>>> It is clear that the input to H(P,P) specifies infinitely nested
> >>>>>>>>>> simulation to H.
> >>>>>>>>> What two pointers must be passed to H for H to tell up about the halting
> >>>>>>>>> of P(P)? If H can't report on the halting of the computation P(P) it is
> >>>>>>>>> not a halt decider, and you have already told use that H(P,P) == false
> >>>>>>>>> and that P(P) halts.
> >>>>>>>>
> >>>>>>>> If H can report on the halting of non-input P(P) then it is not a
> >>>>>>>> decider because deciders only compute the mapping from inputs to final
> >>>>>>>> states.
> >>>>>>> TM deciders compute mappings from inputs to final states /according to
> >>>>>>> some property of the inputs/
> >>>>>>
> >>>>>> That par is exactly correct.
> >>>>>>
> >>>>>>> -- whether the input represents, for
> >>>>>>
> >>>>>> That part has been the key error of everyone in that they all believe
> >>>>>> that is can represent something other than what it actually specifies.
> >>>>>
> >>>>> So now, after thinking otherwise for years, you claim that there is no
> >>>>> way to even specify the computation P(P) for you pseudo-C halt decider
> >>>>> H. At least that is a clear admission that the halting of function
> >>>>> calls like P(P) can not be decided because, apparently, passing P and P
> >>>>> to H does not specify that computation, and you can't say what two
> >>>>> arguments /would/ specify it.
> >>>>>
> >>>>> A clear and unambiguous statement that no D such that D(X,Y) == true if
> >>>>> and only if X(Y) halts and false otherwise is possible would be the
> >>>>> honest way to move things on. If you were clear about this, maybe
> >>>>> someone will talk to you about [whatever] it is that your H is
> >>>>> deciding.
> >>> So you won't admit that no algorithm can do what D is specified to do?
> >>> You are just going to pretend that no one cares about actual halting.
> >>> I hope you see that by ignoring this point you are confirming that you
> >>> know D can't exist. If you thought such a D was possible, you'd be
> >>> shouting that from the roof tops since it's what everyone else says is
> >>> impossible.
> >>>
> >>>> I adapted my system so that I could empirically test this:
> >>>> H1(P,P)==true is empirically proven to be correct
> >>>> H(P,P)==false is empirically proven to be correct
> >>>
> >>> But neither can tell us squat about the halting of P(P) -- the thing
> >>> that H was originally supposed to decide.
> >>
> >> Are you simply wired to ignore my words so that you can disagree with
> >> everything that I say?
> >>
> >> H1(P,P)==true reports on the behavior of P(P).
> >
> > I try to ignore that bits that are irrelevant. These two deciders
> > decide all halting instances between them:
> >
> > bool H1(X, Y) { return true; }
> > bool H2(X, Y) { return false; }
> >
> > Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
> > maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
>
> H1(P,P)==true is empirically proven to be correct
> H(P,P)==false is empirically proven to be correct
If that is so then H and H1 don't perform the same mapping. This means that one (or both) do not compute the halting function.
So which one doesn't compute the halting function?
> Both take the machine code of P as input parameters and are provably
> correct simulations of this same input yet one correctly determines that
> its input halts and the other correctly determines that its input does
> not halt. ALL THESE THINGS ARE VERIFIED FACTS !
>
> I know that you can't verify that these are facts yet imagine they are
> the facts. In that case I have totally proved that I am correct.
>
> Other people can look at in this in my paper:
>
> Halting problem undecidability and infinitely nested simulation
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
> There is enough material in my first paper to verify that everything in
> the first paragraph is a fact for people having sufficient expertise in
> the x86 language and good familiarity with the halting problem.
> --
> Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
> Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-05-04 22:09 -0500 |
| Subject | Re: H(P,P) == false is correct [ verified facts ] |
| Message-ID | <t4vf5c$5ts$1@dont-email.me> |
| In reply to | #49693 |
On 5/4/2022 9:59 PM, Dennis Bush wrote:
> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
>> On 5/4/2022 9:28 PM, Ben wrote:
>>> olcott <polc...@gmail.com> writes:
>>>
>>>> On 5/4/2022 7:59 PM, Ben wrote:
>>>>> olcott <polc...@gmail.com> writes:
>>>>>
>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>
>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> It is clear that the input to H(P,P) specifies infinitely nested
>>>>>>>>>>>> simulation to H.
>>>>>>>>>>> What two pointers must be passed to H for H to tell up about the halting
>>>>>>>>>>> of P(P)? If H can't report on the halting of the computation P(P) it is
>>>>>>>>>>> not a halt decider, and you have already told use that H(P,P) == false
>>>>>>>>>>> and that P(P) halts.
>>>>>>>>>>
>>>>>>>>>> If H can report on the halting of non-input P(P) then it is not a
>>>>>>>>>> decider because deciders only compute the mapping from inputs to final
>>>>>>>>>> states.
>>>>>>>>> TM deciders compute mappings from inputs to final states /according to
>>>>>>>>> some property of the inputs/
>>>>>>>>
>>>>>>>> That par is exactly correct.
>>>>>>>>
>>>>>>>>> -- whether the input represents, for
>>>>>>>>
>>>>>>>> That part has been the key error of everyone in that they all believe
>>>>>>>> that is can represent something other than what it actually specifies.
>>>>>>>
>>>>>>> So now, after thinking otherwise for years, you claim that there is no
>>>>>>> way to even specify the computation P(P) for you pseudo-C halt decider
>>>>>>> H. At least that is a clear admission that the halting of function
>>>>>>> calls like P(P) can not be decided because, apparently, passing P and P
>>>>>>> to H does not specify that computation, and you can't say what two
>>>>>>> arguments /would/ specify it.
>>>>>>>
>>>>>>> A clear and unambiguous statement that no D such that D(X,Y) == true if
>>>>>>> and only if X(Y) halts and false otherwise is possible would be the
>>>>>>> honest way to move things on. If you were clear about this, maybe
>>>>>>> someone will talk to you about [whatever] it is that your H is
>>>>>>> deciding.
>>>>> So you won't admit that no algorithm can do what D is specified to do?
>>>>> You are just going to pretend that no one cares about actual halting.
>>>>> I hope you see that by ignoring this point you are confirming that you
>>>>> know D can't exist. If you thought such a D was possible, you'd be
>>>>> shouting that from the roof tops since it's what everyone else says is
>>>>> impossible.
>>>>>
>>>>>> I adapted my system so that I could empirically test this:
>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>
>>>>> But neither can tell us squat about the halting of P(P) -- the thing
>>>>> that H was originally supposed to decide.
>>>>
>>>> Are you simply wired to ignore my words so that you can disagree with
>>>> everything that I say?
>>>>
>>>> H1(P,P)==true reports on the behavior of P(P).
>>>
>>> I try to ignore that bits that are irrelevant. These two deciders
>>> decide all halting instances between them:
>>>
>>> bool H1(X, Y) { return true; }
>>> bool H2(X, Y) { return false; }
>>>
>>> Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
>>> maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
>>
>> H1(P,P)==true is empirically proven to be correct
>> H(P,P)==false is empirically proven to be correct
>
> If that is so then H and H1 don't perform the same mapping. This means that one (or both) do not compute the halting function.
>
> So which one doesn't compute the halting function?
*ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
Both take the machine code of P as input parameters and are provably
correct simulations of this same input yet one correctly determines that
its input halts and the other correctly determines that its input does
not halt.
>> Both take the machine code of P as input parameters and are provably
>> correct simulations of this same input yet one correctly determines that
>> its input halts and the other correctly determines that its input does
>> not halt. ALL THESE THINGS ARE VERIFIED FACTS !
>>
>> I know that you can't verify that these are facts yet imagine they are
>> the facts. In that case I have totally proved that I am correct.
>>
>> Other people can look at in this in my paper:
>>
>> Halting problem undecidability and infinitely nested simulation
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>> There is enough material in my first paper to verify that everything in
>> the first paragraph is a fact for people having sufficient expertise in
>> the x86 language and good familiarity with the halting problem.
>> --
>> Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see." Arthur Schopenhauer
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2022-05-04 21:17 -0600 |
| Subject | Re: H(P,P) == false is correct [ verified facts ] |
| Message-ID | <t4vfkm$7k2$1@dont-email.me> |
| In reply to | #49695 |
On 2022-05-04 21:09, olcott wrote: > On 5/4/2022 9:59 PM, Dennis Bush wrote: >> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote: >>> H1(P,P)==true is empirically proven to be correct >>> H(P,P)==false is empirically proven to be correct >> >> If that is so then H and H1 don't perform the same mapping. This >> means that one (or both) do not compute the halting function. >> >> So which one doesn't compute the halting function? You didn't actually answer this question. > *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS* > Both take the machine code of P as input parameters and are provably > correct simulations of this same input yet one correctly determines that > its input halts and the other correctly determines that its input does > not halt. Please define your use of the term "correct simulation". André -- To email remove 'invalid' & replace 'gm' with well known Google mail service.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-05-04 22:35 -0500 |
| Subject | Re: H(P,P) == false is correct [ verified facts ] |
| Message-ID | <t4vgm2$gqt$1@dont-email.me> |
| In reply to | #49696 |
On 5/4/2022 10:17 PM, André G. Isaak wrote: > On 2022-05-04 21:09, olcott wrote: >> On 5/4/2022 9:59 PM, Dennis Bush wrote: >>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote: > >>>> H1(P,P)==true is empirically proven to be correct >>>> H(P,P)==false is empirically proven to be correct >>> >>> If that is so then H and H1 don't perform the same mapping. This >>> means that one (or both) do not compute the halting function. >>> >>> So which one doesn't compute the halting function? > > You didn't actually answer this question. > >> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS* >> Both take the machine code of P as input parameters and are provably >> correct simulations of this same input yet one correctly determines >> that its input halts and the other correctly determines that its input >> does not halt. > > Please define your use of the term "correct simulation". > > André > > Good question. The behavior of the simulated input exactly matches the correct execution trace of the behavior in a real hardware machine. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2022-05-04 21:38 -0600 |
| Subject | Re: H(P,P) == false is correct [ verified facts ] |
| Message-ID | <t4vgsg$j1h$1@dont-email.me> |
| In reply to | #49698 |
On 2022-05-04 21:35, olcott wrote: > On 5/4/2022 10:17 PM, André G. Isaak wrote: >> On 2022-05-04 21:09, olcott wrote: >>> On 5/4/2022 9:59 PM, Dennis Bush wrote: >>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote: >> >>>>> H1(P,P)==true is empirically proven to be correct >>>>> H(P,P)==false is empirically proven to be correct >>>> >>>> If that is so then H and H1 don't perform the same mapping. This >>>> means that one (or both) do not compute the halting function. >>>> >>>> So which one doesn't compute the halting function? >> >> You didn't actually answer this question. >> >>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS* >>> Both take the machine code of P as input parameters and are provably >>> correct simulations of this same input yet one correctly determines >>> that its input halts and the other correctly determines that its >>> input does not halt. >> >> Please define your use of the term "correct simulation". >> >> André >> >> > > Good question. > The behavior of the simulated input exactly matches the correct > execution trace of the behavior in a real hardware machine. So if P(P), when executed directly, halts, how can a 'correct simulation' possibly not halt? André -- To email remove 'invalid' & replace 'gm' with well known Google mail service.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-05-04 22:42 -0500 |
| Subject | Re: H(P,P) == false is correct [ verified facts ] |
| Message-ID | <t4vh3r$lma$1@dont-email.me> |
| In reply to | #49700 |
On 5/4/2022 10:38 PM, André G. Isaak wrote: > On 2022-05-04 21:35, olcott wrote: >> On 5/4/2022 10:17 PM, André G. Isaak wrote: >>> On 2022-05-04 21:09, olcott wrote: >>>> On 5/4/2022 9:59 PM, Dennis Bush wrote: >>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote: >>> >>>>>> H1(P,P)==true is empirically proven to be correct >>>>>> H(P,P)==false is empirically proven to be correct >>>>> >>>>> If that is so then H and H1 don't perform the same mapping. This >>>>> means that one (or both) do not compute the halting function. >>>>> >>>>> So which one doesn't compute the halting function? >>> >>> You didn't actually answer this question. >>> >>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS* >>>> Both take the machine code of P as input parameters and are provably >>>> correct simulations of this same input yet one correctly determines >>>> that its input halts and the other correctly determines that its >>>> input does not halt. >>> >>> Please define your use of the term "correct simulation". >>> >>> André >>> >>> >> >> Good question. >> The behavior of the simulated input exactly matches the correct >> execution trace of the behavior in a real hardware machine. > > So if P(P), when executed directly, halts, how can a 'correct > simulation' possibly not halt? > > André > As soon as you very carefully study every single detail of the above paragraph you will realize that it proves that I am correct as soon as the paragraph itself is proved to be factually correct. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Dennis Bush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2022-05-04 20:50 -0700 |
| Subject | Re: H(P,P) == false is correct [ verified facts ] |
| Message-ID | <99f51bdb-4585-410a-969e-2bb81c1065aan@googlegroups.com> |
| In reply to | #49701 |
On Wednesday, May 4, 2022 at 11:42:53 PM UTC-4, olcott wrote: > On 5/4/2022 10:38 PM, André G. Isaak wrote: > > On 2022-05-04 21:35, olcott wrote: > >> On 5/4/2022 10:17 PM, André G. Isaak wrote: > >>> On 2022-05-04 21:09, olcott wrote: > >>>> On 5/4/2022 9:59 PM, Dennis Bush wrote: > >>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote: > >>> > >>>>>> H1(P,P)==true is empirically proven to be correct > >>>>>> H(P,P)==false is empirically proven to be correct > >>>>> > >>>>> If that is so then H and H1 don't perform the same mapping. This > >>>>> means that one (or both) do not compute the halting function. > >>>>> > >>>>> So which one doesn't compute the halting function? > >>> > >>> You didn't actually answer this question. > >>> > >>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS* > >>>> Both take the machine code of P as input parameters and are provably > >>>> correct simulations of this same input yet one correctly determines > >>>> that its input halts and the other correctly determines that its > >>>> input does not halt. > >>> > >>> Please define your use of the term "correct simulation". > >>> > >>> André > >>> > >>> > >> > >> Good question. > >> The behavior of the simulated input exactly matches the correct > >> execution trace of the behavior in a real hardware machine. > > > > So if P(P), when executed directly, halts, how can a 'correct > > simulation' possibly not halt? > > > > André > > > As soon as you very carefully study every single detail of the above > paragraph you will realize that it proves that I am correct as soon as > the paragraph itself is proved to be factually correct. Would you then also agree that Ha3(N,5) == false and Ha7(N,5) == true are both correct because both perform a provably correct simulation their input, so that Ha3 correctly determines that its input does not halt while Ha7 correctly determines that its input halts? If not, then clarify your correctness criteria so that it can apply to *any* input and *any* decider such that it shows that Ha3(N,5) does not perform a correct simulation but H(P,P) does.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-05-04 22:58 -0500 |
| Subject | Re: H(P,P) == false is correct [ verified facts ] |
| Message-ID | <t4vi1o$qn6$1@dont-email.me> |
| In reply to | #49703 |
On 5/4/2022 10:50 PM, Dennis Bush wrote: > On Wednesday, May 4, 2022 at 11:42:53 PM UTC-4, olcott wrote: >> On 5/4/2022 10:38 PM, André G. Isaak wrote: >>> On 2022-05-04 21:35, olcott wrote: >>>> On 5/4/2022 10:17 PM, André G. Isaak wrote: >>>>> On 2022-05-04 21:09, olcott wrote: >>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote: >>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote: >>>>> >>>>>>>> H1(P,P)==true is empirically proven to be correct >>>>>>>> H(P,P)==false is empirically proven to be correct >>>>>>> >>>>>>> If that is so then H and H1 don't perform the same mapping. This >>>>>>> means that one (or both) do not compute the halting function. >>>>>>> >>>>>>> So which one doesn't compute the halting function? >>>>> >>>>> You didn't actually answer this question. >>>>> >>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS* >>>>>> Both take the machine code of P as input parameters and are provably >>>>>> correct simulations of this same input yet one correctly determines >>>>>> that its input halts and the other correctly determines that its >>>>>> input does not halt. >>>>> >>>>> Please define your use of the term "correct simulation". >>>>> >>>>> André >>>>> >>>>> >>>> >>>> Good question. >>>> The behavior of the simulated input exactly matches the correct >>>> execution trace of the behavior in a real hardware machine. >>> >>> So if P(P), when executed directly, halts, how can a 'correct >>> simulation' possibly not halt? >>> >>> André >>> >> As soon as you very carefully study every single detail of the above >> paragraph you will realize that it proves that I am correct as soon as >> the paragraph itself is proved to be factually correct. > > Would you then also agree that Ha3(N,5) == false and Ha7(N,5) == true are both correct because both perform a provably correct simulation their input, so that Ha3 correctly determines that its input does not halt while Ha7 correctly determines that its input halts? > > If not, then clarify your correctness criteria so that it can apply to *any* input and *any* decider such that it shows that Ha3(N,5) does not perform a correct simulation but H(P,P) does. I am not going to go through any of your extraneous nonsense. *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS* Both take the machine code of P as input parameters and are provably correct simulations of this same input yet one correctly determines that its input halts and the other correctly determines that its input does not halt. If the above paragraph is proven to be a fact then this proves that both H and H1 compute the halting function correctly. Try to point to any gaps in this reasoning. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | comp.theory
csiph-web