Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #49891 > unrolled thread
| Started by | olcott <polcott2@gmail.com> |
|---|---|
| First post | 2022-05-06 15:53 -0500 |
| Last post | 2022-05-09 10:35 -0500 |
| Articles | 20 on this page of 194 — 10 participants |
Back to article view | Back to comp.theory
Validating that the implementation meets the spec for TM transition function olcott <polcott2@gmail.com> - 2022-05-06 15:53 -0500
Re: Validating that the implementation meets the spec for TM transition function Mr Flibble <flibble@reddwarf.jmc> - 2022-05-06 22:08 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <polcott2@gmail.com> - 2022-05-06 16:25 -0500
Re: Validating that the implementation meets the spec for TM transition function Mr Flibble <flibble@reddwarf.jmc> - 2022-05-06 22:29 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <polcott2@gmail.com> - 2022-05-06 17:08 -0500
Re: Validating that the implementation meets the spec for TM transition function Mr Flibble <flibble@reddwarf.jmc> - 2022-05-07 13:02 +0100
Re: Validating that the implementation meets the spec for TM transition function Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-06 14:41 -0700
Re: Validating that the implementation meets the spec for TM transition function olcott <polcott2@gmail.com> - 2022-05-06 17:02 -0500
Re: Validating that the implementation meets the spec for TM transition function Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-06 15:36 -0700
Re: Validating that the implementation meets the spec for TM transition function olcott <polcott2@gmail.com> - 2022-05-06 17:54 -0500
Re: Validating that the implementation meets the spec for TM transition function Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-05-07 00:39 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <polcott2@gmail.com> - 2022-05-06 18:54 -0500
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-07 01:54 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <polcott2@gmail.com> - 2022-05-06 20:05 -0500
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-07 23:21 +0100
Re: Validating that the implementation meets the spec for TM transition function Jeff Barnett <jbb@notatt.com> - 2022-05-07 19:57 -0600
Re: Validating that the implementation meets the spec for TM transition function Richard Damon <Richard@Damon-Family.org> - 2022-05-08 07:34 -0400
Re: Validating that the implementation meets the spec for TM transition function Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-08 05:11 -0700
Re: Validating that the implementation meets the spec for TM transition function Richard Damon <Richard@Damon-Family.org> - 2022-05-08 14:20 -0400
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-08 19:59 +0100
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-09 03:14 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-08 22:39 -0500
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-09 12:36 +0100
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-08 14:44 +0100
Re: Validating that the implementation meets the spec for TM transition function Jeff Barnett <jbb@notatt.com> - 2022-05-08 11:08 -0600
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-08 19:27 +0100
Re: Validating that the implementation meets the spec for TM transition function Richard Damon <Richard@Damon-Family.org> - 2022-05-08 15:22 -0400
Re: Validating that the implementation meets the spec for TM transition function Mr Flibble <flibble@reddwarf.jmc> - 2022-05-08 20:30 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-09 10:53 -0500
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-09 23:08 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-09 17:32 -0500
Re: Validating that the implementation meets the spec for TM transition function Richard Damon <Richard@Damon-Family.org> - 2022-05-09 20:31 -0400
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-10 01:37 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-09 20:29 -0500
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-10 11:35 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape] olcott <NoOne@NoWhere.com> - 2022-05-10 19:12 -0500
Re: Validating that the implementation meets the spec for TM transition function Jeff Barnett <jbb@notatt.com> - 2022-05-08 14:51 -0600
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-09 10:18 -0500
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-09 23:14 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-09 17:42 -0500
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-10 01:13 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-09 20:28 -0500
Re: Validating that the implementation meets the spec for TM transition function Richard Damon <Richard@Damon-Family.org> - 2022-05-09 23:34 -0400
Re: Validating that the implementation meets the spec for TM transition function Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-10 00:24 -0700
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-10 11:31 +0100
Re: Validating that the implementation meets the spec for TM transition function Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-10 03:46 -0700
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-10 12:23 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-10 06:53 -0500
Re: Validating that the implementation meets the spec for TM transition function Richard Damon <Richard@Damon-Family.org> - 2022-05-10 08:01 -0400
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-10 16:41 +0100
Re: Validating that the implementation meets the spec for TM transition function Jeff Barnett <jbb@notatt.com> - 2022-05-10 11:56 -0600
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-10 19:43 -0500
Re: Validating that the implementation meets the spec for TM transition function Jeff Barnett <jbb@notatt.com> - 2022-05-10 20:49 -0600
Re: Validating that the implementation meets the spec for TM transition function Mr Flibble <flibble@reddwarf.jmc> - 2022-05-10 19:01 +0100
Re: Validating that the implementation meets the spec for TM transition function "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-05-10 11:59 -0700
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-10 19:04 -0500
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-11 01:42 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-10 20:12 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-05-11 03:05 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-10 21:14 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-11 02:19 -0700
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-11 08:54 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-05-11 16:27 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-11 10:36 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-05-11 16:49 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-11 14:30 -0700
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-11 16:38 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-05-12 00:01 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-11 19:05 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-05-12 04:03 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-11 22:29 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-11 22:37 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-12 15:02 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-05-12 19:03 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-12 19:30 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-12 14:23 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Richard Damon <Richard@Damon-Family.org> - 2022-05-12 19:19 -0400
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-05-13 01:02 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Jeff Barnett <jbb@notatt.com> - 2022-05-11 23:13 -0600
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-12 00:43 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-11 04:02 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-10 22:07 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-11 13:40 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-11 09:02 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-05-11 16:09 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-11 10:29 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-11 20:35 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-11 15:12 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-11 22:54 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-11 17:02 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-12 02:00 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-11 20:37 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-12 02:49 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-11 21:49 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-12 14:45 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-12 10:31 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-12 21:20 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-12 15:33 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mr Flibble <flibble@reddwarf.jmc> - 2022-05-12 21:36 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-12 16:28 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mr Flibble <flibble@reddwarf.jmc> - 2022-05-12 22:33 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-12 22:02 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-12 16:14 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 00:18 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-12 18:22 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 01:10 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-12 19:58 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 02:54 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Richard Damon <Richard@Damon-Family.org> - 2022-05-12 22:09 -0400
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-12 21:41 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mikko <mikko.levanto@iki.fi> - 2022-05-13 10:01 +0300
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 10:57 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mikko <mikko.levanto@iki.fi> - 2022-05-13 19:06 +0300
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 11:54 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 13:38 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 11:07 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 17:14 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 12:03 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 18:09 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 12:15 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 17:26 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 12:07 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 19:45 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 13:57 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 15:04 -0400
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 14:15 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 15:40 -0400
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 14:58 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 16:24 -0400
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 15:33 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 17:25 -0400
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 16:48 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 18:05 -0400
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 20:12 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 14:28 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 21:58 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 16:12 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 23:57 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 17:59 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-14 01:00 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 19:09 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-14 01:21 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-17 13:17 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-14 01:54 -0700
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-14 04:13 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-14 03:30 -0700
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-14 08:51 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-14 11:38 -0700
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-14 13:54 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-14 13:15 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-14 11:37 -0700
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-05-14 19:47 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-14 20:15 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-14 12:52 -0700
Re: Validating that the implementation meets the spec for TM transition function [ unlimited scalability ] olcott <NoOne@NoWhere.com> - 2022-05-13 16:43 -0500
Re: Validating that the implementation meets the spec for TM transition function [ unlimited scalability ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 23:58 +0100
Re: Validating that the implementation meets the spec for TM transition function [ unlimited scalability ] olcott <NoOne@NoWhere.com> - 2022-05-13 18:03 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Jeff Barnett <jbb@notatt.com> - 2022-05-13 15:06 -0600
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 16:16 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Jeff Barnett <jbb@notatt.com> - 2022-05-13 17:48 -0600
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 19:06 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Jeff Barnett <jbb@notatt.com> - 2022-05-13 19:58 -0600
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 22:39 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Jeff Barnett <jbb@notatt.com> - 2022-05-13 19:48 -0600
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 11:00 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 12:08 -0400
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 17:27 +0100
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] olcott <NoOne@NoWhere.com> - 2022-05-13 12:10 -0500
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 13:20 -0400
Re: Validating that the implementation meets the spec for TM transition function [ best tape ] Richard Damon <Richard@Damon-Family.org> - 2022-05-11 22:07 -0400
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-10 21:06 -0500
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-11 00:11 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-10 19:41 -0500
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-10 06:53 -0500
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-07 21:04 -0500
Re: Validating that the implementation meets the spec for TM transition function Richard Damon <Richard@Damon-Family.org> - 2022-05-08 07:30 -0400
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-08 14:46 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-09 10:19 -0500
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-07 01:22 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <polcott2@gmail.com> - 2022-05-06 19:38 -0500
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-07 02:01 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <polcott2@gmail.com> - 2022-05-06 20:22 -0500
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-07 23:30 +0100
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-07 02:04 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <polcott2@gmail.com> - 2022-05-06 20:26 -0500
Re: Validating that the implementation meets the spec for TM transition function Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-07 05:00 -0700
Re: Validating that the implementation meets the spec for TM transition function Ben <ben.usenet@bsb.me.uk> - 2022-05-07 23:31 +0100
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-07 18:36 -0500
Re: Validating that the implementation meets the spec for TM transition function Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-08 02:39 -0700
Re: Validating that the implementation meets the spec for TM transition function [ priorities ] olcott <NoOne@NoWhere.com> - 2022-05-08 17:21 -0500
Re: Validating that the implementation meets the spec for TM transition function Mikko <mikko.levanto@iki.fi> - 2022-05-07 11:06 +0300
Re: Validating that the implementation meets the spec for TM transition function olcott <polcott2@gmail.com> - 2022-05-07 11:14 -0500
Re: Validating that the implementation meets the spec for TM transition function Mikko <mikko.levanto@iki.fi> - 2022-05-08 11:57 +0300
Re: Validating that the implementation meets the spec for TM transition function olcott <NoOne@NoWhere.com> - 2022-05-09 10:35 -0500
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-12 22:33 +0100 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <20220512223343.000062bd@reddwarf.jmc> |
| In reply to | #50303 |
On Thu, 12 May 2022 16:28:30 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 5/12/2022 3:36 PM, Mr Flibble wrote:
> > On Thu, 12 May 2022 15:33:11 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 5/12/2022 3:20 PM, Ben wrote:
> >>> olcott <NoOne@NoWhere.com> writes:
> >>>
> >>>> On 5/12/2022 8:45 AM, Ben wrote:
> >>>>> olcott <NoOne@NoWhere.com> writes:
> >>>>>
> >>>>>> On 5/11/2022 8:49 PM, Ben wrote:
> >>>>>>> olcott <NoOne@NoWhere.com> writes:
> >>>>>>>
> >>>>>>>> On 5/11/2022 8:00 PM, Ben wrote:
> >>>>>>>
> >>>>>>>>> Can't you even post the code for the function that moves
> >>>>>>>>> and/or updates the tape? Surely that part is now written?
> >>>>>>>>> That way we'd know what data structure you are using...
> >>>>>>>>
> >>>>>>>> struct Tape
> >>>>>>>> {
> >>>>>>>> unsigned int Tape_Head;
> >>>>>>>> std::vector<unsigned char> Left;
> >>>>>>>> std::vector<unsigned char> Right;
> >>>>>>>> unsigned int move_left();
> >>>>>>>> unsigned int move_right();
> >>>>>>>> };
> >>>>>>>>
> >>>>>>>> The part of mapping Tape_Head to a location in Left or Right
> >>>>>>>> needs more desk checking before I will implement it.
> >>>>>>> How long is that going to take?
> >>>>>>
> >>>>>> Less than 8 labor hours, maybe 2 labor hours.
> >>>>> For just the tape? Surely not. I wanted to resolve what data
> >>>>> structure you are actually gong to be using.
> >>>>>
> >>>>>> I only work on it for 5 minutes every 2 hours.
> >>>>> So may be another 12 days. Oh well, I'll see if I can apply the
> >>>>> "tying the knot" trick to my Haskell code...
> >>>>
> >>>> I have it almost done.
> >>>
> >>> Not even the two tape movement functions?
> >>>
> >>>> I staid up late working on it.
> >>>> I got very enthused. This is lots of fun.
> >>>
> >>> A bit of programming is always fun.
> >>>
> >>>> It is also essentially basically a significant improvement to how
> >>>> std::deque could be implemented.
> >>>
> >>> This is ambiguous. It is easy to find an improvement over how
> >>> std::deque /could/ be implemented (since it /could/ be implemented
> >>> badly), but, on the other hand, I am sure you don't know all the
> >>> ways std::deque /could/ be implemented so you can't know you have
> >>> an improvement of that sort.
> >>>
> >>
> >> The Tape_Type is almost done. It is ideal for a two-way TM tape. It
> >> has the key benefit of being able to grow on both ends.
> >>
> >> Unlike the messy overhead of the conventional std::deque
> >> implementation it has all of the efficiently of std:vector because
> >> it is implemented as a pair of std::vectors.
> >
> > You cannot meet the complexity and element referential integrity
> > guarantees that std::deque offers with a pair of std::vectors. You
> > are obviously a C++ n00b.
> >
> > /Flibble
> >
>
> It has the same Big-O complexity (with less overhead)
> As far as referential integrity std::deque does not do very well.
> https://www.geeksforgeeks.org/iterator-invalidation-cpp/
You are wrong on both counts:
* referential integrity and iterator invalidation are different
things: when you add or remove elements to either end of a
std::deque iterators are indeed invalidated however references to
existing elements remain valid
* If you do 1000 push_fronts followed by 1000 push_backs followed by
1000 pop_fronts all is good however your next pop_front will have
linear complexity, O(n), as it will necessitate removal of the first
element of the right std::vector.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-12 22:02 +0100 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <87tu9u31nv.fsf@bsb.me.uk> |
| In reply to | #50299 |
olcott <NoOne@NoWhere.com> writes: > The Tape_Type is almost done. How complicated are you making it? The two functions that would clear up, once and for all, what you are really doing should be only a two or three lines. > Left for growing left and Right for growing right. int Tape_Head >= 0 > points to elements of Right, in order. > > int Tape_Head < 0 points to elements of Left, such that -1 points to > Left[0] et cetera. I see. So you are not using two stacks. And what you are implementing is not a deque, though using two arrays is a standard what to implement a deque. I'm curious why this is taking so long. The tape functions will be a couple of lines... -- 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-12 16:14 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <X9mdnVTySoUr5eD_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #50301 |
On 5/12/2022 4:02 PM, Ben wrote: > olcott <NoOne@NoWhere.com> writes: > >> The Tape_Type is almost done. > > How complicated are you making it? The two functions that would clear > up, once and for all, what you are really doing should be only a two or > three lines. > >> Left for growing left and Right for growing right. int Tape_Head >= 0 >> points to elements of Right, in order. >> >> int Tape_Head < 0 points to elements of Left, such that -1 points to >> Left[0] et cetera. > > I see. So you are not using two stacks. And what you are implementing > is not a deque, though using two arrays is a standard what to implement > a deque. > I am implementing a faster, smaller, cleaner, and simpler std::deque > I'm curious why this is taking so long. The tape functions will be a > couple of lines... > I hate to define code that is sub-optimal. It has all of these features of a std::deque deque (usually pronounced like "deck") is an irregular acronym of double-ended queue. Double-ended queues are sequence containers with dynamic sizes that can be expanded or contracted on both ends (either its front or its back). Specific libraries may implement deques in different ways, generally as some form of dynamic array. But in any case, they allow for the individual elements to be accessed directly through random access iterators, with storage handled automatically by expanding and contracting the container as needed. Therefore, they provide a functionality similar to vectors, but with efficient insertion and deletion of elements also at the beginning of the sequence, and not only at its end. https://www.cplusplus.com/reference/deque/deque/ I think that I have it nearly done now. It needs more testing, code cleanup and simplification. -- 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-13 00:18 +0100 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <874k1u2vc7.fsf@bsb.me.uk> |
| In reply to | #50302 |
olcott <NoOne@NoWhere.com> writes: > On 5/12/2022 4:02 PM, Ben wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> The Tape_Type is almost done. >> How complicated are you making it? The two functions that would clear >> up, once and for all, what you are really doing should be only a two or >> three lines. >> >>> Left for growing left and Right for growing right. int Tape_Head >= 0 >>> points to elements of Right, in order. >>> >>> int Tape_Head < 0 points to elements of Left, such that -1 points to >>> Left[0] et cetera. >> >> I see. So you are not using two stacks. And what you are implementing >> is not a deque, though using two arrays is a standard what to implement >> a deque. > > I am implementing a faster, smaller, cleaner, and simpler std::deque From your description you are not implementing a deque at all, though as I say, using two arrays is one well-known way to do that. If you decide to make it an actual deque, what will it be faster, smaller, cleaner and simpler than? Surely it will be just about the same speed, no smaller, no cleaner and no simpler than any other deque implemented with two arrays. >> I'm curious why this is taking so long. The tape functions will be a >> couple of lines... > > I hate to define code that is sub-optimal. Since you are not a data structures or algorithms expert, how can you possibly tell what is or is not sub-optimal? > I think that I have it nearly done now. > It needs more testing, code cleanup and simplification. This is beginning to look like procrastination. First you have the mountain to climb of reading the documentation for the TM interpreter you'd chosen. But then you decided you had to implement it all yourself. And then you got sidetracked by the two stacks idea. And now you don't like to write code if it's sub-optimal (a hopelessly indeterminate measure). Software engineering is about getting the job done on time and in budget. I've written four interpreters since you started. I'm quite pleased with the latest Haskell one in that it builds an actual linked graph of states, something that's not trivial in a functional language. It runs at 30 million "typical" transitions a second compared with 200 for the C++ one. That's surprisingly in the same ball park. The Glasgow Haskell compiler is a magnificent achievement. -- 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-12 18:22 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <2e-dnTfLY8FJC-D_nZ2dnUU7_8xh4p2d@giganews.com> |
| In reply to | #50314 |
On 5/12/2022 6:18 PM, Ben wrote: > olcott <NoOne@NoWhere.com> writes: > >> On 5/12/2022 4:02 PM, Ben wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> The Tape_Type is almost done. >>> How complicated are you making it? The two functions that would clear >>> up, once and for all, what you are really doing should be only a two or >>> three lines. >>> >>>> Left for growing left and Right for growing right. int Tape_Head >= 0 >>>> points to elements of Right, in order. >>>> >>>> int Tape_Head < 0 points to elements of Left, such that -1 points to >>>> Left[0] et cetera. >>> >>> I see. So you are not using two stacks. And what you are implementing >>> is not a deque, though using two arrays is a standard what to implement >>> a deque. >> >> I am implementing a faster, smaller, cleaner, and simpler std::deque > > From your description you are not implementing a deque at all, though as > I say, using two arrays is one well-known way to do that. > > If you decide to make it an actual deque, what will it be faster, > smaller, cleaner and simpler than? Surely it will be just about the > same speed, no smaller, no cleaner and no simpler than any other deque > implemented with two arrays. > >>> I'm curious why this is taking so long. The tape functions will be a >>> couple of lines... >> >> I hate to define code that is sub-optimal. > > Since you are not a data structures or algorithms expert, how can you > possibly tell what is or is not sub-optimal? > >> I think that I have it nearly done now. >> It needs more testing, code cleanup and simplification. > > This is beginning to look like procrastination. First you have the > mountain to climb of reading the documentation for the TM interpreter > you'd chosen. But then you decided you had to implement it all > yourself. And then you got sidetracked by the two stacks idea. And now > you don't like to write code if it's sub-optimal (a hopelessly > indeterminate measure). > > Software engineering is about getting the job done on time and in > budget. I've written four interpreters since you started. I'm quite > pleased with the latest Haskell one in that it builds an actual linked > graph of states, something that's not trivial in a functional language. > It runs at 30 million "typical" transitions a second compared with 200 > for the C++ one. That's surprisingly in the same ball park. The > Glasgow Haskell compiler is a magnificent achievement. > Its done see my new post. -- 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-13 01:10 +0100 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <87pmki1edk.fsf@bsb.me.uk> |
| In reply to | #50318 |
olcott <NoOne@NoWhere.com> writes: > Its done see my new post. Apart from the bug/typo it's a perfectly good way to implement a TM tape. It's not a deque though. -- 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-12 19:58 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <MeOdncVeZaeHMOD_nZ2dnUU7_8xh4p2d@giganews.com> |
| In reply to | #50330 |
On 5/12/2022 7:10 PM, Ben wrote: > olcott <NoOne@NoWhere.com> writes: > >> Its done see my new post. > > Apart from the bug/typo it's a perfectly good way to implement a TM > tape. It's not a deque though. > I think that it is a better way to implement a std::deque. It can be extended to a full deque. -- 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-13 02:54 +0100 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <87wneqyz6w.fsf@bsb.me.uk> |
| In reply to | #50336 |
olcott <NoOne@NoWhere.com> writes: > On 5/12/2022 7:10 PM, Ben wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> Its done see my new post. >> Apart from the bug/typo it's a perfectly good way to implement a TM >> tape. It's not a deque though. > > I think that it is a better way to implement a std::deque. Better than what? There are lots of ways to implement a deque and they all have advantages and disadvantages. Of course, since you have not implemented any of the deque interface, I can't tell what method might be thinking of using. Other than it will probably use two vectors. > It can be extended to a full deque. It implements exactly none of the functions that make a deque a deque. Of course is could be extended to be a deque by (a) implementing all of the member function that a deque should provide and, (b) removing all of the functions that a deque should not provide. -- 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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-05-12 22:09 -0400 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <_4jfK.2551$x1Wf.724@fx10.iad> |
| In reply to | #50348 |
On 5/12/22 9:54 PM, Ben wrote: > olcott <NoOne@NoWhere.com> writes: > >> On 5/12/2022 7:10 PM, Ben wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> Its done see my new post. >>> Apart from the bug/typo it's a perfectly good way to implement a TM >>> tape. It's not a deque though. >> >> I think that it is a better way to implement a std::deque. > > Better than what? There are lots of ways to implement a deque and they > all have advantages and disadvantages. Of course, since you have not > implemented any of the deque interface, I can't tell what method might > be thinking of using. Other than it will probably use two vectors. > >> It can be extended to a full deque. > > It implements exactly none of the functions that make a deque a deque. > > Of course is could be extended to be a deque by (a) implementing all of > the member function that a deque should provide and, (b) removing all of > the functions that a deque should not provide. > Which just shows Peter's problem with understanding REQUIREENTS. Apparently a LONG standing problem, since he didn't get his CS degree due to failing to meet some of the "minor" requirements. This failing colors so much of his work.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-12 21:41 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <IsSdnaQ2qJzQWOD_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #50348 |
On 5/12/2022 8:54 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 5/12/2022 7:10 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> Its done see my new post.
>>> Apart from the bug/typo it's a perfectly good way to implement a TM
>>> tape. It's not a deque though.
>>
>> I think that it is a better way to implement a std::deque.
>
> Better than what?
The complex mess of the conventional way to implement std::deque
> There are lots of ways to implement a deque and they
> all have advantages and disadvantages.
If you get maximum
(a) simplicity (b) speed and (c) minimum space what more could you want?
> Of course, since you have not
> implemented any of the deque interface, I can't tell what method might
> be thinking of using. Other than it will probably use two vectors.
>
public:
tape_element& front( ) { return Left.back(); }
tape_element& back() { return Right.back(); }
void pop_front() { Left.pop_back(); }
void pop_back() { Right.pop_back(); }
void push_front(tape_element& E) { Left.push_back(E); }
void push_back(tape_element& E) { Right.push_back(E); }
void reserve(unsigned int N)
{ Left.reserve(N); Right.reserve(N); }
>> It can be extended to a full deque.
>
> It implements exactly none of the functions that make a deque a deque.
>
> Of course is could be extended to be a deque by (a) implementing all of
> the member function that a deque should provide and, (b) removing all of
> the functions that a deque should not provide.
>
--
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-13 10:01 +0300 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <t5kvo6$vr1$1@dont-email.me> |
| In reply to | #50352 |
On 2022-05-13 02:41:15 +0000, olcott said:
> On 5/12/2022 8:54 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 5/12/2022 7:10 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> Its done see my new post.
>>>> Apart from the bug/typo it's a perfectly good way to implement a TM
>>>> tape. It's not a deque though.
>>>
>>> I think that it is a better way to implement a std::deque.
>>
>> Better than what?
>
> The complex mess of the conventional way to implement std::deque
Every implementation of a deque is more complex than you need because
a deque and in particular std::deque provides functionality that you
don't need. They also lack functionality that you do need, forcing
additional complexity elsewhere in your code. The missing part is the
tape head position.
...
> public:
> tape_element& front( ) { return Left.back(); }
> tape_element& back() { return Right.back(); }
> void pop_front() { Left.pop_back(); }
> void pop_back() { Right.pop_back(); }
> void push_front(tape_element& E) { Left.push_back(E); }
> void push_back(tape_element& E) { Right.push_back(E); }
> void reserve(unsigned int N)
> { Left.reserve(N); Right.reserve(N); }
You only need three functions:
tape_symbol current_symbol()
void write_symbol(tape_symbol)
void move(direction)
Anything more complex than this would be like killing a fly
with a cannon.
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-13 10:57 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <zdmdnV_tirtr4uP_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #50354 |
On 5/13/2022 2:01 AM, Mikko wrote:
> On 2022-05-13 02:41:15 +0000, olcott said:
>
>> On 5/12/2022 8:54 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 5/12/2022 7:10 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> Its done see my new post.
>>>>> Apart from the bug/typo it's a perfectly good way to implement a TM
>>>>> tape. It's not a deque though.
>>>>
>>>> I think that it is a better way to implement a std::deque.
>>>
>>> Better than what?
>>
>> The complex mess of the conventional way to implement std::deque
>
> Every implementation of a deque is more complex than you need because
> a deque and in particular std::deque provides functionality that you
> don't need. They also lack functionality that you do need, forcing
> additional complexity elsewhere in your code. The missing part is the
> tape head position.
>
// Tape_Type implements a two-way Turing machine tape.
// Right contains Tape_Head >= 0 values (right expansion)
// Left contains Tape_Head < 0 values (left expansion)
//
// Grows with Right.push_back() as Tape_Head increases above 0.
// Grows with Left.push_back() as Tape_Head decreases below 0.
//
// Tape_Type has functionality very simular to std::deque
// yet implements this functionality much more simply.
// This saves time and space.
//
class Tape_Type
{
public:
typedef unsigned char tape_element;
private:
int Tape_Head = 0; // Can be negative
std::vector<tape_element> Left; // Stores left expansion
std::vector<tape_element> Right; // Stores right expansion
> ...
>
>> public:
>> tape_element& front( ) { return Left.back(); }
>> tape_element& back() { return Right.back(); }
>> void pop_front() { Left.pop_back(); }
>> void pop_back() { Right.pop_back(); }
>> void push_front(tape_element& E) { Left.push_back(E); }
>> void push_back(tape_element& E) { Right.push_back(E); }
>> void reserve(unsigned int N)
>> { Left.reserve(N); Right.reserve(N); }
>
> You only need three functions:
>
> tape_symbol current_symbol()
> void write_symbol(tape_symbol)
> void move(direction)
>
> Anything more complex than this would be like killing a fly
> with a cannon.
>
> Mikko
I took an hour or so to add some std::deque member functions to prove
that they could be added cleanly.
void Write(tape_element Y){ (*this)[Tape_Head] = Y; };
tape_element Read() { return (*this)[Tape_Head]; };
void move_left()
{
Tape_Head--;
int Left_Index = ((Tape_Head * -1) -1);
if (Left_Index == Left.size())
Left.push_back('_');
}
void move_right()
{
Tape_Head++;
if (Tape_Head == Right.size())
Right.push_back('_');
}
--
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-13 19:06 +0300 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <t5lvmn$5b2$1@dont-email.me> |
| In reply to | #50368 |
On 2022-05-13 15:57:41 +0000, olcott said:
> void Write(tape_element Y){ (*this)[Tape_Head] = Y; };
> tape_element Read() { return (*this)[Tape_Head]; };
>
> void move_left()
> {
> Tape_Head--;
> int Left_Index = ((Tape_Head * -1) -1);
> if (Left_Index == Left.size())
> Left.push_back('_');
> }
>
> void move_right()
> {
> Tape_Head++;
> if (Tape_Head == Right.size())
> Right.push_back('_');
> }
Looks good but needs testing.
Mikko
[toc] | [prev] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-13 11:54 +0100 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <87y1z5zoqu.fsf@bsb.me.uk> |
| In reply to | #50352 |
olcott <NoOne@NoWhere.com> writes:
> On 5/12/2022 8:54 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 5/12/2022 7:10 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> Its done see my new post.
>>>> Apart from the bug/typo it's a perfectly good way to implement a TM
>>>> tape. It's not a deque though.
>>>
>>> I think that it is a better way to implement a std::deque.
>> Better than what?
>
> The complex mess of the conventional way to implement std::deque
>
>> There are lots of ways to implement a deque and they
>> all have advantages and disadvantages.
>
> If you get maximum
> (a) simplicity (b) speed and (c) minimum space what more could you
> want?
Correctness.
>> Of course, since you have not
>> implemented any of the deque interface, I can't tell what method might
>> be thinking of using. Other than it will probably use two vectors.
>>
>
> public:
> tape_element& front( ) { return Left.back(); }
> tape_element& back() { return Right.back(); }
> void pop_front() { Left.pop_back(); }
> void pop_back() { Right.pop_back(); }
> void push_front(tape_element& E) { Left.push_back(E); }
> void push_back(tape_element& E) { Right.push_back(E); }
> void reserve(unsigned int N)
> { Left.reserve(N); Right.reserve(N); }
This is not correct. Please read a book. Or at least write a test
program and compare with std::deque.
--
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 | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-13 13:38 +0100 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <20220513133840.0000732f@reddwarf.jmc> |
| In reply to | #50359 |
On Fri, 13 May 2022 11:54:49 +0100
Ben <ben.usenet@bsb.me.uk> wrote:
> olcott <NoOne@NoWhere.com> writes:
>
> > On 5/12/2022 8:54 PM, Ben wrote:
> >> olcott <NoOne@NoWhere.com> writes:
> >>
> >>> On 5/12/2022 7:10 PM, Ben wrote:
> >>>> olcott <NoOne@NoWhere.com> writes:
> >>>>
> >>>>> Its done see my new post.
> >>>> Apart from the bug/typo it's a perfectly good way to implement a
> >>>> TM tape. It's not a deque though.
> >>>
> >>> I think that it is a better way to implement a std::deque.
> >> Better than what?
> >
> > The complex mess of the conventional way to implement std::deque
> >
> >> There are lots of ways to implement a deque and they
> >> all have advantages and disadvantages.
> >
> > If you get maximum
> > (a) simplicity (b) speed and (c) minimum space what more could you
> > want?
>
> Correctness.
>
> >> Of course, since you have not
> >> implemented any of the deque interface, I can't tell what method
> >> might be thinking of using. Other than it will probably use two
> >> vectors.
> >
> > public:
> > tape_element& front( ) { return Left.back(); }
> > tape_element& back() { return Right.back(); }
> > void pop_front() { Left.pop_back(); }
> > void pop_back() { Right.pop_back(); }
> > void push_front(tape_element& E) { Left.push_back(E); }
> > void push_back(tape_element& E) { Right.push_back(E); }
> > void reserve(unsigned int N)
> > { Left.reserve(N); Right.reserve(N); }
>
> This is not correct. Please read a book. Or at least write a test
> program and compare with std::deque.
Even if we ignore complexity requirements and element reference
stability it is still wrong: what happens if `Left` is empty, `Right` is
non-empty and `pop_front` is called? It simply does not conform to
the std::deque interface.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-13 11:07 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <U8ydnRBPtq-gH-P_nZ2dnUU7_8xh4p2d@giganews.com> |
| In reply to | #50363 |
On 5/13/2022 7:38 AM, Mr Flibble wrote:
> On Fri, 13 May 2022 11:54:49 +0100
> Ben <ben.usenet@bsb.me.uk> wrote:
>
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 5/12/2022 8:54 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 5/12/2022 7:10 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> Its done see my new post.
>>>>>> Apart from the bug/typo it's a perfectly good way to implement a
>>>>>> TM tape. It's not a deque though.
>>>>>
>>>>> I think that it is a better way to implement a std::deque.
>>>> Better than what?
>>>
>>> The complex mess of the conventional way to implement std::deque
>>>
>>>> There are lots of ways to implement a deque and they
>>>> all have advantages and disadvantages.
>>>
>>> If you get maximum
>>> (a) simplicity (b) speed and (c) minimum space what more could you
>>> want?
>>
>> Correctness.
>>
>>>> Of course, since you have not
>>>> implemented any of the deque interface, I can't tell what method
>>>> might be thinking of using. Other than it will probably use two
>>>> vectors.
>>>
>>> public:
>>> tape_element& front( ) { return Left.back(); }
>>> tape_element& back() { return Right.back(); }
>>> void pop_front() { Left.pop_back(); }
>>> void pop_back() { Right.pop_back(); }
>>> void push_front(tape_element& E) { Left.push_back(E); }
>>> void push_back(tape_element& E) { Right.push_back(E); }
>>> void reserve(unsigned int N)
>>> { Left.reserve(N); Right.reserve(N); }
>>
>> This is not correct. Please read a book. Or at least write a test
>> program and compare with std::deque.
>
> Even if we ignore complexity requirements and element reference
> stability it is still wrong: what happens if `Left` is empty, `Right` is
> non-empty and `pop_front` is called? It simply does not conform to
> the std::deque interface.
>
> /Flibble
>
Oh, now I see what Ben was saying.
Simply extend my definition of pop_front() to account for this.
--
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 | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-13 17:14 +0100 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <20220513171452.00007ddd@reddwarf.jmc> |
| In reply to | #50375 |
On Fri, 13 May 2022 11:07:24 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 5/13/2022 7:38 AM, Mr Flibble wrote:
> > On Fri, 13 May 2022 11:54:49 +0100
> > Ben <ben.usenet@bsb.me.uk> wrote:
> >
> >> olcott <NoOne@NoWhere.com> writes:
> >>
> >>> On 5/12/2022 8:54 PM, Ben wrote:
> >>>> olcott <NoOne@NoWhere.com> writes:
> >>>>
> >>>>> On 5/12/2022 7:10 PM, Ben wrote:
> >>>>>> olcott <NoOne@NoWhere.com> writes:
> >>>>>>
> >>>>>>> Its done see my new post.
> >>>>>> Apart from the bug/typo it's a perfectly good way to implement
> >>>>>> a TM tape. It's not a deque though.
> >>>>>
> >>>>> I think that it is a better way to implement a std::deque.
> >>>> Better than what?
> >>>
> >>> The complex mess of the conventional way to implement std::deque
> >>>
> >>>> There are lots of ways to implement a deque and they
> >>>> all have advantages and disadvantages.
> >>>
> >>> If you get maximum
> >>> (a) simplicity (b) speed and (c) minimum space what more could you
> >>> want?
> >>
> >> Correctness.
> >>
> >>>> Of course, since you have not
> >>>> implemented any of the deque interface, I can't tell what method
> >>>> might be thinking of using. Other than it will probably use two
> >>>> vectors.
> >>>
> >>> public:
> >>> tape_element& front( ) { return Left.back(); }
> >>> tape_element& back() { return Right.back(); }
> >>> void pop_front() { Left.pop_back(); }
> >>> void pop_back() { Right.pop_back(); }
> >>> void push_front(tape_element& E) { Left.push_back(E); }
> >>> void push_back(tape_element& E) { Right.push_back(E); }
> >>> void reserve(unsigned int N)
> >>> { Left.reserve(N); Right.reserve(N); }
> >>
> >> This is not correct. Please read a book. Or at least write a test
> >> program and compare with std::deque.
> >
> > Even if we ignore complexity requirements and element reference
> > stability it is still wrong: what happens if `Left` is empty,
> > `Right` is non-empty and `pop_front` is called? It simply does not
> > conform to the std::deque interface.
> >
> > /Flibble
> >
>
> Oh, now I see what Ben was saying.
> Simply extend my definition of pop_front() to account for this.
I will be interested to see how you account for this without
introducing linear, O(n), complexity for that operation.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-13 12:03 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <44CdnVIP0pbtEuP_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #50377 |
On 5/13/2022 11:14 AM, Mr Flibble wrote:
> On Fri, 13 May 2022 11:07:24 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/13/2022 7:38 AM, Mr Flibble wrote:
>>> On Fri, 13 May 2022 11:54:49 +0100
>>> Ben <ben.usenet@bsb.me.uk> wrote:
>>>
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 5/12/2022 8:54 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 5/12/2022 7:10 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> Its done see my new post.
>>>>>>>> Apart from the bug/typo it's a perfectly good way to implement
>>>>>>>> a TM tape. It's not a deque though.
>>>>>>>
>>>>>>> I think that it is a better way to implement a std::deque.
>>>>>> Better than what?
>>>>>
>>>>> The complex mess of the conventional way to implement std::deque
>>>>>
>>>>>> There are lots of ways to implement a deque and they
>>>>>> all have advantages and disadvantages.
>>>>>
>>>>> If you get maximum
>>>>> (a) simplicity (b) speed and (c) minimum space what more could you
>>>>> want?
>>>>
>>>> Correctness.
>>>>
>>>>>> Of course, since you have not
>>>>>> implemented any of the deque interface, I can't tell what method
>>>>>> might be thinking of using. Other than it will probably use two
>>>>>> vectors.
>>>>>
>>>>> public:
>>>>> tape_element& front( ) { return Left.back(); }
>>>>> tape_element& back() { return Right.back(); }
>>>>> void pop_front() { Left.pop_back(); }
>>>>> void pop_back() { Right.pop_back(); }
>>>>> void push_front(tape_element& E) { Left.push_back(E); }
>>>>> void push_back(tape_element& E) { Right.push_back(E); }
>>>>> void reserve(unsigned int N)
>>>>> { Left.reserve(N); Right.reserve(N); }
>>>>
>>>> This is not correct. Please read a book. Or at least write a test
>>>> program and compare with std::deque.
>>>
>>> Even if we ignore complexity requirements and element reference
>>> stability it is still wrong: what happens if `Left` is empty,
>>> `Right` is non-empty and `pop_front` is called? It simply does not
>>> conform to the std::deque interface.
>>>
>>> /Flibble
>>>
>>
>> Oh, now I see what Ben was saying.
>> Simply extend my definition of pop_front() to account for this.
>
> I will be interested to see how you account for this without
> introducing linear, O(n), complexity for that operation.
>
> /Flibble
>
It requires linear, O(n), complexity for that operation.
Tape_Type never needs to do that.
--
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 | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-13 18:09 +0100 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <20220513180900.00003005@reddwarf.jmc> |
| In reply to | #50385 |
On Fri, 13 May 2022 12:03:43 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 5/13/2022 11:14 AM, Mr Flibble wrote:
> > On Fri, 13 May 2022 11:07:24 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 5/13/2022 7:38 AM, Mr Flibble wrote:
> >>> On Fri, 13 May 2022 11:54:49 +0100
> >>> Ben <ben.usenet@bsb.me.uk> wrote:
> >>>
> >>>> olcott <NoOne@NoWhere.com> writes:
> >>>>
> >>>>> On 5/12/2022 8:54 PM, Ben wrote:
> >>>>>> olcott <NoOne@NoWhere.com> writes:
> >>>>>>
> >>>>>>> On 5/12/2022 7:10 PM, Ben wrote:
> >>>>>>>> olcott <NoOne@NoWhere.com> writes:
> >>>>>>>>
> >>>>>>>>> Its done see my new post.
> >>>>>>>> Apart from the bug/typo it's a perfectly good way to
> >>>>>>>> implement a TM tape. It's not a deque though.
> >>>>>>>
> >>>>>>> I think that it is a better way to implement a std::deque.
> >>>>>> Better than what?
> >>>>>
> >>>>> The complex mess of the conventional way to implement std::deque
> >>>>>
> >>>>>> There are lots of ways to implement a deque and they
> >>>>>> all have advantages and disadvantages.
> >>>>>
> >>>>> If you get maximum
> >>>>> (a) simplicity (b) speed and (c) minimum space what more could
> >>>>> you want?
> >>>>
> >>>> Correctness.
> >>>>
> >>>>>> Of course, since you have not
> >>>>>> implemented any of the deque interface, I can't tell what
> >>>>>> method might be thinking of using. Other than it will
> >>>>>> probably use two vectors.
> >>>>>
> >>>>> public:
> >>>>> tape_element& front( ) { return Left.back(); }
> >>>>> tape_element& back() { return Right.back(); }
> >>>>> void pop_front() { Left.pop_back(); }
> >>>>> void pop_back() { Right.pop_back(); }
> >>>>> void push_front(tape_element& E) { Left.push_back(E); }
> >>>>> void push_back(tape_element& E) { Right.push_back(E); }
> >>>>> void reserve(unsigned int N)
> >>>>> { Left.reserve(N); Right.reserve(N); }
> >>>>
> >>>> This is not correct. Please read a book. Or at least write a
> >>>> test program and compare with std::deque.
> >>>
> >>> Even if we ignore complexity requirements and element reference
> >>> stability it is still wrong: what happens if `Left` is empty,
> >>> `Right` is non-empty and `pop_front` is called? It simply does not
> >>> conform to the std::deque interface.
> >>>
> >>> /Flibble
> >>>
> >>
> >> Oh, now I see what Ben was saying.
> >> Simply extend my definition of pop_front() to account for this.
> >
> > I will be interested to see how you account for this without
> > introducing linear, O(n), complexity for that operation.
> >
> > /Flibble
> >
>
> It requires linear, O(n), complexity for that operation.
> Tape_Type never needs to do that.
So your class isn't a better version of std::deque then because
std::deque::pop_front() is constant time not linear. Feel free to
apologize for your mistake.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-13 12:15 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <yaednWiSKce0D-P_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #50388 |
On 5/13/2022 12:09 PM, Mr Flibble wrote:
> On Fri, 13 May 2022 12:03:43 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/13/2022 11:14 AM, Mr Flibble wrote:
>>> On Fri, 13 May 2022 11:07:24 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 5/13/2022 7:38 AM, Mr Flibble wrote:
>>>>> On Fri, 13 May 2022 11:54:49 +0100
>>>>> Ben <ben.usenet@bsb.me.uk> wrote:
>>>>>
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 5/12/2022 8:54 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 5/12/2022 7:10 PM, Ben wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> Its done see my new post.
>>>>>>>>>> Apart from the bug/typo it's a perfectly good way to
>>>>>>>>>> implement a TM tape. It's not a deque though.
>>>>>>>>>
>>>>>>>>> I think that it is a better way to implement a std::deque.
>>>>>>>> Better than what?
>>>>>>>
>>>>>>> The complex mess of the conventional way to implement std::deque
>>>>>>>
>>>>>>>> There are lots of ways to implement a deque and they
>>>>>>>> all have advantages and disadvantages.
>>>>>>>
>>>>>>> If you get maximum
>>>>>>> (a) simplicity (b) speed and (c) minimum space what more could
>>>>>>> you want?
>>>>>>
>>>>>> Correctness.
>>>>>>
>>>>>>>> Of course, since you have not
>>>>>>>> implemented any of the deque interface, I can't tell what
>>>>>>>> method might be thinking of using. Other than it will
>>>>>>>> probably use two vectors.
>>>>>>>
>>>>>>> public:
>>>>>>> tape_element& front( ) { return Left.back(); }
>>>>>>> tape_element& back() { return Right.back(); }
>>>>>>> void pop_front() { Left.pop_back(); }
>>>>>>> void pop_back() { Right.pop_back(); }
>>>>>>> void push_front(tape_element& E) { Left.push_back(E); }
>>>>>>> void push_back(tape_element& E) { Right.push_back(E); }
>>>>>>> void reserve(unsigned int N)
>>>>>>> { Left.reserve(N); Right.reserve(N); }
>>>>>>
>>>>>> This is not correct. Please read a book. Or at least write a
>>>>>> test program and compare with std::deque.
>>>>>
>>>>> Even if we ignore complexity requirements and element reference
>>>>> stability it is still wrong: what happens if `Left` is empty,
>>>>> `Right` is non-empty and `pop_front` is called? It simply does not
>>>>> conform to the std::deque interface.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> Oh, now I see what Ben was saying.
>>>> Simply extend my definition of pop_front() to account for this.
>>>
>>> I will be interested to see how you account for this without
>>> introducing linear, O(n), complexity for that operation.
>>>
>>> /Flibble
>>>
>>
>> It requires linear, O(n), complexity for that operation.
>> Tape_Type never needs to do that.
>
> So your class isn't a better version of std::deque then because
> std::deque::pop_front() is constant time not linear. Feel free to
> apologize for your mistake.
>
> /Flibble
>
The reason that I asked for review was to verify that my version of
std::deque is always better. You found an exception to that claim.
That exception never applies to my use of Tape_Type.
--
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 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.theory
csiph-web