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 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2022-05-06 13:23 -0600 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t53sjn$mfu$1@dont-email.me> |
| In reply to | #49876 |
On 2022-05-06 13:19, olcott wrote:
> 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.
No. That's not how these words are used. A design and a specification
are entirely different things.
> The functionality of the functions can be inferred from their use.
> What do you think is horribly named?
Well, you've got a variable called current_state that represents a
quintuple rather than a state, for one.
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:34 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t53t7f$rdg$1@dont-email.me> |
| In reply to | #49878 |
On 5/6/2022 2:23 PM, André G. Isaak wrote:
> On 2022-05-06 13:19, olcott wrote:
>> 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;
current_quintuple = 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.
>
> No. That's not how these words are used. A design and a specification
> are entirely different things.
>
I don't do it that way.
I have designs at various levels of abstraction/versus specificity.
The most specific level of design is the actual coding in C++.
Just above this is the pseudo code.
>> The functionality of the functions can be inferred from their use.
>> What do you think is horribly named?
>
> Well, you've got a variable called current_state that represents a
> quintuple rather than a state, for one.
>
> André
>
Yet another typo.
--
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:37 -0600 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t53tdq$ss7$1@dont-email.me> |
| In reply to | #49881 |
On 2022-05-06 13:34, olcott wrote: > On 5/6/2022 2:23 PM, André G. Isaak wrote: >> On 2022-05-06 13:19, olcott wrote: >>> A design is a kind of specification. >> >> No. That's not how these words are used. A design and a specification >> are entirely different things. >> > > I don't do it that way. And that's a major part of your problem: You keep inventing your own meanings for words which already have well-established usage and thus have absolutely no hope of ever communicating your ideas to anyone. Worse, you misinterpret most everything you read because you substitute your own private meanings for whatever the author actually intended to say. 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:48 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t53u21$21o$1@dont-email.me> |
| In reply to | #49882 |
On 5/6/2022 2:37 PM, André G. Isaak wrote:
> On 2022-05-06 13:34, olcott wrote:
>> On 5/6/2022 2:23 PM, André G. Isaak wrote:
>>> On 2022-05-06 13:19, olcott wrote:
>
>>>> A design is a kind of specification.
>>>
>>> No. That's not how these words are used. A design and a specification
>>> are entirely different things.
>>>
>>
>> I don't do it that way.
>
> And that's a major part of your problem: You keep inventing your own
> meanings for words which already have well-established usage and thus
> have absolutely no hope of ever communicating your ideas to anyone.
>
A software requirements specification (SRS) is a document that describes
what the software will do and how it will be expected to perform. It
also describes the functionality the product needs to fulfill all
stakeholders (business, users) needs.
https://www.perforce.com/blog/alm/how-write-software-requirements-specification-srs-document#what-is-a-software-requirements-specification-document
So it is merely a design with enough detail that the system can be
implemented on the basis of the spec. This is exactly the same thing as
my next to last level of detailed design.
My designs start with very high level abstractions
---Begin Design of Simplest TM Interpreter---
(1) Parse Lines of text in the filename.tm file into
(a) structure of five fields.
(1) current state // possibly redundant
(2) current symbol
(3) next state
(4) write symbol
(5) Move tape head L(eft) or R(ight)
(b) single contiguous sequence of tape elements
(2) Make executable TM
And are progressively refined until working code is derived.
> Worse, you misinterpret most everything you read because you substitute
> your own private meanings for whatever the author actually intended to say.
>
> 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]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-07 00:47 +0100 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <87a6bu1aw4.fsf@bsb.me.uk> |
| In reply to | #49870 |
André G. Isaak <agisaak@gm.invalid> writes: > What is the point of this exercise? It's a delaying tactic. PO can now claim that he's started to write the TM I called E, but since no existing interpreter meets his exacting standards, he simply must sort that out first. There may also be a legitimate purpose. It's possible that PO hopes that by writing an interpreter he will gain enough understanding of TMs to write E. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-05-06 18:59 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t54cpv$986$1@dont-email.me> |
| In reply to | #49905 |
On 5/6/2022 6:47 PM, Ben wrote:
> André G. Isaak <agisaak@gm.invalid> writes:
>
>> What is the point of this exercise?
>
> It's a delaying tactic. PO can now claim that he's started to write the
> TM I called E, but since no existing interpreter meets his exacting
> standards, he simply must sort that out first.
>
> There may also be a legitimate purpose. It's possible that PO hopes
> that by writing an interpreter he will gain enough understanding of TMs
> to write E.
>
I wanted a Minimal TM interpreter that has <= three minute learning
curve for people that already know TM's very well.
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'
THIS SEEMS TO EXACTLY MATCH THE SPEC PROVIDED ABOVE.
THE SPEC SEEMS TO HAVE AN ERROR (see above) THAT WAS ACCOUNTED FOR.
bool Quintuple_List::transition_function
(std::set<Quintuple>::iterator& current_quintuple)
{
unsigned int next_state = current_quintuple->next_state;
unsigned int 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 == States.end())
return false;
current_quintuple = next_quintuple;
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 | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-07 03:04 +0100 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <87fslmxfn3.fsf@bsb.me.uk> |
| In reply to | #49908 |
olcott <polcott2@gmail.com> writes:
> bool Quintuple_List::transition_function
> (std::set<Quintuple>::iterator& current_quintuple)
> {
> unsigned int next_state = current_quintuple->next_state;
> unsigned int 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 == States.end())
> return false;
> current_quintuple = next_quintuple;
> return true;
> }
Much better names, but still not right. There's no point is setting
current_quintuple at the end, and the symbol used to look up the next
quintuple is the wrong one. And Sates is still misnamed: the iterators
are into a set of Quintuples, not states.
--
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:26 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t54lc1$uiv$1@dont-email.me> |
| In reply to | #49923 |
On 5/6/2022 9:04 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> bool Quintuple_List::transition_function
>> (std::set<Quintuple>::iterator& current_quintuple)
>> {
>> unsigned int next_state = current_quintuple->next_state;
>> unsigned int 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 == States.end())
>> return false;
>> current_quintuple = next_quintuple;
>> return true;
>> }
>
> Much better names, but still not right. There's no point is setting
> current_quintuple at the end, and the symbol used to look up the next
> quintuple is the wrong one. And Sates is still misnamed: the iterators
> are into a set of Quintuples, not states.
>
It is a reference parameter thus current_state is set to the state that
was transitioned to. true / false is returned on success / failure.
My execution engine simple loops until NextState() returns false.
--
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-06 23:03 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t54r1v$t4m$1@dont-email.me> |
| In reply to | #49923 |
On 5/6/2022 9:04 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> bool Quintuple_List::transition_function
>> (std::set<Quintuple>::iterator& current_quintuple)
>> {
>> unsigned int next_state = current_quintuple->next_state;
>> unsigned int 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 == States.end())
>> return false;
>> current_quintuple = next_quintuple;
>> return true;
>> }
>
> Much better names, but still not right. There's no point is setting
> current_quintuple at the end, and the symbol used to look up the next
> quintuple is the wrong one. And Sates is still misnamed: the iterators
> are into a set of Quintuples, not states.
>
I got the whole thing almost done.
I figured out a simpler way to parse the tape data.
The std::set:find works perfectly.
--
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-06 00:55 -0500 |
| Subject | Re: H(P,P) == false is correct [ Simple TM Interpreter ] |
| Message-ID | <t52d8v$5s8$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é
In Lex the lexical analyzer "states" all of the actions are considered
to be a part of the state.
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-05-05 22:51 -0400 |
| Subject | Re: H(P,P) == false is correct [ verified facts ] |
| Message-ID | <Y20dK.2941$arR.464@fx48.iad> |
| In reply to | #49777 |
On 5/5/22 6:12 PM, olcott wrote:
> On 5/5/2022 8:29 AM, Ben wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> On 5/4/2022 9:28 PM, Ben wrote:
>>>> olcott <polcott2@gmail.com> writes:
>>>>
>>>>> On 5/4/2022 7:59 PM, Ben wrote:
>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>
>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>
>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
>>>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>>>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> It is clear that the input to H(P,P) specifies infinitely
>>>>>>>>>>>>> nested
>>>>>>>>>>>>> simulation to H.
>>>>>>>>>>>> What two pointers must be passed to H for H to tell up about
>>>>>>>>>>>> the halting
>>>>>>>>>>>> of P(P)? If H can't report on the halting of the
>>>>>>>>>>>> computation P(P) it is
>>>>>>>>>>>> not a halt decider, and you have already told use that
>>>>>>>>>>>> H(P,P) == false
>>>>>>>>>>>> and that P(P) halts.
>>>>>>>>>>>
>>>>>>>>>>> If H can report on the halting of non-input P(P) then it is
>>>>>>>>>>> not a
>>>>>>>>>>> decider because deciders only compute the mapping from inputs
>>>>>>>>>>> to final
>>>>>>>>>>> states.
>>>>>>>>>> TM deciders compute mappings from inputs to final states
>>>>>>>>>> /according to
>>>>>>>>>> some property of the inputs/
>>>>>>>>>
>>>>>>>>> That par is exactly correct.
>>>>>>>>>
>>>>>>>>>> -- whether the input represents, for
>>>>>>>>>
>>>>>>>>> That part has been the key error of everyone in that they all
>>>>>>>>> believe
>>>>>>>>> that is can represent something other than what it actually
>>>>>>>>> specifies.
>>>>>>>>
>>>>>>>> So now, after thinking otherwise for years, you claim that there
>>>>>>>> is no
>>>>>>>> way to even specify the computation P(P) for you pseudo-C halt
>>>>>>>> decider
>>>>>>>> H. At least that is a clear admission that the halting of function
>>>>>>>> calls like P(P) can not be decided because, apparently, passing
>>>>>>>> P and P
>>>>>>>> to H does not specify that computation, and you can't say what two
>>>>>>>> arguments /would/ specify it.
>>>>>>>>
>>>>>>>> A clear and unambiguous statement that no D such that D(X,Y) ==
>>>>>>>> true if
>>>>>>>> and only if X(Y) halts and false otherwise is possible would be the
>>>>>>>> honest way to move things on. If you were clear about this, maybe
>>>>>>>> someone will talk to you about [whatever] it is that your H is
>>>>>>>> deciding.
>>>>>> So you won't admit that no algorithm can do what D is specified to
>>>>>> do?
>>>>>> You are just going to pretend that no one cares about actual halting.
>>>>>> I hope you see that by ignoring this point you are confirming that
>>>>>> you
>>>>>> know D can't exist. If you thought such a D was possible, you'd be
>>>>>> shouting that from the roof tops since it's what everyone else
>>>>>> says is
>>>>>> impossible.
>>>>>>
>>>>>>> I adapted my system so that I could empirically test this:
>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>
>>>>>> But neither can tell us squat about the halting of P(P) -- the thing
>>>>>> that H was originally supposed to decide.
>>>>>
>>>>> Are you simply wired to ignore my words so that you can disagree with
>>>>> everything that I say?
>>>>>
>>>>> H1(P,P)==true reports on the behavior of P(P).
>>>> I try to ignore that bits that are irrelevant. These two deciders
>>>> decide all halting instances between them:
>>>> bool H1(X, Y) { return true; }
>>>> bool H2(X, Y) { return false; }
>>>> Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
>>>> maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
>>>
>>> H1(P,P)==true is empirically proven to be correct
>>> H(P,P)==false is empirically proven to be correct
>>
>>> Both take the machine code of P as input parameters and are provably
>>> correct simulations of this same input yet one correctly determines
>>> that its input halts and the other correctly determines that its input
>>> does not halt. ALL THESE THINGS ARE VERIFIED FACTS !
>>
>> 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)
> H1(P,P) IS THE HALT STATUS OF P(P)
> H1(P,P) IS THE HALT STATUS OF P(P)
> H1(P,P) IS THE HALT STATUS OF P(P)
> H1(P,P) IS THE HALT STATUS OF P(P)
But H1 is not H, so this is just admitting that H can't do the job?
>
>> 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.
You may "KNOW" that, but you don't seem to understand the actual truth
about what it is requried to do, but can't in this case.
>
>> 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.
>>
>
> H1(P,P)==true is empirically proven to be correct
> H(P,P)==false is empirically proven to be correct
Nope. At least not for the question you claim to be asking. Maybe for
the question you are actually asking, but that isn't about the actual
Halting Problem.
>
> That you keep contradicting verified facts that you already accept as
> true seems quite nuts. Halt deciders (like all deciders) compute the
> mapping from their inputs.
>
> 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).
But the halting problem isn't about the "correct simulation of the
input" but about the behavior of the machine represented by the input
applied to the input represented in the input.
Since this doesn't seem to be what you consider the "correct simulation
of the input", and you refuse to actually DEFINE what you mean by that,
we can plainly see that you aren't actually talking about Halting, but
only are incorrectly (or deceitfully) claiming to be.
>
> 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).
Thus, your admission that you aren't actually working on the halting
problem, because for that problem, it needs to be.
>
> 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.
You may compute *A* Mapping, but not *THE* mapping of the Halting Problem.
FAIL.
>
>> I am sure some people will still want to talk about the mistakes in what
>> you call the "correct simulations of this same input" but you should be
>> honest about halting problem as defined above. And if people do stop
>> talking to you about halting, you can always switch back to Gödel or
>> Tarski.
>
> 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;
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2022-05-06 12:42 +0300 |
| Subject | Re: H(P,P) == false is correct [ verified facts ] |
| Message-ID | <t52qhg$ue$1@dont-email.me> |
| In reply to | #49777 |
On 2022-05-05 22:12:51 +0000, olcott said:
> struct Quintuple
> {
> u32 state;
> u32 symbol;
> u32 write_symbol;
> u32 next_state;
> u8 Tape_Head_Move;
> }
>
> std::set<Quintuple> States;
I would recommend "Rule" pro "Quintuple" and "Rules" pro "States".
Then the code would be easier to understand.
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-05-06 14:09 -0500 |
| Subject | Re: H(P,P) == false is correct [ verified facts ] |
| Message-ID | <t53roj$ej0$2@dont-email.me> |
| In reply to | #49835 |
On 5/6/2022 4:42 AM, Mikko wrote:
> On 2022-05-05 22:12:51 +0000, olcott said:
>
>> struct Quintuple
>> {
>> u32 state;
>> u32 symbol;
>> u32 write_symbol;
>> u32 next_state;
>> u8 Tape_Head_Move;
>> }
>>
>> std::set<Quintuple> States;
>
> I would recommend "Rule" pro "Quintuple" and "Rules" pro "States".
> Then the code would be easier to understand.
>
> Mikko
>
>
I am currently calling it Quintuple_List.
--
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 | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2022-05-03 12:36 +0300 |
| Message-ID | <t4qt3c$vbe$1@dont-email.me> |
| In reply to | #49508 |
On 2022-05-02 16:18:36 +0000, olcott said: > It seems to me that all infinitely recursive definitions are invalid > and I am having an excellent dialogue with some Prolog folks about this > in comp.lang.prolog. One of the rules that define Prolog language is arguments ::= argument | argument "," arguments which is infinitely recursive. Is it invalid? Is Prolog invalid because of this and other infinitely recursive rules? Mikko
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-05-03 04:08 -0700 |
| Message-ID | <b72c8f03-1d5b-49d0-8c5d-e04a7d92978an@googlegroups.com> |
| In reply to | #49548 |
On Tuesday, 3 May 2022 at 10:36:48 UTC+1, Mikko wrote: > On 2022-05-02 16:18:36 +0000, olcott said: > > > It seems to me that all infinitely recursive definitions are invalid > > and I am having an excellent dialogue with some Prolog folks about this > > in comp.lang.prolog. > One of the rules that define Prolog language is > > arguments ::= argument | argument "," arguments > > which is infinitely recursive. Is it invalid? Is Prolog invalid because > of this and other infinitely recursive rules? > Kind of. A Prolog program is a physical object, not a mathematical object, so the recursion has to terminate somewhere. But it might lead you into strange territory if you tried to define the result of passing an ininite argument list to some Prolog.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-05-03 09:33 -0500 |
| Message-ID | <t4reg6$mfk$2@dont-email.me> |
| In reply to | #49549 |
On 5/3/2022 6:08 AM, Malcolm McLean wrote: > On Tuesday, 3 May 2022 at 10:36:48 UTC+1, Mikko wrote: >> On 2022-05-02 16:18:36 +0000, olcott said: >> >>> It seems to me that all infinitely recursive definitions are invalid >>> and I am having an excellent dialogue with some Prolog folks about this >>> in comp.lang.prolog. >> One of the rules that define Prolog language is >> >> arguments ::= argument | argument "," arguments >> >> which is infinitely recursive. Is it invalid? Is Prolog invalid because >> of this and other infinitely recursive rules? >> > Kind of. > A Prolog program is a physical object, not a mathematical object, so > the recursion has to terminate somewhere. > But it might lead you into strange territory if you tried to define the result > of passing an ininite argument list to some Prolog. Even infinitely recursive math expressions are semantically incorrect in that they can never be evaluated. -- 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 | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-05-03 09:41 -0700 |
| Message-ID | <6b7d9204-ab6a-46d8-a3e5-5baab8a28c93n@googlegroups.com> |
| In reply to | #49553 |
On Tuesday, 3 May 2022 at 15:33:45 UTC+1, olcott wrote: > On 5/3/2022 6:08 AM, Malcolm McLean wrote: > > On Tuesday, 3 May 2022 at 10:36:48 UTC+1, Mikko wrote: > >> On 2022-05-02 16:18:36 +0000, olcott said: > >> > >>> It seems to me that all infinitely recursive definitions are invalid > >>> and I am having an excellent dialogue with some Prolog folks about this > >>> in comp.lang.prolog. > >> One of the rules that define Prolog language is > >> > >> arguments ::= argument | argument "," arguments > >> > >> which is infinitely recursive. Is it invalid? Is Prolog invalid because > >> of this and other infinitely recursive rules? > >> > > Kind of. > > A Prolog program is a physical object, not a mathematical object, so > > the recursion has to terminate somewhere. > > But it might lead you into strange territory if you tried to define the result > > of passing an ininite argument list to some Prolog. > Even infinitely recursive math expressions are semantically incorrect in > that they can never be evaluated. > What's e ^ (PI * i) ? e is Euler's number. PI is the ratio of the diameter of a circle to its circumference i is the square root of -1.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-05-03 11:57 -0500 |
| Message-ID | <t4rmu5$mdj$1@dont-email.me> |
| In reply to | #49566 |
On 5/3/2022 11:41 AM, Malcolm McLean wrote: > On Tuesday, 3 May 2022 at 15:33:45 UTC+1, olcott wrote: >> On 5/3/2022 6:08 AM, Malcolm McLean wrote: >>> On Tuesday, 3 May 2022 at 10:36:48 UTC+1, Mikko wrote: >>>> On 2022-05-02 16:18:36 +0000, olcott said: >>>> >>>>> It seems to me that all infinitely recursive definitions are invalid >>>>> and I am having an excellent dialogue with some Prolog folks about this >>>>> in comp.lang.prolog. >>>> One of the rules that define Prolog language is >>>> >>>> arguments ::= argument | argument "," arguments >>>> >>>> which is infinitely recursive. Is it invalid? Is Prolog invalid because >>>> of this and other infinitely recursive rules? >>>> >>> Kind of. >>> A Prolog program is a physical object, not a mathematical object, so >>> the recursion has to terminate somewhere. >>> But it might lead you into strange territory if you tried to define the result >>> of passing an ininite argument list to some Prolog. >> Even infinitely recursive math expressions are semantically incorrect in >> that they can never be evaluated. >> > What's e ^ (PI * i) ? > > e is Euler's number. > PI is the ratio of the diameter of a circle to its circumference > i is the square root of -1. > I don't buy into the whole imaginary numbers game. We could imagine that 2 + 3 = 17 and call that an imaginary sum. That is not an infinitely recursive math expression. It is a math expression that can be evaluated on the basis of the numerical constants specified by e, PI and i. That it cannot be resolved to a finite string of digits does not make it invalid. -- 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 | Jeff Barnett <jbb@notatt.com> |
|---|---|
| Date | 2022-05-03 12:53 -0600 |
| Message-ID | <t4rtms$k49$1@dont-email.me> |
| In reply to | #49568 |
On 5/3/2022 10:57 AM, olcott wrote: > On 5/3/2022 11:41 AM, Malcolm McLean wrote: >> On Tuesday, 3 May 2022 at 15:33:45 UTC+1, olcott wrote: >>> On 5/3/2022 6:08 AM, Malcolm McLean wrote: >>>> On Tuesday, 3 May 2022 at 10:36:48 UTC+1, Mikko wrote: >>>>> On 2022-05-02 16:18:36 +0000, olcott said: >>>>> >>>>>> It seems to me that all infinitely recursive definitions are invalid >>>>>> and I am having an excellent dialogue with some Prolog folks about >>>>>> this >>>>>> in comp.lang.prolog. >>>>> One of the rules that define Prolog language is >>>>> >>>>> arguments ::= argument | argument "," arguments >>>>> >>>>> which is infinitely recursive. Is it invalid? Is Prolog invalid >>>>> because >>>>> of this and other infinitely recursive rules? >>>>> >>>> Kind of. >>>> A Prolog program is a physical object, not a mathematical object, so >>>> the recursion has to terminate somewhere. >>>> But it might lead you into strange territory if you tried to define >>>> the result >>>> of passing an ininite argument list to some Prolog. > >>> Even infinitely recursive math expressions are semantically incorrect in >>> that they can never be evaluated. >>> >> What's e ^ (PI * i) ? >> >> e is Euler's number. >> PI is the ratio of the diameter of a circle to its circumference >> i is the square root of -1. >> > > I don't buy into the whole imaginary numbers game. > We could imagine that 2 + 3 = 17 and call that an imaginary sum. > > That is not an infinitely recursive math expression. > It is a math expression that can be evaluated on the basis of the > numerical constants specified by e, PI and i. That it cannot be resolved > to a finite string of digits does not make it invalid. I first saw that expression in high school. It was claimed to be a key part of what was claimed to be the world's "most intriguing" formula. Too bad you missed math in high school and the rest of your life. [Try Google maybe you'll find it and can copy and paste some nonsense about it. SQUAWK Polly want a cracker?] -- Jeff Barnett
[toc] | [prev] | [next] | [standalone]
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2022-05-03 13:02 -0600 |
| Message-ID | <t4ru7r$n2b$1@dont-email.me> |
| In reply to | #49585 |
On 2022-05-03 12:53, Jeff Barnett wrote: > I first saw that expression in high school. It was claimed to be a key > part of what was claimed to be the world's "most intriguing" formula. > Too bad you missed math in high school and the rest of your life. [Try > Google maybe you'll find it and can copy and paste some nonsense about > it. SQUAWK Polly want a cracker?] An ASCII formula might be hard to google. Euler's Identity is probably a better search term. https://en.wikipedia.org/wiki/Euler%27s_identity André -- To email remove 'invalid' & replace 'gm' with well known Google mail service.
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.theory
csiph-web