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 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-05-06 11:33 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t53il0$47f$1@dont-email.me> |
| In reply to | #49836 |
On 5/6/2022 6:36 AM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 5/5/2022 9:35 PM, Ben wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> On 5/5/2022 8:29 AM, Ben wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>
>>>>>> 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 !
>>>>>
>>>>> Your mantra is doing sterling work, allowing you to pretend you are
>>>>> taking about the halting problem while hiding what it is that your
>>>>> deciders are deciding. Whatever you are hiding behind the words
>>>>> "correct simulations of this same input" it is obviously not the halting
>>>>> of P(P).
>>>>
>>>> You seem to have a short-circuit in your brain, I have told you this
>>>> many times and you have not seen it once.
>>>>
>>>> H1(P,P) IS THE HALT STATUS OF P(P)
>>> So what? Everyone know that there are an infinity of functions that are
>>> correct about the halting of P(P). It's H that's wrong, not H1.
>>> The only interesting thing about H1 is that you say it does that same as
>>> H but gets a different answer. Now that's a rabbit hole that other
>>> people might follow you down, but I don't care. You are wrong about too
>>> many things to be bothered about all of them.
>>> The important point is that your H is wrong because H(P,P) == false even
>>> though P(P) halts.
>>>
>>>>> For one thing, there is only one correct answer to the halting
>>>>> or otherwise of a computation, and for another, H(X,Y) is obviously not
>>>>> telling the world what it wants to know -- the halting of the
>>>>> computation X(Y).
>>>>
>>>> Since you know that a decider (halting or otherwise) only computes the
>>>> mapping from its inputs and that you insist that a halt decider
>>>> compute its mapping from non inputs it is either psychosis or
>>>> deception on your part.
>>> Remember all those other times you thought I was mad? Remember the last
>>> time? It was because you didn't know what a sequence was.
>>> Hint: every time you think I am lying or playing games or psychotic it's
>>> because your conviction that you can't be wrong has butted up against
>>> cold facts. You know, at some level of consciousness, that a C-like
>>> halt decider, bool D(ptr X, ptr Y);, returns true or false based on the
>>> halting of X(Y) as here:
>>>
>>>>> Do you have anything at all left to say about the real halting problem?
>>>>> I really think you should at least state, explicitly, that you now
>>>>> accept that no function D exists such that D(X,Y) == true if an only if
>>>>> X(Y) halts and false otherwise.
>>> We could make progress if you would accept that no such D can exist for
>>> whatever reason you choose to give -- even it's because you think X(Y)
>>> is a "non-input". But then there's no reason to think you will make
>>> such a clear statement.
>>>
>>>> H1(P,P)==true is empirically proven to be correct
>>>> H(P,P)==false is empirically proven to be correct
>>>>
>>>> That you keep contradicting verified facts that you already accept as
>>>> true seems quite nuts.
>>> H1 is irrelevant, and H is wrong by definition. Whatever H has been
>>> "empirically proven to be correct" about you are clear that it's not
>>> correct about the halting of P(P).
>>>
>>>> Halt deciders (like all deciders) compute the
>>>> mapping from their inputs.
>>> ... to specified true/false properties of those inputs. In the case of
>>> H, we want it to report on the halting or otherwise of its first
>>> argument when called with the second argument. Your H fails at that.
>>>
>>>> It turns out that the halting behavior of the correct simulation of
>>>> the input to H1(P,P) is the same as the halting behavior of P(P).
>>> And that is true of an infinity of equally irrelevant functions.
>>>
>>>> It turns out that the halting behavior of the correct simulation of
>>>> the input to H(P,P) is NOT the same as the halting behavior of P(P).
>>> Which is why H does not meet the specification of being a halt decider.
>>>
>>>> The ultimate measure is that H(P,P) does compute the mapping from its
>>>> inputs to its final reject state. This can be easily verified by
>>>> anyone with sufficient expertise in the x86 language.
>>> Yes, H just wrong to reject (P,P) because of how the halting problem is
>>> defined. No one disputes the fact that H(P,P) == false even though P(P)
>>> halts. The /only/ fact is dispute is the specification that H should
>>> meet.
>>>
>>>> I made good progress on Simplest TM interpreter yesterday. The
>>>> detailed design is halfway done. The trickiest part is the state
>>>> change function. I think that I am going to use a std::set that is
>>>> indexed on state + input.
>>>>
>>>> struct Quintuple
>>>> {
>>>> u32 state;
>>>> u32 symbol;
>>>> u32 write_symbol;
>>>> u32 next_state;
>>>> u8 Tape_Head_Move;
>>>> }
>>>>
>>>> std::set<Quintuple> States;
>>> Why is a set of objects that are not states called "States"?
>>
>> They are states, what did you think that states are?
>
> Not quintuples. There are lots of ways to represent a TM's states, but
> states are not quintuples and quintuples are not states. This confusion
> will (as you can see below) make lots of the code read badly.
>
What did you think that states are?
Do you think that they are raw integers?
>> This is the first draft of my transition_function() its seems to exactly match this design on the first page of the docs.
>> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
>>
>> I am writing this in Open Office Writer not any compiler.
>> I don't even know that it compiles.
>>
>> This is going to be a member function.
>> bool transition_function(std::set<Quintuple>::iterator& current_state)
>
> There's no point in putting the quintuples into a std::set. And the
> parameter current_state is badly worded as it refers to a particular
> rule (quintuple) and not to a state.
>
It is simpler than a linear or binary search scan through the whole list
every-time we need to make a transition from the current_state to the
(next_state + current_Input).
> The main role of a state in a TM implementation is to collect together
> all the rules (quintuples) that apply in that date. You could do a lot
> worse than follow that as a key organisational principle.
A linear list of quintuples is specified in the filename.TM
TAPE_DATA // on a line by itself followed by
A linear list of ASCII text chars or hexadecimal bytes.
The tape has been initialized as a std::vector<u8> Tape;
We could have a Move_R past the end of the tape allocate more memory.
A move left prior to the beginning of the tape might be reported as an
error.
int Tape_Head = 0; // not a global
std::set<Quintuple>::iterator
NextState(int next_state, int current_input)
{
Quintuple QT(next_state, current_input);
return States.find(QT);
};
The above returns an iterator to state indexed by (state + symbol).
bool Transition_to_State_0(std::set<Quintuple>::iterator& current_state)
{
it = NextState(0, Tape[Tape_Head]);
if (it == States.end())
return false;
current_state = it;
return true;
}
>> {
>> u32 next_state = current_state->next_state;
>
> States, as you make clear here are just unsigned integers (in your
> implementation).
>
OK then I will use Quintuple_List as my designer implemented.
>> u32 current_input = Tape[Tape_Head];
>
> Why reference the tape here? If Tape[Tape_Head] != current_state.symbol
> then something has gone very wrong already. Note how confusing my
> writing the condition is since current_state.symbol should not make
> sense.
Although after successful find current_state->symbol would have the same
value as Tape[Tape_Head] it is more clear that we are referring to the
current input with the latter.
> (By all means reference the tape to put in a run-time assertion that
> tape.head() == current_rule.symbol or some such but there's no need to
> get the symbol from the tape as you will already have done this in order
> to pass the right quintuple to this function.)
>
My way is clearer.
>> std::set<Quintuple>::iterator it;
>>
>> Tape[Tape_Head] = current_state->write_symbol;
>
> current_state.write_symbol
>
> But if the parameter were correctly named it would make more sense:
>
> Tape[Tape_Head] = current_rule.write_symbol
>
>> if (toupper(current_state->tape_head_move) == “L”;
>> Tape_Head--; // Left
>> else
>> Tape_Head++; // Right
>
> Since the tape has a very limited number of operations, I'd abstract it
> out into a class with a move member function (or a left and a right
> function).
>
I think that it is more clear the way it is.
>> it = NextState(current_input, next_state);
>
> The next state should be right here in the current_rule (badly named
> current_state). At least that would be the obvious way to implement
> this. Maybe the bad name is leading you astray?
Since the current state must refer to every element of its related
Quintuple and current_state is actually current_state + current_input,
this a single integer does not uniquely identify a Quintuple it seems to
make the most sense to call each Quintuple a state.
It may be more conventional to have a two layered system where an
integer indexes into a list of states each one having a list of inputs
that they respond to. The ads extraneous complexity.
I could call current_state current_quintuple.
>
>> if (it == States.end())
>> return false;
>> current_state = it;
>> return true;
>> }
>
> I don't think you have the key parts properly structured yet. I'd back
> up a bit and map out the very top-level loop.
bool transition_function(std::set<Quintuple>::iterator& current_state)
{
u32 next_state = current_state->next_state;
u32 current_input = Tape[Tape_Head];
std::set<Quintuple>::iterator it;
Tape[Tape_Head] = current_state->write_symbol;
if (toupper(current_state->tape_head_move) == “L”;
Tape_Head--; // Left
else
Tape_Head++; // Right
it = NextState(next_state, current_input);
if (it == States.end())
return false;
current_state = it;
return true;
}
The top level loop initializes
int Tape_Head = 0;
std::set<Quintuple>::iterator current_state;
if (!Transition_to_State_0(current_state))
return false;
The top level loop then simply executes transition_function() until false.
while (transition_function(current_state) == true)
;
> That will point you to
> what objects you need and what methods those objects should provide.
>
The key part that I have mapped out the transition_function and the TM
file format. The transition_function is the core of the TM execution
engine.
You didn't point out any actual errors, you simply critiqued my design
aesthetics.
--
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-07 02:57 +0100 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <87levexfxz.fsf@bsb.me.uk> |
| In reply to | #49852 |
olcott <polcott2@gmail.com> writes:
> On 5/6/2022 6:36 AM, Ben wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> On 5/5/2022 9:35 PM, Ben wrote:
>>>> olcott <polcott2@gmail.com> writes:
>>>>> struct Quintuple
>>>>> {
>>>>> u32 state;
>>>>> u32 symbol;
>>>>> u32 write_symbol;
>>>>> u32 next_state;
>>>>> u8 Tape_Head_Move;
>>>>> }
>>>>>
>>>>> std::set<Quintuple> States;
>>>> Why is a set of objects that are not states called "States"?
>>>
>>> They are states, what did you think that states are?
>> Not quintuples. There are lots of ways to represent a TM's states, but
>> states are not quintuples and quintuples are not states. This confusion
>> will (as you can see below) make lots of the code read badly.
>
> What did you think that states are?
Their only properties are that they are distinct and finite in number.
I have written an interpreter in which the states are instances of a
class State, that holds all the information a TM might need when in that
state. But there are a hundreds of other ways to represent the states.
> Do you think that they are raw integers?
No, that's not what they are, though you could use integers to represent
them. You could also use characters, strings and pointers to state
objects.
A key consideration, though, is that you might want to print information
about the states to help the user of the interpreter so the states
should be identifiable in some what that matches the way the user writes
the TM. So I tend to favour labelling the sates with strings so that
messages can report things like:
In state 'open_(_seen': no transition for symbol '+'.
If you are matching the input scheme for the implementation you posted a
link to, then you should be able to report the state's name as the
character the user will have entered.
>>> This is the first draft of my transition_function() its seems to exactly match this design on the first page of the docs.
>>> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
>>>
>>> I am writing this in Open Office Writer not any compiler.
>>> I don't even know that it compiles.
>>>
>>> This is going to be a member function.
>>> bool transition_function(std::set<Quintuple>::iterator& current_state)
>>
>> There's no point in putting the quintuples into a std::set. And the
>> parameter current_state is badly worded as it refers to a particular
>> rule (quintuple) and not to a state.
>
> It is simpler than a linear or binary search scan through the whole
> list every-time we need to make a transition from the current_state to
> the (next_state + current_Input).
Of course, but a set is not, in my opinion, the natural container for
quintuples. Do you even know how to make it work in your case? It
would involve what I would consider a bit of trickery.
> std::set<Quintuple>::iterator
> NextState(int next_state, int current_input)
> {
> Quintuple QT(next_state, current_input);
> return States.find(QT);
> };
>
> The above returns an iterator to state indexed by (state + symbol).
It returns an iterator to a quintuple, not a state, so the name is bad.
And why does the function take things called 'next_state' and
'current_input'? The next quintuple is determined by the current state
and the current input.
> bool Transition_to_State_0(std::set<Quintuple>::iterator& current_state)
> {
> it = NextState(0, Tape[Tape_Head]);
> if (it == States.end())
> return false;
> current_state = it;
> return true;
> }
This looks all messed up but mainly because I don't think you are using
the right names.
And it's still a very loose sketch. Setting current_state is
essentially pointless.
>>> {
>>> u32 next_state = current_state->next_state;
>> States, as you make clear here are just unsigned integers (in your
>> implementation).
>>
>
> OK then I will use Quintuple_List as my designer implemented.
>
>>> u32 current_input = Tape[Tape_Head];
>> Why reference the tape here? If Tape[Tape_Head] != current_state.symbol
>> then something has gone very wrong already. Note how confusing my
>> writing the condition is since current_state.symbol should not make
>> sense.
>
> Although after successful find current_state->symbol would have the
> same value as Tape[Tape_Head] it is more clear that we are referring
> to the current input with the latter.
>
>> (By all means reference the tape to put in a run-time assertion that
>> tape.head() == current_rule.symbol or some such but there's no need to
>> get the symbol from the tape as you will already have done this in order
>> to pass the right quintuple to this function.)
>
> My way is clearer.
I think the best way to judge that will be to compare code. At the
moment you only have a very rough sketch.
>>> std::set<Quintuple>::iterator it;
>>>
>>> Tape[Tape_Head] = current_state->write_symbol;
>> current_state.write_symbol
>> But if the parameter were correctly named it would make more sense:
>> Tape[Tape_Head] = current_rule.write_symbol
>>
>>> if (toupper(current_state->tape_head_move) == “L”;
>>> Tape_Head--; // Left
>>> else
>>> Tape_Head++; // Right
>> Since the tape has a very limited number of operations, I'd abstract it
>> out into a class with a move member function (or a left and a right
>> function).
>
> I think that it is more clear the way it is.
Let's see how it turns out in the end.
> Since the current state must refer to every element of its related
> Quintuple and current_state is actually current_state + current_input,
> this a single integer does not uniquely identify a Quintuple it seems
> to make the most sense to call each Quintuple a state.
>
> It may be more conventional to have a two layered system where an
> integer indexes into a list of states each one having a list of inputs
> that they respond to. The ads extraneous complexity.
>
> I could call current_state current_quintuple.
I think a lot of the problems a down to your uses state when you mean
quintuple. NextState seems all wrong, but maybe it makes more sense if
it does not find the next state but the next quintuple.
> bool transition_function(std::set<Quintuple>::iterator& current_state)
> {
> u32 next_state = current_state->next_state;
> u32 current_input = Tape[Tape_Head];
> std::set<Quintuple>::iterator it;
>
> Tape[Tape_Head] = current_state->write_symbol;
> if (toupper(current_state->tape_head_move) == “L”;
> Tape_Head--; // Left
> else
> Tape_Head++; // Right
>
> it = NextState(next_state, current_input);
> if (it == States.end())
> return false;
> current_state = it;
> return true;
> }
With proper renaming this sketch makes a bit more sense. You take a
current rule (I am getting tired typing quintuple) and NextState really
finds the next rule, not state.
But the details are still all wrong. NextRule (as I'd call it) needs to
use next_state and the new current_input, not the input you find at the
top of the function. And setting current_state (which should be called
current_rule) is pointless since it's about to be thrown away.
> You didn't point out any actual errors, you simply critiqued my design
> aesthetics.
You take my remarks how you like. When you show this code to a
compiler, you'll see more problems.
--
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-06 21:22 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t54l5g$tm5$1@dont-email.me> |
| In reply to | #49922 |
On 5/6/2022 8:57 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 5/6/2022 6:36 AM, Ben wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> On 5/5/2022 9:35 PM, Ben wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>
>>>>>> struct Quintuple
>>>>>> {
>>>>>> u32 state;
>>>>>> u32 symbol;
>>>>>> u32 write_symbol;
>>>>>> u32 next_state;
>>>>>> u8 Tape_Head_Move;
>>>>>> }
>>>>>>
>>>>>> std::set<Quintuple> States;
>>>>> Why is a set of objects that are not states called "States"?
>>>>
>>>> They are states, what did you think that states are?
>
>>> Not quintuples. There are lots of ways to represent a TM's states, but
>>> states are not quintuples and quintuples are not states. This confusion
>>> will (as you can see below) make lots of the code read badly.
>>
>> What did you think that states are?
>
> Their only properties are that they are distinct and finite in number.
Ah so you are only seeing the mathematical abstraction that uses
directed graphs. That is not enough for an actual hardware machine to go
on.
> I have written an interpreter in which the states are instances of a
> class State, that holds all the information a TM might need when in that
> state. But there are a hundreds of other ways to represent the states.
>
In other words this:
struct Quintuple
{
int state;
int symbol;
int write_symbol;
int next_state;
char tape_head_move;
};
>> Do you think that they are raw integers?
>
> No, that's not what they are, though you could use integers to represent
> them. You could also use characters, strings and pointers to state
> objects.
>
> A key consideration, though, is that you might want to print information
> about the states to help the user of the interpreter so the states
> should be identifiable in some what that matches the way the user writes
> the TM. So I tend to favour labelling the sates with strings so that
> messages can report things like:
>
I am going to make it compatible with the TM interpreter files and I
will always output the full execution trace. I am aiming for a three
minute learning curve for everyone that knows TM's very well.
> In state 'open_(_seen': no transition for symbol '+'.
>
> If you are matching the input scheme for the implementation you posted a
> link to, then you should be able to report the state's name as the
> character the user will have entered.
>
full execution trace.
>>>> This is the first draft of my transition_function() its seems to exactly match this design on the first page of the docs.
>>>> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
>>>>
>>>> I am writing this in Open Office Writer not any compiler.
>>>> I don't even know that it compiles.
>>>>
>>>> This is going to be a member function.
>>>> bool transition_function(std::set<Quintuple>::iterator& current_state)
>>>
>>> There's no point in putting the quintuples into a std::set. And the
>>> parameter current_state is badly worded as it refers to a particular
>>> rule (quintuple) and not to a state.
>>
>> It is simpler than a linear or binary search scan through the whole
>> list every-time we need to make a transition from the current_state to
>> the (next_state + current_Input).
>
> Of course, but a set is not, in my opinion, the natural container for
> quintuples. Do you even know how to make it work in your case? It
> would involve what I would consider a bit of trickery.
>
>> std::set<Quintuple>::iterator
>> NextState(int next_state, int current_input)
>> {
>> Quintuple QT(next_state, current_input);
>> return States.find(QT);
>> };
>>
>> The above returns an iterator to state indexed by (state + symbol).
>
> It returns an iterator to a quintuple, not a state, so the name is bad.
> And why does the function take things called 'next_state' and
> 'current_input'? The next quintuple is determined by the current state
> and the current input.
It is specified by the TM interpreter specs.
For example, the quintuple 'SCcsm' is executed by the machine:
If it is in state 'S' and is reading the symbol 'C' on the tape then
(a) make a transition to state 's'.
(b) overwrite the symbol 'C' on the tape with the symbol 'c'.
// Must do this before transition to state 's' or we lose 'c' from S.
(c) move the tape reading head one symbol to the left or right
according to whether 'm' is 'l' or 'r'.
http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
>> bool Transition_to_State_0(std::set<Quintuple>::iterator& current_state)
>> {
>> it = NextState(0, Tape[Tape_Head]);
>> if (it == States.end())
>> return false;
>> current_state = it;
>> return true;
>> }
>
> This looks all messed up but mainly because I don't think you are using
> the right names.
>
> And it's still a very loose sketch. Setting current_state is
> essentially pointless.
>
It performs ALL of the steps of transitioning to the start state.
>>>> {
>>>> u32 next_state = current_state->next_state;
>>> States, as you make clear here are just unsigned integers (in your
>>> implementation).
>>>
>>
>> OK then I will use Quintuple_List as my designer implemented.
>>
>>>> u32 current_input = Tape[Tape_Head];
>>> Why reference the tape here? If Tape[Tape_Head] != current_state.symbol
>>> then something has gone very wrong already. Note how confusing my
>>> writing the condition is since current_state.symbol should not make
>>> sense.
>>
>> Although after successful find current_state->symbol would have the
>> same value as Tape[Tape_Head] it is more clear that we are referring
>> to the current input with the latter.
>>
>>> (By all means reference the tape to put in a run-time assertion that
>>> tape.head() == current_rule.symbol or some such but there's no need to
>>> get the symbol from the tape as you will already have done this in order
>>> to pass the right quintuple to this function.)
>>
>> My way is clearer.
>
> I think the best way to judge that will be to compare code. At the
> moment you only have a very rough sketch.
The "rough sketch" is fully operational code.
I am adding parse capability.
>>>> std::set<Quintuple>::iterator it;
>>>>
>>>> Tape[Tape_Head] = current_state->write_symbol;
>>> current_state.write_symbol
>>> But if the parameter were correctly named it would make more sense:
>>> Tape[Tape_Head] = current_rule.write_symbol
>>>
>>>> if (toupper(current_state->tape_head_move) == “L”;
>>>> Tape_Head--; // Left
>>>> else
>>>> Tape_Head++; // Right
>>> Since the tape has a very limited number of operations, I'd abstract it
>>> out into a class with a move member function (or a left and a right
>>> function).
>>
>> I think that it is more clear the way it is.
>
> Let's see how it turns out in the end.
>
>> Since the current state must refer to every element of its related
>> Quintuple and current_state is actually current_state + current_input,
>> this a single integer does not uniquely identify a Quintuple it seems
>> to make the most sense to call each Quintuple a state.
>>
>> It may be more conventional to have a two layered system where an
>> integer indexes into a list of states each one having a list of inputs
>> that they respond to. The ads extraneous complexity.
>>
>> I could call current_state current_quintuple.
>
> I think a lot of the problems a down to your uses state when you mean
> quintuple. NextState seems all wrong, but maybe it makes more sense if
> it does not find the next state but the next quintuple.
>
NextState does this:
(a) make a transition to state 's'.
>> bool transition_function(std::set<Quintuple>::iterator& current_state)
>> {
>> u32 next_state = current_state->next_state;
>> u32 current_input = Tape[Tape_Head];
>> std::set<Quintuple>::iterator it;
>>
>> Tape[Tape_Head] = current_state->write_symbol;
>> if (toupper(current_state->tape_head_move) == “L”;
>> Tape_Head--; // Left
>> else
>> Tape_Head++; // Right
>>
>> it = NextState(next_state, current_input);
>> if (it == States.end())
>> return false;
>> current_state = it;
>> return true;
>> }
>
> With proper renaming this sketch makes a bit more sense. You take a
> current rule (I am getting tired typing quintuple) and NextState really
> finds the next rule, not state.
>
I will work out best naming later on after the code works.
> But the details are still all wrong. NextRule (as I'd call it) needs to
> use next_state and the new current_input, not the input you find at the
> top of the function. And setting current_state (which should be called
> current_rule) is pointless since it's about to be thrown away.
>
That is the part that is ambiguous in the spec.
Do you know a source that confirms that next_state is a function of
current_state and next_input?
>> You didn't point out any actual errors, you simply critiqued my design
>> aesthetics.
>
> You take my remarks how you like. When you show this code to a
> compiler, you'll see more problems.
>
It already compiles.
--
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-08 00:01 +0100 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <87ee15vtfn.fsf@bsb.me.uk> |
| In reply to | #49924 |
olcott <polcott2@gmail.com> writes:
> On 5/6/2022 8:57 PM, Ben wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> On 5/6/2022 6:36 AM, Ben wrote:
>>>> olcott <polcott2@gmail.com> writes:
>>>>
>>>>> On 5/5/2022 9:35 PM, Ben wrote:
>>>>>> olcott <polcott2@gmail.com> writes:
>>
>>>>>>> struct Quintuple
>>>>>>> {
>>>>>>> u32 state;
>>>>>>> u32 symbol;
>>>>>>> u32 write_symbol;
>>>>>>> u32 next_state;
>>>>>>> u8 Tape_Head_Move;
>>>>>>> }
>>>>>>>
>>>>>>> std::set<Quintuple> States;
>>>>>> Why is a set of objects that are not states called "States"?
>>>>>
>>>>> They are states, what did you think that states are?
>>
>>>> Not quintuples. There are lots of ways to represent a TM's states, but
>>>> states are not quintuples and quintuples are not states. This confusion
>>>> will (as you can see below) make lots of the code read badly.
>>>
>>> What did you think that states are?
>> Their only properties are that they are distinct and finite in number.
>
> Ah so you are only seeing the mathematical abstraction that uses
> directed graphs. That is not enough for an actual hardware machine to
> go on.
Nonsense. It's perfectly practical and entirely natiral to implement
this using a directed graph.
>> I have written an interpreter in which the states are instances of a
>> class State, that holds all the information a TM might need when in that
>> state. But there are a hundreds of other ways to represent the states.
>
> In other words this:
> struct Quintuple
> {
> int state;
> int symbol;
> int write_symbol;
> int next_state;
> char tape_head_move;
> };
This is not a state. States are not quintuples and vice-versa. Please
don't pick this hill fight on.
>>> bool Transition_to_State_0(std::set<Quintuple>::iterator& current_state)
>>> {
>>> it = NextState(0, Tape[Tape_Head]);
>>> if (it == States.end())
>>> return false;
>>> current_state = it;
>>> return true;
>>> }
>> This looks all messed up but mainly because I don't think you are using
>> the right names.
>> And it's still a very loose sketch. Setting current_state is
>> essentially pointless.
>
> It performs ALL of the steps of transitioning to the start state.
Nope. I really don't like arguing about programming because the hard
test is will it work. This won't, and you'll find out when you run your
first tests.
>>> My way is clearer.
>> I think the best way to judge that will be to compare code. At the
>> moment you only have a very rough sketch.
>
> The "rough sketch" is fully operational code.
That's very revealing. You've claimed to have other "fully operational
code" and since these sketches are clearly not operational, you must be
using the phrase in some rather loose way.
--
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 <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-07 18:45 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <57Odnbwd0o8xmer_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #49982 |
On 5/7/2022 6:01 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 5/6/2022 8:57 PM, Ben wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> On 5/6/2022 6:36 AM, Ben wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>> On 5/5/2022 9:35 PM, Ben wrote:
>>>>>>> olcott <polcott2@gmail.com> writes:
>>>
>>>>>>>> struct Quintuple
>>>>>>>> {
>>>>>>>> u32 state;
>>>>>>>> u32 symbol;
>>>>>>>> u32 write_symbol;
>>>>>>>> u32 next_state;
>>>>>>>> u8 Tape_Head_Move;
>>>>>>>> }
>>>>>>>>
>>>>>>>> std::set<Quintuple> States;
>>>>>>> Why is a set of objects that are not states called "States"?
>>>>>>
>>>>>> They are states, what did you think that states are?
>>>
>>>>> Not quintuples. There are lots of ways to represent a TM's states, but
>>>>> states are not quintuples and quintuples are not states. This confusion
>>>>> will (as you can see below) make lots of the code read badly.
>>>>
>>>> What did you think that states are?
>>> Their only properties are that they are distinct and finite in number.
>>
>> Ah so you are only seeing the mathematical abstraction that uses
>> directed graphs. That is not enough for an actual hardware machine to
>> go on.
>
> Nonsense. It's perfectly practical and entirely natiral to implement
> this using a directed graph.
>
A directed graph with labeled edges would seem to require all this (node
and edge) info kept in a single struct when physically implemented as
software. One node could have a list of edge data, yet that is cumbersome.
>>> I have written an interpreter in which the states are instances of a
>>> class State, that holds all the information a TM might need when in that
>>> state. But there are a hundreds of other ways to represent the states.
>>
>> In other words this:
>> struct Quintuple
>> {
>> int state;
>> int symbol;
>> int write_symbol;
>> int next_state;
>> char tape_head_move;
>> };
>
> This is not a state. States are not quintuples and vice-versa. Please
> don't pick this hill fight on.
I want to grok this.
>
>>>> bool Transition_to_State_0(std::set<Quintuple>::iterator& current_state)
>>>> {
>>>> it = NextState(0, Tape[Tape_Head]);
>>>> if (it == States.end())
>>>> return false;
>>>> current_state = it;
>>>> return true;
>>>> }
>>> This looks all messed up but mainly because I don't think you are using
>>> the right names.
>>> And it's still a very loose sketch. Setting current_state is
>>> essentially pointless.
>>
>> It performs ALL of the steps of transitioning to the start state.
>
> Nope. I really don't like arguing about programming because the hard
> test is will it work. This won't, and you'll find out when you run your
> first tests.
>
>>>> My way is clearer.
>>> I think the best way to judge that will be to compare code. At the
>>> moment you only have a very rough sketch.
>>
>> The "rough sketch" is fully operational code.
>
More accurately the The "rough sketch" is my best estimate of is fully
operational code.
> That's very revealing. You've claimed to have other "fully operational
> code" and since these sketches are clearly not operational, you must be
> using the phrase in some rather loose way.
>
I was trying to make it clear that it is not a more sketch with many
missing pieces. All the pieces are there.
--
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-08 00:59 +0100 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <8735hkx5al.fsf@bsb.me.uk> |
| In reply to | #49987 |
olcott <NoOne@NoWhere.com> writes:
> On 5/7/2022 6:01 PM, Ben wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> On 5/6/2022 8:57 PM, Ben wrote:
>>>> olcott <polcott2@gmail.com> writes:
>>>>
>>>>> On 5/6/2022 6:36 AM, Ben wrote:
>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>
>>>>>>> On 5/5/2022 9:35 PM, Ben wrote:
>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>
>>>>>>>>> struct Quintuple
>>>>>>>>> {
>>>>>>>>> u32 state;
>>>>>>>>> u32 symbol;
>>>>>>>>> u32 write_symbol;
>>>>>>>>> u32 next_state;
>>>>>>>>> u8 Tape_Head_Move;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> std::set<Quintuple> States;
>>>>>>>> Why is a set of objects that are not states called "States"?
>>>>>>>
>>>>>>> They are states, what did you think that states are?
>>>>
>>>>>> Not quintuples. There are lots of ways to represent a TM's states, but
>>>>>> states are not quintuples and quintuples are not states. This confusion
>>>>>> will (as you can see below) make lots of the code read badly.
>>>>>
>>>>> What did you think that states are?
>>>> Their only properties are that they are distinct and finite in number.
>>>
>>> Ah so you are only seeing the mathematical abstraction that uses
>>> directed graphs. That is not enough for an actual hardware machine to
>>> go on.
>> Nonsense. It's perfectly practical and entirely natiral to implement
>> this using a directed graph.
>
> A directed graph with labeled edges would seem to require all this
> (node and edge) info kept in a single struct when physically
> implemented as software. One node could have a list of edge data, yet
> that is cumbersome.
It's a few lines of C++.
>>>> I have written an interpreter in which the states are instances of a
>>>> class State, that holds all the information a TM might need when in that
>>>> state. But there are a hundreds of other ways to represent the states.
>>>
>>> In other words this:
>>> struct Quintuple
>>> {
>>> int state;
>>> int symbol;
>>> int write_symbol;
>>> int next_state;
>>> char tape_head_move;
>>> };
>> This is not a state. States are not quintuples and vice-versa. Please
>> don't pick this hill fight on.
>
> I want to grok this.
Grok what? Do you find the distinction between a state (a circle in the
graph of a TM) and a quintuple (one of the arrows in the graph) a
confusing one?
Or are you referring to groking my metaphor. All I meant is that this
distinction is so clear cut that digging your heels in over it is not a
wise move.
>>>> I think the best way to judge that will be to compare code. At the
>>>> moment you only have a very rough sketch.
>>>
>>> The "rough sketch" is fully operational code.
>
> More accurately the The "rough sketch" is my best estimate of is fully
> operational code.
>
>> That's very revealing. You've claimed to have other "fully operational
>> code" and since these sketches are clearly not operational, you must be
>> using the phrase in some rather loose way.
>
> I was trying to make it clear that it is not a more sketch with many
> missing pieces. All the pieces are there.
So saying "fully operational code" was what you have called "poetic
licence" in the past. Put a smiley in there next time you use this
level of poetic licence.
--
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-07 12:31 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t56adl$bkb$1@dont-email.me> |
| In reply to | #49922 |
On 5/6/2022 8:57 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 5/6/2022 6:36 AM, Ben wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> On 5/5/2022 9:35 PM, Ben wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>
>>>>>> struct Quintuple
>>>>>> {
>>>>>> u32 state;
>>>>>> u32 symbol;
>>>>>> u32 write_symbol;
>>>>>> u32 next_state;
>>>>>> u8 Tape_Head_Move;
>>>>>> }
>>>>>>
>>>>>> std::set<Quintuple> States;
>>>>> Why is a set of objects that are not states called "States"?
>>>>
>>>> They are states, what did you think that states are?
>
>>> Not quintuples. There are lots of ways to represent a TM's states, but
>>> states are not quintuples and quintuples are not states. This confusion
>>> will (as you can see below) make lots of the code read badly.
>>
>> What did you think that states are?
>
> Their only properties are that they are distinct and finite in number.
> I have written an interpreter in which the states are instances of a
> class State, that holds all the information a TM might need when in that
> state. But there are a hundreds of other ways to represent the states.
>
>> Do you think that they are raw integers?
>
> No, that's not what they are, though you could use integers to represent
> them. You could also use characters, strings and pointers to state
> objects.
>
> A key consideration, though, is that you might want to print information
> about the states to help the user of the interpreter so the states
> should be identifiable in some what that matches the way the user writes
> the TM. So I tend to favour labelling the sates with strings so that
> messages can report things like:
>
> In state 'open_(_seen': no transition for symbol '+'.
>
> If you are matching the input scheme for the implementation you posted a
> link to, then you should be able to report the state's name as the
> character the user will have entered.
>
>>>> This is the first draft of my transition_function() its seems to exactly match this design on the first page of the docs.
>>>> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
>>>>
>>>> I am writing this in Open Office Writer not any compiler.
>>>> I don't even know that it compiles.
>>>>
>>>> This is going to be a member function.
>>>> bool transition_function(std::set<Quintuple>::iterator& current_state)
>>>
>>> There's no point in putting the quintuples into a std::set. And the
>>> parameter current_state is badly worded as it refers to a particular
>>> rule (quintuple) and not to a state.
>>
>> It is simpler than a linear or binary search scan through the whole
>> list every-time we need to make a transition from the current_state to
>> the (next_state + current_Input).
>
> Of course, but a set is not, in my opinion, the natural container for
> quintuples. Do you even know how to make it work in your case? It
> would involve what I would consider a bit of trickery.
>
>> std::set<Quintuple>::iterator
>> NextState(int next_state, int current_input)
>> {
>> Quintuple QT(next_state, current_input);
>> return States.find(QT);
>> };
>>
>> The above returns an iterator to state indexed by (state + symbol).
>
> It returns an iterator to a quintuple, not a state, so the name is bad.
> And why does the function take things called 'next_state' and
> 'current_input'? The next quintuple is determined by the current state
> and the current input.
>
>> bool Transition_to_State_0(std::set<Quintuple>::iterator& current_state)
>> {
>> it = NextState(0, Tape[Tape_Head]);
>> if (it == States.end())
>> return false;
>> current_state = it;
>> return true;
>> }
>
> This looks all messed up but mainly because I don't think you are using
> the right names.
>
> And it's still a very loose sketch. Setting current_state is
> essentially pointless.
>
>>>> {
>>>> u32 next_state = current_state->next_state;
>>> States, as you make clear here are just unsigned integers (in your
>>> implementation).
>>>
>>
>> OK then I will use Quintuple_List as my designer implemented.
>>
>>>> u32 current_input = Tape[Tape_Head];
>>> Why reference the tape here? If Tape[Tape_Head] != current_state.symbol
>>> then something has gone very wrong already. Note how confusing my
>>> writing the condition is since current_state.symbol should not make
>>> sense.
>>
>> Although after successful find current_state->symbol would have the
>> same value as Tape[Tape_Head] it is more clear that we are referring
>> to the current input with the latter.
>>
>>> (By all means reference the tape to put in a run-time assertion that
>>> tape.head() == current_rule.symbol or some such but there's no need to
>>> get the symbol from the tape as you will already have done this in order
>>> to pass the right quintuple to this function.)
>>
>> My way is clearer.
>
> I think the best way to judge that will be to compare code. At the
> moment you only have a very rough sketch.
>
>>>> std::set<Quintuple>::iterator it;
>>>>
>>>> Tape[Tape_Head] = current_state->write_symbol;
>>> current_state.write_symbol
>>> But if the parameter were correctly named it would make more sense:
>>> Tape[Tape_Head] = current_rule.write_symbol
>>>
>>>> if (toupper(current_state->tape_head_move) == “L”;
>>>> Tape_Head--; // Left
>>>> else
>>>> Tape_Head++; // Right
>>> Since the tape has a very limited number of operations, I'd abstract it
>>> out into a class with a move member function (or a left and a right
>>> function).
>>
>> I think that it is more clear the way it is.
>
> Let's see how it turns out in the end.
>
>> Since the current state must refer to every element of its related
>> Quintuple and current_state is actually current_state + current_input,
>> this a single integer does not uniquely identify a Quintuple it seems
>> to make the most sense to call each Quintuple a state.
>>
>> It may be more conventional to have a two layered system where an
>> integer indexes into a list of states each one having a list of inputs
>> that they respond to. The ads extraneous complexity.
>>
>> I could call current_state current_quintuple.
>
> I think a lot of the problems a down to your uses state when you mean
> quintuple. NextState seems all wrong, but maybe it makes more sense if
> it does not find the next state but the next quintuple.
>
>> bool transition_function(std::set<Quintuple>::iterator& current_state)
>> {
>> u32 next_state = current_state->next_state;
>> u32 current_input = Tape[Tape_Head];
>> std::set<Quintuple>::iterator it;
>>
>> Tape[Tape_Head] = current_state->write_symbol;
>> if (toupper(current_state->tape_head_move) == “L”;
>> Tape_Head--; // Left
>> else
>> Tape_Head++; // Right
>>
>> it = NextState(next_state, current_input);
>> if (it == States.end())
>> return false;
>> current_state = it;
>> return true;
>> }
>
> With proper renaming this sketch makes a bit more sense. You take a
> current rule (I am getting tired typing quintuple) and NextState really
> finds the next rule, not state.
>
http://www.lns.mit.edu/~dsw/turing/turing.html
David S. Woodruff calls it next state:
This is his spec:
For example, the quintuple 'SCcsm' is executed by the machine:
If it is in state 'S' and is reading the symbol 'C' on the tape then
(a) make a transition to state 's'.
(b) overwrite the symbol 'C' on the tape with the symbol 'c'.
// Must do this before transition to state 's' or we lose 'c' from S.
(c) move the tape reading head one symbol to the left or right
according to whether 'm' is 'l' or 'r'.
http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
Everything else is implemented so that testing of the above function can
begin.
--
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-05 23:48 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t529bf$fls$1@dont-email.me> |
| In reply to | #49809 |
On 5/5/2022 9:35 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 5/5/2022 8:29 AM, Ben wrote:
>>> olcott <polcott2@gmail.com> writes:
>
>>>> 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 !
>>>
>>> Your mantra is doing sterling work, allowing you to pretend you are
>>> taking about the halting problem while hiding what it is that your
>>> deciders are deciding. Whatever you are hiding behind the words
>>> "correct simulations of this same input" it is obviously not the halting
>>> of P(P).
>>
>> You seem to have a short-circuit in your brain, I have told you this
>> many times and you have not seen it once.
>>
>> H1(P,P) IS THE HALT STATUS OF P(P)
>
> So what? Everyone know that there are an infinity of functions that are
> correct about the halting of P(P). It's H that's wrong, not H1.
>
> The only interesting thing about H1 is that you say it does that same as
> H but gets a different answer. Now that's a rabbit hole that other
> people might follow you down, but I don't care. You are wrong about too
> many things to be bothered about all of them.
>
> The important point is that your H is wrong because H(P,P) == false even
> though P(P) halts.
>
>>> For one thing, there is only one correct answer to the halting
>>> or otherwise of a computation, and for another, H(X,Y) is obviously not
>>> telling the world what it wants to know -- the halting of the
>>> computation X(Y).
>>
>> Since you know that a decider (halting or otherwise) only computes the
>> mapping from its inputs and that you insist that a halt decider
>> compute its mapping from non inputs it is either psychosis or
>> deception on your part.
>
> Remember all those other times you thought I was mad? Remember the last
> time? It was because you didn't know what a sequence was.
>
> Hint: every time you think I am lying or playing games or psychotic it's
> because your conviction that you can't be wrong has butted up against
> cold facts. You know, at some level of consciousness, that a C-like
> halt decider, bool D(ptr X, ptr Y);, returns true or false based on the
> halting of X(Y) as here:
>
>>> Do you have anything at all left to say about the real halting problem?
>>> I really think you should at least state, explicitly, that you now
>>> accept that no function D exists such that D(X,Y) == true if an only if
>>> X(Y) halts and false otherwise.
>
> We could make progress if you would accept that no such D can exist for
> whatever reason you choose to give -- even it's because you think X(Y)
> is a "non-input". But then there's no reason to think you will make
> such a clear statement.
>
>> H1(P,P)==true is empirically proven to be correct
>> H(P,P)==false is empirically proven to be correct
>>
>> That you keep contradicting verified facts that you already accept as
>> true seems quite nuts.
>
> H1 is irrelevant, and H is wrong by definition. Whatever H has been
> "empirically proven to be correct" about you are clear that it's not
> correct about the halting of P(P).
>
>> Halt deciders (like all deciders) compute the
>> mapping from their inputs.
>
> ... to specified true/false properties of those inputs. In the case of
> H, we want it to report on the halting or otherwise of its first
> argument when called with the second argument. Your H fails at that.
>
>> It turns out that the halting behavior of the correct simulation of
>> the input to H1(P,P) is the same as the halting behavior of P(P).
>
> And that is true of an infinity of equally irrelevant functions.
>
>> It turns out that the halting behavior of the correct simulation of
>> the input to H(P,P) is NOT the same as the halting behavior of P(P).
>
> Which is why H does not meet the specification of being a halt decider.
>
>> The ultimate measure is that H(P,P) does compute the mapping from its
>> inputs to its final reject state. This can be easily verified by
>> anyone with sufficient expertise in the x86 language.
>
> Yes, H just wrong to reject (P,P) because of how the halting problem is
> defined. No one disputes the fact that H(P,P) == false even though P(P)
> halts. The /only/ fact is dispute is the specification that H should
> meet.
>
>> I made good progress on Simplest TM interpreter yesterday. The
>> detailed design is halfway done. The trickiest part is the state
>> change function. I think that I am going to use a std::set that is
>> indexed on state + input.
>>
>> struct Quintuple
>> {
>> u32 state;
>> u32 symbol;
>> u32 write_symbol;
>> u32 next_state;
>> u8 Tape_Head_Move;
>> }
>>
>> std::set<Quintuple> States;
>
> Why is a set of objects that are not states called "States"?
>
They are states, what did you think that states are?
> Would you like some help with the design? Over the years I've written
> about a dozen TM interpreters in at least three languages, as well as
> having graded literally dozens of students' attempts at doing the same.
> Having a set of quintuples is of little help. It's a dead end.
>
This is the first draft of my transition_function() its seems to exactly
match this design (page 1 of the docs)
A Turing machine program consists of a list of 'quintuples', each one of
which is a five-symbol Turing machine instruction.
For example, the quintuple 'SCcsm' is executed by the machine
(a) if it is in state 'S'
(b) is reading the symbol 'C' on the tape.
(c) make a transition to state 's'
(d) overwrite the symbol 'C' on the tape with the symbol 'c'.
(e) move the tape reading head one symbol to the left or right
according to whether 'm' is 'l' or 'r'.
http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
This is going to be a member function.
bool transition_function(std::set<Quintuple>::iterator& current_state)
{
u32 next_state = current_state->next_state;
u32 current_input = Tape[Tape_Head];
std::set<Quintuple>::iterator it;
Tape[Tape_Head] = current_state->write_symbol;
if (toupper(current_state->tape_head_move) == “L”;
Tape_Head--; // Left
else
Tape_Head++; // Right
it = NextState(current_input, next_state);
if (it == States.end())
return false;
current_state = it;
return true;
}
--
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-05 23:01 -0600 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t52a2k$jk3$1@dont-email.me> |
| In reply to | #49824 |
On 2022-05-05 22:48, olcott wrote:
> On 5/5/2022 9:35 PM, Ben wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> I made good progress on Simplest TM interpreter yesterday. The
>>> detailed design is halfway done. The trickiest part is the state
>>> change function. I think that I am going to use a std::set that is
>>> indexed on state + input.
>>>
>>> struct Quintuple
>>> {
>>> u32 state;
>>> u32 symbol;
>>> u32 write_symbol;
>>> u32 next_state;
>>> u8 Tape_Head_Move;
>>> }
>>>
>>> std::set<Quintuple> States;
>>
>> Why is a set of objects that are not states called "States"?
>>
>
> They are states, what did you think that states are?
States are states. Quintuples are quintuples. They're not the same
thing. In a C implementation, a state is simply going to be an integer,
not some sort of struct.
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-06 00:12 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t52ano$n78$1@dont-email.me> |
| In reply to | #49825 |
On 5/6/2022 12:01 AM, André G. Isaak wrote:
> On 2022-05-05 22:48, olcott wrote:
>> On 5/5/2022 9:35 PM, Ben wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> I made good progress on Simplest TM interpreter yesterday. The
>>>> detailed design is halfway done. The trickiest part is the state
>>>> change function. I think that I am going to use a std::set that is
>>>> indexed on state + input.
>>>>
>>>> struct Quintuple
>>>> {
>>>> u32 state;
>>>> u32 symbol;
>>>> u32 write_symbol;
>>>> u32 next_state;
>>>> u8 Tape_Head_Move;
>>>> }
>>>>
>>>> std::set<Quintuple> States;
>>>
>>> Why is a set of objects that are not states called "States"?
>>>
>>
>> They are states, what did you think that states are?
>
> States are states. Quintuples are quintuples. They're not the same
> thing. In a C implementation, a state is simply going to be an integer,
> not some sort of struct.
>
> André
>
>
So then you don't disagree that my implementation of the TM transition
function matches its corresponding design?
This is the first draft of my transition_function() its seems to exactly
match this design (page 1 of the docs)
http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
A Turing machine program consists of a list of 'quintuples', each one of
which is a five-symbol Turing machine instruction.
For example, the quintuple 'SCcsm' is executed by the machine
(a) if it is in state 'S'
(b) is reading the symbol 'C' on the tape.
(c) make a transition to state 's'
(d) overwrite the symbol 'C' on the tape with the symbol 'c'.
(e) move the tape reading head one symbol to the left or right
according to whether 'm' is 'l' or 'r'.
This is going to be a member function.
bool transition_function(std::set<Quintuple>::iterator& current_state)
{
u32 next_state = current_state->next_state;
u32 current_input = Tape[Tape_Head];
std::set<Quintuple>::iterator it;
Tape[Tape_Head] = current_state->write_symbol;
if (toupper(current_state->tape_head_move) == “L”;
Tape_Head--; // Left
else
Tape_Head++; // Right
it = NextState(current_input, next_state);
if (it == States.end())
return false;
current_state = it;
return true;
}
--
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-06 07:36 -0600 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t5388a$b6j$1@dont-email.me> |
| In reply to | #49828 |
On 2022-05-05 23:12, olcott wrote:
> On 5/6/2022 12:01 AM, André G. Isaak wrote:
>> On 2022-05-05 22:48, olcott wrote:
>>> On 5/5/2022 9:35 PM, Ben wrote:
>>>> olcott <polcott2@gmail.com> writes:
>>>>
>>>>> I made good progress on Simplest TM interpreter yesterday. The
>>>>> detailed design is halfway done. The trickiest part is the state
>>>>> change function. I think that I am going to use a std::set that is
>>>>> indexed on state + input.
>>>>>
>>>>> struct Quintuple
>>>>> {
>>>>> u32 state;
>>>>> u32 symbol;
>>>>> u32 write_symbol;
>>>>> u32 next_state;
>>>>> u8 Tape_Head_Move;
>>>>> }
>>>>>
>>>>> std::set<Quintuple> States;
>>>>
>>>> Why is a set of objects that are not states called "States"?
>>>>
>>>
>>> They are states, what did you think that states are?
>>
>> States are states. Quintuples are quintuples. They're not the same
>> thing. In a C implementation, a state is simply going to be an
>> integer, not some sort of struct.
>>
>> André
>>
>>
>
> So then you don't disagree that my implementation of the TM transition
> function matches its corresponding design?
I said nothing about your implementation. I simply pointed out that you
are incorrectly referring to quintuples as states. I have no idea what
"its corresponding design" refers to.
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-06 10:32 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t53f1o$57i$1@dont-email.me> |
| In reply to | #49841 |
On 5/6/2022 8:36 AM, André G. Isaak wrote:
> On 2022-05-05 23:12, olcott wrote:
>> On 5/6/2022 12:01 AM, André G. Isaak wrote:
>>> On 2022-05-05 22:48, olcott wrote:
>>>> On 5/5/2022 9:35 PM, Ben wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>> I made good progress on Simplest TM interpreter yesterday. The
>>>>>> detailed design is halfway done. The trickiest part is the state
>>>>>> change function. I think that I am going to use a std::set that is
>>>>>> indexed on state + input.
>>>>>>
>>>>>> struct Quintuple
>>>>>> {
>>>>>> u32 state;
>>>>>> u32 symbol;
>>>>>> u32 write_symbol;
>>>>>> u32 next_state;
>>>>>> u8 Tape_Head_Move;
>>>>>> }
>>>>>>
>>>>>> std::set<Quintuple> States;
>>>>>
>>>>> Why is a set of objects that are not states called "States"?
>>>>>
>>>>
>>>> They are states, what did you think that states are?
>>>
>>> States are states. Quintuples are quintuples. They're not the same
>>> thing. In a C implementation, a state is simply going to be an
>>> integer, not some sort of struct.
>>>
>>> André
>>>
>>>
>>
>> So then you don't disagree that my implementation of the TM transition
>> function matches its corresponding design?
>
> I said nothing about your implementation. I simply pointed out that you
> are incorrectly referring to quintuples as states. I have no idea what
> "its corresponding design" refers to.
>
> André
>
This design was cut from the TM interpreter linked below:
A turing machine program consists of a list of 'quintuples', each one of
which is a five-symbol turing machine instruction.
For example, the quintuple 'SCcsm' is executed by the machine
(a) is in state 'S'
(b) is reading the symbol 'C' on the tape.
(c) makes a transition to state 's'
(d) overwrite the symbol 'C' on the tape with the symbol 'c'.
(e) move the tape reading head one symbol to the left or right
according to whether 'm' is 'l' or 'r'.
http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
transition_function() implements the transition_function() of the above
design. This is the hardest part of coding a TM interpreter (not very
hard).
struct Quintuple
{
u32 state;
u32 symbol;
u32 write_symbol;
u32 next_state;
u8 Tape_Head_Move;
};
bool transition_function(std::set<Quintuple>::iterator& current_state)
{
u32 next_state = current_state->next_state;
u32 current_input = Tape[Tape_Head];
std::set<Quintuple>::iterator it;
Tape[Tape_Head] = current_state->write_symbol;
if (toupper(current_state->tape_head_move) == “L”;
Tape_Head--; // Left
else
Tape_Head++; // Right
it = NextState(current_input, next_state);
if (it == States.end())
return false;
current_state = it;
return true;
}
--
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-06 09:43 -0600 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t53fn7$avk$1@dont-email.me> |
| In reply to | #49849 |
On 2022-05-06 09:32, olcott wrote:
> On 5/6/2022 8:36 AM, André G. Isaak wrote:
>> On 2022-05-05 23:12, olcott wrote:
>>> On 5/6/2022 12:01 AM, André G. Isaak wrote:
>>>> On 2022-05-05 22:48, olcott wrote:
>>>>> On 5/5/2022 9:35 PM, Ben wrote:
>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>
>>>>>>> I made good progress on Simplest TM interpreter yesterday. The
>>>>>>> detailed design is halfway done. The trickiest part is the state
>>>>>>> change function. I think that I am going to use a std::set that is
>>>>>>> indexed on state + input.
>>>>>>>
>>>>>>> struct Quintuple
>>>>>>> {
>>>>>>> u32 state;
>>>>>>> u32 symbol;
>>>>>>> u32 write_symbol;
>>>>>>> u32 next_state;
>>>>>>> u8 Tape_Head_Move;
>>>>>>> }
>>>>>>>
>>>>>>> std::set<Quintuple> States;
>>>>>>
>>>>>> Why is a set of objects that are not states called "States"?
>>>>>>
>>>>>
>>>>> They are states, what did you think that states are?
>>>>
>>>> States are states. Quintuples are quintuples. They're not the same
>>>> thing. In a C implementation, a state is simply going to be an
>>>> integer, not some sort of struct.
>>>>
>>>> André
>>>>
>>>>
>>>
>>> So then you don't disagree that my implementation of the TM
>>> transition function matches its corresponding design?
>>
>> I said nothing about your implementation. I simply pointed out that
>> you are incorrectly referring to quintuples as states. I have no idea
>> what "its corresponding design" refers to.
>>
>> André
>>
>
> This design was cut from the TM interpreter linked below:
> A turing machine program consists of a list of 'quintuples', each one of
> which is a five-symbol turing machine instruction.
The above does not claim that quintuples are states.
> For example, the quintuple 'SCcsm' is executed by the machine
> (a) is in state 'S'
> (b) is reading the symbol 'C' on the tape.
> (c) makes a transition to state 's'
> (d) overwrite the symbol 'C' on the tape with the symbol 'c'.
> (e) move the tape reading head one symbol to the left or right
> according to whether 'm' is 'l' or 'r'.
> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
Your (a)-(e) lettering are not part of the original and adding them
suggests you don't even understand the paragraph.
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-06 11:45 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t53jc5$a9p$1@dont-email.me> |
| In reply to | #49850 |
On 5/6/2022 10:43 AM, André G. Isaak wrote:
> On 2022-05-06 09:32, olcott wrote:
>> On 5/6/2022 8:36 AM, André G. Isaak wrote:
>>> On 2022-05-05 23:12, olcott wrote:
>>>> On 5/6/2022 12:01 AM, André G. Isaak wrote:
>>>>> On 2022-05-05 22:48, olcott wrote:
>>>>>> On 5/5/2022 9:35 PM, Ben wrote:
>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>
>>>>>>>> I made good progress on Simplest TM interpreter yesterday. The
>>>>>>>> detailed design is halfway done. The trickiest part is the state
>>>>>>>> change function. I think that I am going to use a std::set that is
>>>>>>>> indexed on state + input.
>>>>>>>>
>>>>>>>> struct Quintuple
>>>>>>>> {
>>>>>>>> u32 state;
>>>>>>>> u32 symbol;
>>>>>>>> u32 write_symbol;
>>>>>>>> u32 next_state;
>>>>>>>> u8 Tape_Head_Move;
>>>>>>>> }
>>>>>>>>
>>>>>>>> std::set<Quintuple> States;
>>>>>>>
>>>>>>> Why is a set of objects that are not states called "States"?
>>>>>>>
>>>>>>
>>>>>> They are states, what did you think that states are?
>>>>>
>>>>> States are states. Quintuples are quintuples. They're not the same
>>>>> thing. In a C implementation, a state is simply going to be an
>>>>> integer, not some sort of struct.
>>>>>
>>>>> André
>>>>>
>>>>>
>>>>
>>>> So then you don't disagree that my implementation of the TM
>>>> transition function matches its corresponding design?
>>>
>>> I said nothing about your implementation. I simply pointed out that
>>> you are incorrectly referring to quintuples as states. I have no idea
>>> what "its corresponding design" refers to.
>>>
>>> André
>>>
>>
>> This design was cut from the TM interpreter linked below:
>> A turing machine program consists of a list of 'quintuples', each one
>> of which is a five-symbol turing machine instruction.
>
> The above does not claim that quintuples are states.
OK, so I will change the name current_state to Current_Quintuple and
States to Quintuple_List.
>
>> For example, the quintuple 'SCcsm' is executed by the machine
>> (a) is in state 'S'
>> (b) is reading the symbol 'C' on the tape.
>> (c) makes a transition to state 's'
>> (d) overwrite the symbol 'C' on the tape with the symbol 'c'.
>> (e) move the tape reading head one symbol to the left or right
>> according to whether 'm' is 'l' or 'r'.
>> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
>
> Your (a)-(e) lettering are not part of the original and adding them
> suggests you don't even understand the paragraph.
>
> André
>
I trimmed the original and reformatted to make is easier to understand.
It is pretty callous to say that I made a mistake when no actual mistake
can be pointed out.
*The question was*
*Does the following implementation match the above design?*
bool transition_function(std::set<Quintuple>::iterator& current_quintuple)
{
u32 next_state = current_quintuple->next_state;
u32 current_input = Tape[Tape_Head];
std::set<Quintuple>::iterator it;
Tape[Tape_Head] = current_quintuple->write_symbol;
if (toupper(current_quintuple->tape_head_move) == “L”;
Tape_Head--; // Left
else
Tape_Head++; // Right
it = NextState(next_state, current_input);
if (it == Quintuple_List.end())
return false;
current_state = it;
return true;
}
--
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-06 11:01 -0600 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t53k9p$hta$1@dont-email.me> |
| In reply to | #49853 |
On 2022-05-06 10:45, olcott wrote: > On 5/6/2022 10:43 AM, André G. Isaak wrote: >> On 2022-05-06 09:32, olcott wrote: >>> For example, the quintuple 'SCcsm' is executed by the machine >>> (a) is in state 'S' >>> (b) is reading the symbol 'C' on the tape. >>> (c) makes a transition to state 's' >>> (d) overwrite the symbol 'C' on the tape with the symbol 'c'. >>> (e) move the tape reading head one symbol to the left or right >>> according to whether 'm' is 'l' or 'r'. >>> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt >> >> Your (a)-(e) lettering are not part of the original and adding them >> suggests you don't even understand the paragraph. >> >> André >> > > I trimmed the original and reformatted to make is easier to understand. And destroyed the meaning in the process. That certainly doesn't make it "easier" to understand. First, you eliminate the crucial words "if it" from (a). Second, you split (a) and (b) into two items thereby obscuring the fact that these two go together and are both equally part of the condition which the missing 'if it' describes. Third, by formatting this as a list if five items you obscure the fact that (a) and (b) are entirely different from (c)-(e). (a) and (b) describe the CONDITION under which the transition described by the rule apply. (c) - (e) describe the ACTION taken when this transition is applied. > It is pretty callous to say that I made a mistake when no actual mistake > can be pointed out. Answered above. 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-06 13:03 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t53nsn$ftg$1@dont-email.me> |
| In reply to | #49857 |
On 5/6/2022 12:01 PM, André G. Isaak wrote:
> On 2022-05-06 10:45, olcott wrote:
>> On 5/6/2022 10:43 AM, André G. Isaak wrote:
>>> On 2022-05-06 09:32, olcott wrote:
>
>>>> For example, the quintuple 'SCcsm' is executed by the machine
>>>> (a) is in state 'S'
>>>> (b) is reading the symbol 'C' on the tape.
>>>> (c) makes a transition to state 's'
>>>> (d) overwrite the symbol 'C' on the tape with the symbol 'c'.
>>>> (e) move the tape reading head one symbol to the left or right
>>>> according to whether 'm' is 'l' or 'r'.
>>>> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
>>>
>>> Your (a)-(e) lettering are not part of the original and adding them
>>> suggests you don't even understand the paragraph.
>>>
>>> André
>>>
>>
>> I trimmed the original and reformatted to make is easier to understand.
>
> And destroyed the meaning in the process. That certainly doesn't make it
> "easier" to understand.
>
> First, you eliminate the crucial words "if it" from (a).
>
Yes you are correct this is my mistake.
> Second, you split (a) and (b) into two items thereby obscuring the fact
> that these two go together and are both equally part of the condition
> which the missing 'if it' describes.
>
Yes you are correct this is my mistake. I should have done a more
accurate job specifying the original design.
A turing machine is a model of a computer. It has a finite number of
states, and it is capable of reading and modifying a tape. A turing
machine program consists of a list of 'quintuples', each one of which is
a five-symbol turing machine instruction. For example, the quintuple
'SCcsm' is executed by the machine if it is in state 'S' and is reading
the symbol 'C' on the tape. In that case, the instruction causes the
machine to make a transition to state 's' and to overwrite the symbol
'C' on the tape with the symbol 'c'. The last operation it performs
under this instruction is to move the tape reading head one symbol to
the left or right according to whether 'm' is 'l' or 'r'.
http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
For example, the quintuple 'SCcsm' is executed by the machine:
if is in state 'S' and is reading the symbol 'C' on the tape then
(a) make a transition to state 's'.
(b) overwrite the symbol 'C' on the tape with the symbol 'c'.
(c) move the tape reading head one symbol to the left or right
according to whether 'm' is 'l' or 'r'.
> Third, by formatting this as a list if five items you obscure the fact
> that (a) and (b) are entirely different from (c)-(e).
>
Not at all (a) is named S (b) is named C whereas
(c) is named s and (d) is named c.
> (a) and (b) describe the CONDITION under which the transition described
> by the rule apply.
>
Yes
> (c) - (e) describe the ACTION taken when this transition is applied.
>
Yes
>> It is pretty callous to say that I made a mistake when no actual
>> mistake can be pointed out.
>
> Answered above.
>
Good critique.
> André
>
>
Because there is no current_quintuple when quintuple_list::find fails
then the following function can safely assume that current_quintuple is
in state 'S' and is reading the symbol 'C' on the tape.
Does this transition_function() implement the above design?
bool transition_function(std::set<Quintuple>::iterator& current_quintuple)
{
u32 next_state = current_quintuple->next_state;
u32 current_input = Tape[Tape_Head];
std::set<Quintuple>::iterator it;
Tape[Tape_Head] = current_quintuple->write_symbol;
if (toupper(current_quintuple->tape_head_move) == “L”;
Tape_Head--; // Left
else
Tape_Head++; // Right
it = NextState(next_state, current_input);
if (it == Quintuple_List.end())
return false;
current_state = it;
return true;
}
--
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-06 12:18 -0600 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t53op3$m5h$1@dont-email.me> |
| In reply to | #49864 |
On 2022-05-06 12:03, olcott wrote: > On 5/6/2022 12:01 PM, André G. Isaak wrote: >> On 2022-05-06 10:45, olcott wrote: >>> On 5/6/2022 10:43 AM, André G. Isaak wrote: >>>> On 2022-05-06 09:32, olcott wrote: >> >>>>> For example, the quintuple 'SCcsm' is executed by the machine >>>>> (a) is in state 'S' >>>>> (b) is reading the symbol 'C' on the tape. >>>>> (c) makes a transition to state 's' >>>>> (d) overwrite the symbol 'C' on the tape with the symbol 'c'. >>>>> (e) move the tape reading head one symbol to the left or right >>>>> according to whether 'm' is 'l' or 'r'. >>>>> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt >>>> >>>> Your (a)-(e) lettering are not part of the original and adding them >>>> suggests you don't even understand the paragraph. >>>> >>>> André >>>> >>> >>> I trimmed the original and reformatted to make is easier to understand. >> >> And destroyed the meaning in the process. That certainly doesn't make >> it "easier" to understand. >> >> First, you eliminate the crucial words "if it" from (a). >> > > Yes you are correct this is my mistake. > >> Second, you split (a) and (b) into two items thereby obscuring the >> fact that these two go together and are both equally part of the >> condition which the missing 'if it' describes. >> > > Yes you are correct this is my mistake. I should have done a more > accurate job specifying the original design. The way to do that would be to have just left the original quote alone given that it was already perfectly clear. "Quoting" it without indicating that it has been altered is simply deceptive. 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-06 13:50 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t53qla$6g7$1@dont-email.me> |
| In reply to | #49865 |
On 5/6/2022 1:18 PM, André G. Isaak wrote:
> On 2022-05-06 12:03, olcott wrote:
>> On 5/6/2022 12:01 PM, André G. Isaak wrote:
>>> On 2022-05-06 10:45, olcott wrote:
>>>> On 5/6/2022 10:43 AM, André G. Isaak wrote:
>>>>> On 2022-05-06 09:32, olcott wrote:
>>>
>> Yes you are correct this is my mistake. I should have done a more
>> accurate job specifying the original design.
>
> The way to do that would be to have just left the original quote alone
> given that it was already perfectly clear. "Quoting" it without
> indicating that it has been altered is simply deceptive.
>
> André
>
A turing machine is a model of a computer. It has a finite number of
states, and it is capable of reading and modifying a tape. A turing
machine program consists of a list of 'quintuples', each one of which is
a five-symbol turing machine instruction. For example, the quintuple
'SCcsm' is executed by the machine if it is in state 'S' and is reading
the symbol 'C' on the tape. In that case, the instruction causes the
machine to make a transition to state 's' and to overwrite the symbol
'C' on the tape with the symbol 'c'. The last operation it performs
under this instruction is to move the tape reading head one symbol to
the left or right according to whether 'm' is 'l' or 'r'.
http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
This does more succinctly (and thus more clearly) list the essential
elements of the design, that the above paragraph specifies.
For example, the quintuple 'SCcsm' is executed by the machine:
if is in state 'S' and is reading the symbol 'C' on the tape then
(a) make a transition to state 's'.
(b) overwrite the symbol 'C' on the tape with the symbol 'c'.
// This must occur before the state transition or we lose access to
// current_quintuple->write_symbol
(c) move the tape reading head one symbol to the left or right
according to whether 'm' is 'l' or 'r'.
When we assume that current_quintuple was found in quintuple_list then
this does seem to correctly implement the above design:
bool transition_function(std::set<Quintuple>::iterator& current_quintuple)
{
u32 next_state = current_quintuple->next_state;
u32 current_input = Tape[Tape_Head];
std::set<Quintuple>::iterator next_quintuple;
Tape[Tape_Head] = current_quintuple->write_symbol;
if (toupper(current_quintuple->tape_head_move) == “L”;
Tape_Head--; // Left
else
Tape_Head++; // Right
next_quintuple = NextState(next_state, current_input);
if (next_quintuple == Quintuple_List.end())
return false;
current_state = it;
return true;
}
Do you think that the above function matches its design?
--
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-06 13:05 -0600 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t53rid$dva$1@dont-email.me> |
| In reply to | #49868 |
On 2022-05-06 12:50, olcott wrote:
> On 5/6/2022 1:18 PM, André G. Isaak wrote:
>> On 2022-05-06 12:03, olcott wrote:
>>> On 5/6/2022 12:01 PM, André G. Isaak wrote:
>>>> On 2022-05-06 10:45, olcott wrote:
>>>>> On 5/6/2022 10:43 AM, André G. Isaak wrote:
>>>>>> On 2022-05-06 09:32, olcott wrote:
>>>>
>>> Yes you are correct this is my mistake. I should have done a more
>>> accurate job specifying the original design.
>>
>> The way to do that would be to have just left the original quote alone
>> given that it was already perfectly clear. "Quoting" it without
>> indicating that it has been altered is simply deceptive.
>>
>> André
>>
>
> A turing machine is a model of a computer. It has a finite number of
> states, and it is capable of reading and modifying a tape. A turing
> machine program consists of a list of 'quintuples', each one of which is
> a five-symbol turing machine instruction. For example, the quintuple
> 'SCcsm' is executed by the machine if it is in state 'S' and is reading
> the symbol 'C' on the tape. In that case, the instruction causes the
> machine to make a transition to state 's' and to overwrite the symbol
> 'C' on the tape with the symbol 'c'. The last operation it performs
> under this instruction is to move the tape reading head one symbol to
> the left or right according to whether 'm' is 'l' or 'r'.
> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
>
>
> This does more succinctly (and thus more clearly) list the essential
> elements of the design, that the above paragraph specifies.
> For example, the quintuple 'SCcsm' is executed by the machine:
>
> if is in state 'S' and is reading the symbol 'C' on the tape then
> (a) make a transition to state 's'.
> (b) overwrite the symbol 'C' on the tape with the symbol 'c'.
>
> // This must occur before the state transition or we lose access to
> // current_quintuple->write_symbol
>
> (c) move the tape reading head one symbol to the left or right
> according to whether 'm' is 'l' or 'r'.
>
> When we assume that current_quintuple was found in quintuple_list then
> this does seem to correctly implement the above design:
Design? Do you mean 'specification'?
> bool transition_function(std::set<Quintuple>::iterator& current_quintuple)
> {
> u32 next_state = current_quintuple->next_state;
> u32 current_input = Tape[Tape_Head];
> std::set<Quintuple>::iterator next_quintuple;
>
> Tape[Tape_Head] = current_quintuple->write_symbol;
> if (toupper(current_quintuple->tape_head_move) == “L”;
> Tape_Head--; // Left
> else
> Tape_Head++; // Right
>
> next_quintuple = NextState(next_state, current_input);
> if (next_quintuple == Quintuple_List.end())
> return false;
> current_state = it;
> return true;
> }
>
> Do you think that the above function matches its design?
I have no idea what 'its design' is supposed to mean.
If by design you mean 'specification', then how is anyone supposed to
tell? You've got a bunch of horribly-named variables and undefined
functions.
What is the point of this exercise? You already have access to a TM
interpreter which written by someone who actually knows what they are
doing. If you can't write a TM which decides evenness, what on earth
would possess you to think you understand TMs well enough to write a TM
interpreter?
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-06 14:19 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t53scr$kr3$1@dont-email.me> |
| In reply to | #49870 |
On 5/6/2022 2:05 PM, André G. Isaak wrote:
> On 2022-05-06 12:50, olcott wrote:
>> On 5/6/2022 1:18 PM, André G. Isaak wrote:
>>> On 2022-05-06 12:03, olcott wrote:
>>>> On 5/6/2022 12:01 PM, André G. Isaak wrote:
>>>>> On 2022-05-06 10:45, olcott wrote:
>>>>>> On 5/6/2022 10:43 AM, André G. Isaak wrote:
>>>>>>> On 2022-05-06 09:32, olcott wrote:
>>>>>
>>>> Yes you are correct this is my mistake. I should have done a more
>>>> accurate job specifying the original design.
>>>
>>> The way to do that would be to have just left the original quote
>>> alone given that it was already perfectly clear. "Quoting" it without
>>> indicating that it has been altered is simply deceptive.
>>>
>>> André
>>>
>>
>> A turing machine is a model of a computer. It has a finite number of
>> states, and it is capable of reading and modifying a tape. A turing
>> machine program consists of a list of 'quintuples', each one of which
>> is a five-symbol turing machine instruction. For example, the
>> quintuple 'SCcsm' is executed by the machine if it is in state 'S' and
>> is reading the symbol 'C' on the tape. In that case, the instruction
>> causes the machine to make a transition to state 's' and to overwrite
>> the symbol 'C' on the tape with the symbol 'c'. The last operation it
>> performs under this instruction is to move the tape reading head one
>> symbol to the left or right according to whether 'm' is 'l' or 'r'.
>> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
>>
>>
>> This does more succinctly (and thus more clearly) list the essential
>> elements of the design, that the above paragraph specifies.
>> For example, the quintuple 'SCcsm' is executed by the machine:
>>
>> if is in state 'S' and is reading the symbol 'C' on the tape then
>> (a) make a transition to state 's'.
>> (b) overwrite the symbol 'C' on the tape with the symbol 'c'.
>>
>> // This must occur before the state transition or we lose access to
>> // current_quintuple->write_symbol
>>
>> (c) move the tape reading head one symbol to the left or right
>> according to whether 'm' is 'l' or 'r'.
>>
>> When we assume that current_quintuple was found in quintuple_list then
>> this does seem to correctly implement the above design:
>
> Design? Do you mean 'specification'?
>
>> bool transition_function(std::set<Quintuple>::iterator&
>> current_quintuple)
>> {
>> u32 next_state = current_quintuple->next_state;
>> u32 current_input = Tape[Tape_Head];
>> std::set<Quintuple>::iterator next_quintuple;
>>
>> Tape[Tape_Head] = current_quintuple->write_symbol;
>> if (toupper(current_quintuple->tape_head_move) == “L”;
>> Tape_Head--; // Left
>> else
>> Tape_Head++; // Right
>>
>> next_quintuple = NextState(next_state, current_input);
>> if (next_quintuple == Quintuple_List.end())
>> return false;
>> current_state = it;
correction: current_state = next_quintuple;
>> return true;
>> }
>>
>> Do you think that the above function matches its design?
>
> I have no idea what 'its design' is supposed to mean.
>
> If by design you mean 'specification', then how is anyone supposed to
> tell? You've got a bunch of horribly-named variables and undefined
> functions.
>
A design is a kind of specification.
The functionality of the functions can be inferred from their use.
What do you think is horribly named?
> What is the point of this exercise? You already have access to a TM
> interpreter which written by someone who actually knows what they are
> doing. If you can't write a TM which decides evenness, what on earth
> would possess you to think you understand TMs well enough to write a TM
> interpreter?
>
> André
>
--
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 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.theory
csiph-web