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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-13 17:26 +0100 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <875ym9z9et.fsf@bsb.me.uk> |
| In reply to | #50363 |
Mr Flibble <flibble@reddwarf.jmc> writes:
> 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.
Yes, I know. You are inclined to help by pointing this out, but it's so
easy to see that this class is wrong, but I hoped that PO would be
inclined to find out for himself what a deque should do.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-13 12:07 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <44CdnUwP0pbxDeP_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #50380 |
On 5/13/2022 11:26 AM, Ben wrote:
> Mr Flibble <flibble@reddwarf.jmc> writes:
>
>> 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.
>
> Yes, I know. You are inclined to help by pointing this out, but it's so
> easy to see that this class is wrong, but I hoped that PO would be
> inclined to find out for himself what a deque should do.
>
Flibble found a case where my member functions would need to be extended
and this extension may have a worse Big-O than std::deque in some cases.
--
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 19:45 +0100 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <87ilq9xodt.fsf@bsb.me.uk> |
| In reply to | #50387 |
olcott <NoOne@NoWhere.com> writes: > Flibble found a case where my member functions would need to be > extended and this extension may have a worse Big-O than std::deque in > some cases. As did everyone who glanced at the code for more than a few seconds. Or at least I sincerely hope they did. It's not hard to see that your code was wrong. -- 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-13 13:57 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <OdqdnRWhpOuQN-P_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #50401 |
On 5/13/2022 1:45 PM, Ben wrote: > olcott <NoOne@NoWhere.com> writes: > >> Flibble found a case where my member functions would need to be >> extended and this extension may have a worse Big-O than std::deque in >> some cases. > > As did everyone who glanced at the code for more than a few seconds. Or > at least I sincerely hope they did. It's not hard to see that your code > was wrong. > The details of std::deque is almost brand new to me. None-the-less my Tape_Type does seem optimal for a TM tape as long as the speed with Tape_Type::reserve() beats some and matches the rest of the speed of every operation of your std::string, otherwise I would go for the simpler std::string version. -- 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-13 15:04 -0400 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <TYxfK.2958$tTK.2462@fx97.iad> |
| In reply to | #50403 |
On 5/13/22 2:57 PM, olcott wrote: > On 5/13/2022 1:45 PM, Ben wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> Flibble found a case where my member functions would need to be >>> extended and this extension may have a worse Big-O than std::deque in >>> some cases. >> >> As did everyone who glanced at the code for more than a few seconds. Or >> at least I sincerely hope they did. It's not hard to see that your code >> was wrong. >> > > The details of std::deque is almost brand new to me. I thought you said your were an expert at Computer Science. The deque is like a first year data structure. > > None-the-less my Tape_Type does seem optimal for a TM tape as long as > the speed with Tape_Type::reserve() beats some and matches the rest of > the speed of every operation of your std::string, otherwise I would go > for the simpler std::string version. >
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-13 14:15 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <5sidnRk5xOXeM-P_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #50405 |
On 5/13/2022 2:04 PM, Richard Damon wrote: > On 5/13/22 2:57 PM, olcott wrote: >> On 5/13/2022 1:45 PM, Ben wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> Flibble found a case where my member functions would need to be >>>> extended and this extension may have a worse Big-O than std::deque in >>>> some cases. >>> >>> As did everyone who glanced at the code for more than a few seconds. Or >>> at least I sincerely hope they did. It's not hard to see that your code >>> was wrong. >>> >> >> The details of std::deque is almost brand new to me. > > I thought you said your were an expert at Computer Science. > I never said that. I am becoming an expert on the analytical foundations of knowledge and epistemology, which includes correcting the errors in the notions of analytical truth and provability. > The deque is like a first year data structure. > >> >> None-the-less my Tape_Type does seem optimal for a TM tape as long as >> the speed with Tape_Type::reserve() beats some and matches the rest of >> the speed of every operation of your std::string, otherwise I would go >> for the simpler std::string version. >> > -- 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-13 15:40 -0400 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <6vyfK.4945$x1Wf.4347@fx10.iad> |
| In reply to | #50412 |
On 5/13/22 3:15 PM, olcott wrote: > On 5/13/2022 2:04 PM, Richard Damon wrote: >> On 5/13/22 2:57 PM, olcott wrote: >>> On 5/13/2022 1:45 PM, Ben wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> Flibble found a case where my member functions would need to be >>>>> extended and this extension may have a worse Big-O than std::deque in >>>>> some cases. >>>> >>>> As did everyone who glanced at the code for more than a few >>>> seconds. Or >>>> at least I sincerely hope they did. It's not hard to see that your >>>> code >>>> was wrong. >>>> >>> >>> The details of std::deque is almost brand new to me. >> >> I thought you said your were an expert at Computer Science. >> > > I never said that. I am becoming an expert on the analytical foundations > of knowledge and epistemology, which includes correcting the errors in > the notions of analytical truth and provability. > But you have, isn't the criteria to understand your own proof: > > This proof can only be understood only by those having sufficient technical competence in: > (a) software engineering (recognizing infinite recursion in C and x86 code) > (b) the x86 programming language > (c) the C programming language and > (d) the details of how C is translated into x86 by the Microsoft C compilers. So, the first item is sufficient technical competence, which would include the basic builing blocks of software, like the deque. Also, you claim to have the training to have gotten a computer degree, except for a few non-technical courses you didn't take. Thus, either your own proof is beyond your understand (which I think it might actually be, which is why it has so many mistakes in it), or you have just admitted that you aren't really competent as a programmer, and thus ALL your claims about things being obvious, need to be taken with a grain of salt. This also explains why even dirt simple programming tasks take you so long, you just don't have the programming background to do it at all efficiently. >> The deque is like a first year data structure. >> >>> >>> None-the-less my Tape_Type does seem optimal for a TM tape as long as >>> the speed with Tape_Type::reserve() beats some and matches the rest >>> of the speed of every operation of your std::string, otherwise I >>> would go for the simpler std::string version. >>> >> > >
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-13 14:58 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <XM6dnUn-mqnWJeP_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #50420 |
On 5/13/2022 2:40 PM, Richard Damon wrote: > On 5/13/22 3:15 PM, olcott wrote: >> On 5/13/2022 2:04 PM, Richard Damon wrote: >>> On 5/13/22 2:57 PM, olcott wrote: >>>> On 5/13/2022 1:45 PM, Ben wrote: >>>>> olcott <NoOne@NoWhere.com> writes: >>>>> >>>>>> Flibble found a case where my member functions would need to be >>>>>> extended and this extension may have a worse Big-O than std::deque in >>>>>> some cases. >>>>> >>>>> As did everyone who glanced at the code for more than a few >>>>> seconds. Or >>>>> at least I sincerely hope they did. It's not hard to see that your >>>>> code >>>>> was wrong. >>>>> >>>> >>>> The details of std::deque is almost brand new to me. >>> >>> I thought you said your were an expert at Computer Science. >>> >> >> I never said that. I am becoming an expert on the analytical >> foundations of knowledge and epistemology, which includes correcting >> the errors in the notions of analytical truth and provability. >> > > But you have, isn't the criteria to understand your own proof: > >> >> This proof can only be understood only by those having sufficient >> technical competence in: >> (a) software engineering (recognizing infinite recursion in C and x86 >> code) >> (b) the x86 programming language >> (c) the C programming language and >> (d) the details of how C is translated into x86 by the Microsoft C >> compilers. > > So, the first item is sufficient technical competence, The precisely listed categories. > which would > include the basic builing blocks of software, like the deque. > Not at all, only the precisely listed categories are needed. > Also, you claim to have the training to have gotten a computer degree, > except for a few non-technical courses you didn't take. > Credibility often proves to be a crappy measure of validity especially for brand new insights. It has been dead obvious that H(P,P)==0 is the correct halt status for the input to H(P,P) on the basis of the actual behavior that this input actually specifies. This has been dead obvious on this basis for at least six months, yet people very persistently insisted on simply ignoring the easily verifiable facts for this whole six month period. -- 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-13 16:24 -0400 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <C7zfK.24$NMxb.11@fx02.iad> |
| In reply to | #50425 |
On 5/13/22 3:58 PM, olcott wrote: > On 5/13/2022 2:40 PM, Richard Damon wrote: >> On 5/13/22 3:15 PM, olcott wrote: >>> On 5/13/2022 2:04 PM, Richard Damon wrote: >>>> On 5/13/22 2:57 PM, olcott wrote: >>>>> On 5/13/2022 1:45 PM, Ben wrote: >>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>> >>>>>>> Flibble found a case where my member functions would need to be >>>>>>> extended and this extension may have a worse Big-O than >>>>>>> std::deque in >>>>>>> some cases. >>>>>> >>>>>> As did everyone who glanced at the code for more than a few >>>>>> seconds. Or >>>>>> at least I sincerely hope they did. It's not hard to see that >>>>>> your code >>>>>> was wrong. >>>>>> >>>>> >>>>> The details of std::deque is almost brand new to me. >>>> >>>> I thought you said your were an expert at Computer Science. >>>> >>> >>> I never said that. I am becoming an expert on the analytical >>> foundations of knowledge and epistemology, which includes correcting >>> the errors in the notions of analytical truth and provability. >>> >> >> But you have, isn't the criteria to understand your own proof: >> >>> >>> This proof can only be understood only by those having sufficient >>> technical competence in: >>> (a) software engineering (recognizing infinite recursion in C and x86 >>> code) >>> (b) the x86 programming language >>> (c) the C programming language and >>> (d) the details of how C is translated into x86 by the Microsoft C >>> compilers. >> >> So, the first item is sufficient technical competence, > > The precisely listed categories. > >> which would include the basic builing blocks of software, like the >> deque. >> > > Not at all, only the precisely listed categories are needed. > >> Also, you claim to have the training to have gotten a computer degree, >> except for a few non-technical courses you didn't take. >> > > Credibility often proves to be a crappy measure of validity especially > for brand new insights. > > It has been dead obvious that H(P,P)==0 is the correct halt status for > the input to H(P,P) on the basis of the actual behavior that this input > actually specifies. > > This has been dead obvious on this basis for at least six months, yet > people very persistently insisted on simply ignoring the easily > verifiable facts for this whole six month period. > It has been DEAD obvious for years that you don't actually understand what you are saying and don't understand how any of this actually works. If we can believe you, soon YOU will be dead, and we will be relieved of having to show you your errors. You clearly don't understand what it means for something to be true, or provable. You have shown that you have ZERO credibility behind anything that you have said. You claim great genius, but genius can break down its ideas to explain to those with lesser understanding. YOU just have delusions, which is shown by the fact that all you can do is keep rephrasing the same problematic statements, but can't actually break them done. All is base on it being 'obvious', but things that are obvious, generally can be actually proved. (The number of fundamental obvious assumptions that are used is tried to be kept to an absolute minimum.) One big problem to adding 'obvious' assumptions, is that every time you do, you add the risk of making your system inconsistent, and proving consistancy is something that often just can not be done. Which means that by your definitions, you can't talk about is a system is consistent, since that isn't often provable in the system, so it doesn't have a truth value.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-13 15:33 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <4KidnfSFNeUwXeP_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #50437 |
On 5/13/2022 3:24 PM, Richard Damon wrote: > On 5/13/22 3:58 PM, olcott wrote: >> On 5/13/2022 2:40 PM, Richard Damon wrote: >>> On 5/13/22 3:15 PM, olcott wrote: >>>> On 5/13/2022 2:04 PM, Richard Damon wrote: >>>>> On 5/13/22 2:57 PM, olcott wrote: >>>>>> On 5/13/2022 1:45 PM, Ben wrote: >>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>> >>>>>>>> Flibble found a case where my member functions would need to be >>>>>>>> extended and this extension may have a worse Big-O than >>>>>>>> std::deque in >>>>>>>> some cases. >>>>>>> >>>>>>> As did everyone who glanced at the code for more than a few >>>>>>> seconds. Or >>>>>>> at least I sincerely hope they did. It's not hard to see that >>>>>>> your code >>>>>>> was wrong. >>>>>>> >>>>>> >>>>>> The details of std::deque is almost brand new to me. >>>>> >>>>> I thought you said your were an expert at Computer Science. >>>>> >>>> >>>> I never said that. I am becoming an expert on the analytical >>>> foundations of knowledge and epistemology, which includes correcting >>>> the errors in the notions of analytical truth and provability. >>>> >>> >>> But you have, isn't the criteria to understand your own proof: >>> >>>> >>>> This proof can only be understood only by those having sufficient >>>> technical competence in: >>>> (a) software engineering (recognizing infinite recursion in C and >>>> x86 code) >>>> (b) the x86 programming language >>>> (c) the C programming language and >>>> (d) the details of how C is translated into x86 by the Microsoft C >>>> compilers. >>> >>> So, the first item is sufficient technical competence, >> >> The precisely listed categories. >> >>> which would include the basic builing blocks of software, like the >>> deque. >>> >> >> Not at all, only the precisely listed categories are needed. >> >>> Also, you claim to have the training to have gotten a computer >>> degree, except for a few non-technical courses you didn't take. >>> >> >> Credibility often proves to be a crappy measure of validity especially >> for brand new insights. >> >> It has been dead obvious that H(P,P)==0 is the correct halt status for >> the input to H(P,P) on the basis of the actual behavior that this >> input actually specifies. >> >> This has been dead obvious on this basis for at least six months, yet >> people very persistently insisted on simply ignoring the easily >> verifiable facts for this whole six month period. >> > > It has been DEAD obvious for years that you don't actually understand > what you are saying and don't understand how any of this actually works. H(P,P)==0 is proven to be correct empirically in that it does correctly decide the halt status that its input specifies. That is does not specify the halt status that you expect makes your expectation incorrect. -- 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-13 17:25 -0400 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <n1AfK.778$JXmb.251@fx03.iad> |
| In reply to | #50441 |
On 5/13/22 4:33 PM, olcott wrote: > On 5/13/2022 3:24 PM, Richard Damon wrote: >> On 5/13/22 3:58 PM, olcott wrote: >>> On 5/13/2022 2:40 PM, Richard Damon wrote: >>>> On 5/13/22 3:15 PM, olcott wrote: >>>>> On 5/13/2022 2:04 PM, Richard Damon wrote: >>>>>> On 5/13/22 2:57 PM, olcott wrote: >>>>>>> On 5/13/2022 1:45 PM, Ben wrote: >>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>> >>>>>>>>> Flibble found a case where my member functions would need to be >>>>>>>>> extended and this extension may have a worse Big-O than >>>>>>>>> std::deque in >>>>>>>>> some cases. >>>>>>>> >>>>>>>> As did everyone who glanced at the code for more than a few >>>>>>>> seconds. Or >>>>>>>> at least I sincerely hope they did. It's not hard to see that >>>>>>>> your code >>>>>>>> was wrong. >>>>>>>> >>>>>>> >>>>>>> The details of std::deque is almost brand new to me. >>>>>> >>>>>> I thought you said your were an expert at Computer Science. >>>>>> >>>>> >>>>> I never said that. I am becoming an expert on the analytical >>>>> foundations of knowledge and epistemology, which includes >>>>> correcting the errors in the notions of analytical truth and >>>>> provability. >>>>> >>>> >>>> But you have, isn't the criteria to understand your own proof: >>>> >>>>> >>>>> This proof can only be understood only by those having sufficient >>>>> technical competence in: >>>>> (a) software engineering (recognizing infinite recursion in C and >>>>> x86 code) >>>>> (b) the x86 programming language >>>>> (c) the C programming language and >>>>> (d) the details of how C is translated into x86 by the Microsoft C >>>>> compilers. >>>> >>>> So, the first item is sufficient technical competence, >>> >>> The precisely listed categories. >>> >>>> which would include the basic builing blocks of software, like the >>>> deque. >>>> >>> >>> Not at all, only the precisely listed categories are needed. >>> >>>> Also, you claim to have the training to have gotten a computer >>>> degree, except for a few non-technical courses you didn't take. >>>> >>> >>> Credibility often proves to be a crappy measure of validity >>> especially for brand new insights. >>> >>> It has been dead obvious that H(P,P)==0 is the correct halt status >>> for the input to H(P,P) on the basis of the actual behavior that this >>> input actually specifies. >>> >>> This has been dead obvious on this basis for at least six months, yet >>> people very persistently insisted on simply ignoring the easily >>> verifiable facts for this whole six month period. >>> >> >> It has been DEAD obvious for years that you don't actually understand >> what you are saying and don't understand how any of this actually works. > H(P,P)==0 is proven to be correct empirically in that it does correctly > decide the halt status that its input specifies. > > That is does not specify the halt status that you expect makes your > expectation incorrect. > Nope, just provesw that H (and you) are not using the REQUIERED criteria. The "proof" that H is correct is incorrect based on the right definitions of the terms, and only proves that you are not working on the Halting Problem. Note, you don't get to redefine the problem or claim it can't mean what it says, THAT is invalid logic. You are just proving you are a liar.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-13 16:48 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <FJWdnauuhYHeT-P_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #50460 |
On 5/13/2022 4:25 PM, Richard Damon wrote: > On 5/13/22 4:33 PM, olcott wrote: >> On 5/13/2022 3:24 PM, Richard Damon wrote: >>> On 5/13/22 3:58 PM, olcott wrote: >>>> On 5/13/2022 2:40 PM, Richard Damon wrote: >>>>> On 5/13/22 3:15 PM, olcott wrote: >>>>>> On 5/13/2022 2:04 PM, Richard Damon wrote: >>>>>>> On 5/13/22 2:57 PM, olcott wrote: >>>>>>>> On 5/13/2022 1:45 PM, Ben wrote: >>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>> >>>>>>>>>> Flibble found a case where my member functions would need to be >>>>>>>>>> extended and this extension may have a worse Big-O than >>>>>>>>>> std::deque in >>>>>>>>>> some cases. >>>>>>>>> >>>>>>>>> As did everyone who glanced at the code for more than a few >>>>>>>>> seconds. Or >>>>>>>>> at least I sincerely hope they did. It's not hard to see that >>>>>>>>> your code >>>>>>>>> was wrong. >>>>>>>>> >>>>>>>> >>>>>>>> The details of std::deque is almost brand new to me. >>>>>>> >>>>>>> I thought you said your were an expert at Computer Science. >>>>>>> >>>>>> >>>>>> I never said that. I am becoming an expert on the analytical >>>>>> foundations of knowledge and epistemology, which includes >>>>>> correcting the errors in the notions of analytical truth and >>>>>> provability. >>>>>> >>>>> >>>>> But you have, isn't the criteria to understand your own proof: >>>>> >>>>>> >>>>>> This proof can only be understood only by those having sufficient >>>>>> technical competence in: >>>>>> (a) software engineering (recognizing infinite recursion in C and >>>>>> x86 code) >>>>>> (b) the x86 programming language >>>>>> (c) the C programming language and >>>>>> (d) the details of how C is translated into x86 by the Microsoft C >>>>>> compilers. >>>>> >>>>> So, the first item is sufficient technical competence, >>>> >>>> The precisely listed categories. >>>> >>>>> which would include the basic builing blocks of software, like the >>>>> deque. >>>>> >>>> >>>> Not at all, only the precisely listed categories are needed. >>>> >>>>> Also, you claim to have the training to have gotten a computer >>>>> degree, except for a few non-technical courses you didn't take. >>>>> >>>> >>>> Credibility often proves to be a crappy measure of validity >>>> especially for brand new insights. >>>> >>>> It has been dead obvious that H(P,P)==0 is the correct halt status >>>> for the input to H(P,P) on the basis of the actual behavior that >>>> this input actually specifies. >>>> >>>> This has been dead obvious on this basis for at least six months, >>>> yet people very persistently insisted on simply ignoring the easily >>>> verifiable facts for this whole six month period. >>>> >>> >>> It has been DEAD obvious for years that you don't actually understand >>> what you are saying and don't understand how any of this actually works. >> H(P,P)==0 is proven to be correct empirically in that it does >> correctly decide the halt status that its input specifies. >> >> That is does not specify the halt status that you expect makes your >> expectation incorrect. >> > > Nope, just provesw that H (and you) are not using the REQUIERED criteria. > > The "proof" that H is correct is incorrect based on the right > definitions of the terms, and only proves that you are not working on > the Halting Problem. > Tarski makes a similar mistake when he concludes that True() is not a definable predicate entirely on the basis that he cannot prove that the liar paradox is true. It never occurred to him that the liar paradox is simply untrue. That the definition of the halting problem criteria (in some rare cases) directly contradicts the definition of a computer science decider that requires all deciders to compute the mapping from their inputs conclusively proves that the definition of the halting problem criteria is incorrect in these (previously undiscovered) rare cases. -- 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-13 18:05 -0400 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <ECAfK.1466$j0D5.823@fx09.iad> |
| In reply to | #50470 |
On 5/13/22 5:48 PM, olcott wrote: > On 5/13/2022 4:25 PM, Richard Damon wrote: >> On 5/13/22 4:33 PM, olcott wrote: >>> On 5/13/2022 3:24 PM, Richard Damon wrote: >>>> On 5/13/22 3:58 PM, olcott wrote: >>>>> On 5/13/2022 2:40 PM, Richard Damon wrote: >>>>>> On 5/13/22 3:15 PM, olcott wrote: >>>>>>> On 5/13/2022 2:04 PM, Richard Damon wrote: >>>>>>>> On 5/13/22 2:57 PM, olcott wrote: >>>>>>>>> On 5/13/2022 1:45 PM, Ben wrote: >>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>> >>>>>>>>>>> Flibble found a case where my member functions would need to be >>>>>>>>>>> extended and this extension may have a worse Big-O than >>>>>>>>>>> std::deque in >>>>>>>>>>> some cases. >>>>>>>>>> >>>>>>>>>> As did everyone who glanced at the code for more than a few >>>>>>>>>> seconds. Or >>>>>>>>>> at least I sincerely hope they did. It's not hard to see that >>>>>>>>>> your code >>>>>>>>>> was wrong. >>>>>>>>>> >>>>>>>>> >>>>>>>>> The details of std::deque is almost brand new to me. >>>>>>>> >>>>>>>> I thought you said your were an expert at Computer Science. >>>>>>>> >>>>>>> >>>>>>> I never said that. I am becoming an expert on the analytical >>>>>>> foundations of knowledge and epistemology, which includes >>>>>>> correcting the errors in the notions of analytical truth and >>>>>>> provability. >>>>>>> >>>>>> >>>>>> But you have, isn't the criteria to understand your own proof: >>>>>> >>>>>>> >>>>>>> This proof can only be understood only by those having sufficient >>>>>>> technical competence in: >>>>>>> (a) software engineering (recognizing infinite recursion in C and >>>>>>> x86 code) >>>>>>> (b) the x86 programming language >>>>>>> (c) the C programming language and >>>>>>> (d) the details of how C is translated into x86 by the Microsoft >>>>>>> C compilers. >>>>>> >>>>>> So, the first item is sufficient technical competence, >>>>> >>>>> The precisely listed categories. >>>>> >>>>>> which would include the basic builing blocks of software, like >>>>>> the deque. >>>>>> >>>>> >>>>> Not at all, only the precisely listed categories are needed. >>>>> >>>>>> Also, you claim to have the training to have gotten a computer >>>>>> degree, except for a few non-technical courses you didn't take. >>>>>> >>>>> >>>>> Credibility often proves to be a crappy measure of validity >>>>> especially for brand new insights. >>>>> >>>>> It has been dead obvious that H(P,P)==0 is the correct halt status >>>>> for the input to H(P,P) on the basis of the actual behavior that >>>>> this input actually specifies. >>>>> >>>>> This has been dead obvious on this basis for at least six months, >>>>> yet people very persistently insisted on simply ignoring the easily >>>>> verifiable facts for this whole six month period. >>>>> >>>> >>>> It has been DEAD obvious for years that you don't actually >>>> understand what you are saying and don't understand how any of this >>>> actually works. >>> H(P,P)==0 is proven to be correct empirically in that it does >>> correctly decide the halt status that its input specifies. >>> >>> That is does not specify the halt status that you expect makes your >>> expectation incorrect. >>> >> >> Nope, just provesw that H (and you) are not using the REQUIERED criteria. >> >> The "proof" that H is correct is incorrect based on the right >> definitions of the terms, and only proves that you are not working on >> the Halting Problem. >> > > Tarski makes a similar mistake when he concludes that True() is not a > definable predicate entirely on the basis that he cannot prove that the > liar paradox is true. It never occurred to him that the liar paradox is > simply untrue. > > That the definition of the halting problem criteria (in some rare cases) > directly contradicts the definition of a computer science decider that > requires all deciders to compute the mapping from their inputs > conclusively proves that the definition of the halting problem criteria > is incorrect in these (previously undiscovered) rare cases. > > Nope, your are just talking nonsense. See my other answer.
[toc] | [prev] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-13 20:12 +0100 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <871qwxxn4u.fsf@bsb.me.uk> |
| In reply to | #50403 |
olcott <NoOne@NoWhere.com> writes: > On 5/13/2022 1:45 PM, Ben wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> Flibble found a case where my member functions would need to be >>> extended and this extension may have a worse Big-O than std::deque in >>> some cases. >> >> As did everyone who glanced at the code for more than a few seconds. Or >> at least I sincerely hope they did. It's not hard to see that your code >> was wrong. > > The details of std::deque is almost brand new to me. I guessed as much. Yet you claimed to have done better than the teams of experienced programmers who've worked on various C++ standard libraries after writing only a few lines of code? That level of delusion might lead someone to think they can solve the halting problem. > None-the-less my Tape_Type does seem optimal for a TM tape as long as > the speed with Tape_Type::reserve() beats some and matches the rest of > the speed of every operation of your std::string, otherwise I would go > for the simpler std::string version. Using reserve has no effect on the one test case I have for timing. -- 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-13 14:28 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <ibSdnZplz8XxLOP_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #50409 |
On 5/13/2022 2:12 PM, Ben wrote: > olcott <NoOne@NoWhere.com> writes: > >> On 5/13/2022 1:45 PM, Ben wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> Flibble found a case where my member functions would need to be >>>> extended and this extension may have a worse Big-O than std::deque in >>>> some cases. >>> >>> As did everyone who glanced at the code for more than a few seconds. Or >>> at least I sincerely hope they did. It's not hard to see that your code >>> was wrong. >> >> The details of std::deque is almost brand new to me. > > I guessed as much. Yet you claimed to have done better than the teams > of experienced programmers who've worked on various C++ standard > libraries after writing only a few lines of code? That level of > delusion might lead someone to think they can solve the halting problem. > None-the-less my version does perform better and is much simpler on the operations that I need. >> None-the-less my Tape_Type does seem optimal for a TM tape as long as >> the speed with Tape_Type::reserve() beats some and matches the rest of >> the speed of every operation of your std::string, otherwise I would go >> for the simpler std::string version. > > Using reserve has no effect on the one test case I have for timing. > What is the speed difference? It may be that yours is simply better than mine. Faster, smaller and simpler is definiitely better, depending on the test case coverage. -- 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 21:58 +0100 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <87fsldw3np.fsf@bsb.me.uk> |
| In reply to | #50418 |
olcott <NoOne@NoWhere.com> writes: > On 5/13/2022 2:12 PM, Ben wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> On 5/13/2022 1:45 PM, Ben wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> Flibble found a case where my member functions would need to be >>>>> extended and this extension may have a worse Big-O than std::deque in >>>>> some cases. >>>> >>>> As did everyone who glanced at the code for more than a few seconds. Or >>>> at least I sincerely hope they did. It's not hard to see that your code >>>> was wrong. >>> >>> The details of std::deque is almost brand new to me. >> >> I guessed as much. Yet you claimed to have done better than the teams >> of experienced programmers who've worked on various C++ standard >> libraries after writing only a few lines of code? That level of >> delusion might lead someone to think they can solve the halting problem. > > None-the-less my version does perform better and is much simpler on > the operations that I need. What new delusion is this? Your "version" is not a deque. What is it a version of? What does it perform better than? >>> None-the-less my Tape_Type does seem optimal for a TM tape as long as >>> the speed with Tape_Type::reserve() beats some and matches the rest of >>> the speed of every operation of your std::string, otherwise I would go >>> for the simpler std::string version. >> >> Using reserve has no effect on the one test case I have for timing. > > What is the speed difference? Not reliably measurable. I could do more robust tests but that's not what I want to do today. -- 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-13 16:12 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <Kb2dnUS7ONJVVOP_nZ2dnUU7_81QAAAA@giganews.com> |
| In reply to | #50449 |
On 5/13/2022 3:58 PM, Ben wrote: > olcott <NoOne@NoWhere.com> writes: > >> On 5/13/2022 2:12 PM, Ben wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> On 5/13/2022 1:45 PM, Ben wrote: >>>>> olcott <NoOne@NoWhere.com> writes: >>>>> >>>>>> Flibble found a case where my member functions would need to be >>>>>> extended and this extension may have a worse Big-O than std::deque in >>>>>> some cases. >>>>> >>>>> As did everyone who glanced at the code for more than a few seconds. Or >>>>> at least I sincerely hope they did. It's not hard to see that your code >>>>> was wrong. >>>> >>>> The details of std::deque is almost brand new to me. >>> >>> I guessed as much. Yet you claimed to have done better than the teams >>> of experienced programmers who've worked on various C++ standard >>> libraries after writing only a few lines of code? That level of >>> delusion might lead someone to think they can solve the halting problem. >> >> None-the-less my version does perform better and is much simpler on >> the operations that I need. > > What new delusion is this? Your "version" is not a deque. What is it a > version of? What does it perform better than? > >>>> None-the-less my Tape_Type does seem optimal for a TM tape as long as >>>> the speed with Tape_Type::reserve() beats some and matches the rest of >>>> the speed of every operation of your std::string, otherwise I would go >>>> for the simpler std::string version. >>> >>> Using reserve has no effect on the one test case I have for timing. >> >> What is the speed difference? > > Not reliably measurable. I could do more robust tests but that's not > what I want to do today. > This always works well for me. https://www.tutorialspoint.com/c_standard_library/c_function_clock.htm I want to know if your version is better than mine. When I am all done I want to have the best version. -- 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 23:57 +0100 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <874k1tvy63.fsf@bsb.me.uk> |
| In reply to | #50453 |
olcott <NoOne@NoWhere.com> writes: > On 5/13/2022 3:58 PM, Ben wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> On 5/13/2022 2:12 PM, Ben wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> On 5/13/2022 1:45 PM, Ben wrote: >>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>> >>>>>>> Flibble found a case where my member functions would need to be >>>>>>> extended and this extension may have a worse Big-O than std::deque in >>>>>>> some cases. >>>>>> >>>>>> As did everyone who glanced at the code for more than a few seconds. Or >>>>>> at least I sincerely hope they did. It's not hard to see that your code >>>>>> was wrong. >>>>> >>>>> The details of std::deque is almost brand new to me. >>>> >>>> I guessed as much. Yet you claimed to have done better than the teams >>>> of experienced programmers who've worked on various C++ standard >>>> libraries after writing only a few lines of code? That level of >>>> delusion might lead someone to think they can solve the halting problem. >>> >>> None-the-less my version does perform better and is much simpler on >>> the operations that I need. >> What new delusion is this? Your "version" is not a deque. What is it a >> version of? What does it perform better than? >> >>>>> None-the-less my Tape_Type does seem optimal for a TM tape as long as >>>>> the speed with Tape_Type::reserve() beats some and matches the rest of >>>>> the speed of every operation of your std::string, otherwise I would go >>>>> for the simpler std::string version. >>>> >>>> Using reserve has no effect on the one test case I have for timing. >>> >>> What is the speed difference? >> >> Not reliably measurable. I could do more robust tests but that's not >> what I want to do today. > > This always works well for me. > https://www.tutorialspoint.com/c_standard_library/c_function_clock.htm It's not a method I like. When yours program is working, you can do timings any way you like. (And since the code is C++ you might want to look at std::chrono::high_resolution_clock.) > I want to know if your version is better than mine. > When I am all done I want to have the best version. Well, it's better because it's finished. It may be worse in other ways, but you don't say what "best" means to you. -- 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-13 17:59 -0500 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <zaWdnfcK_d13f-P_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #50485 |
On 5/13/2022 5:57 PM, Ben wrote: > olcott <NoOne@NoWhere.com> writes: > >> On 5/13/2022 3:58 PM, Ben wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> On 5/13/2022 2:12 PM, Ben wrote: >>>>> olcott <NoOne@NoWhere.com> writes: >>>>> >>>>>> On 5/13/2022 1:45 PM, Ben wrote: >>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>> >>>>>>>> Flibble found a case where my member functions would need to be >>>>>>>> extended and this extension may have a worse Big-O than std::deque in >>>>>>>> some cases. >>>>>>> >>>>>>> As did everyone who glanced at the code for more than a few seconds. Or >>>>>>> at least I sincerely hope they did. It's not hard to see that your code >>>>>>> was wrong. >>>>>> >>>>>> The details of std::deque is almost brand new to me. >>>>> >>>>> I guessed as much. Yet you claimed to have done better than the teams >>>>> of experienced programmers who've worked on various C++ standard >>>>> libraries after writing only a few lines of code? That level of >>>>> delusion might lead someone to think they can solve the halting problem. >>>> >>>> None-the-less my version does perform better and is much simpler on >>>> the operations that I need. >>> What new delusion is this? Your "version" is not a deque. What is it a >>> version of? What does it perform better than? >>> >>>>>> None-the-less my Tape_Type does seem optimal for a TM tape as long as >>>>>> the speed with Tape_Type::reserve() beats some and matches the rest of >>>>>> the speed of every operation of your std::string, otherwise I would go >>>>>> for the simpler std::string version. >>>>> >>>>> Using reserve has no effect on the one test case I have for timing. >>>> >>>> What is the speed difference? >>> >>> Not reliably measurable. I could do more robust tests but that's not >>> what I want to do today. >> >> This always works well for me. >> https://www.tutorialspoint.com/c_standard_library/c_function_clock.htm > > It's not a method I like. When yours program is working, you can > do timings any way you like. (And since the code is C++ you might want > to look at std::chrono::high_resolution_clock.) > >> I want to know if your version is better than mine. >> When I am all done I want to have the best version. > > Well, it's better because it's finished. It may be worse in other ways, > but you don't say what "best" means to you. > Mine is certainly designed to scale so on this basis I will keep mine. -- 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-14 01:00 +0100 |
| Subject | Re: Validating that the implementation meets the spec for TM transition function [ best tape ] |
| Message-ID | <87h75tugo8.fsf@bsb.me.uk> |
| In reply to | #50489 |
olcott <NoOne@NoWhere.com> writes: > On 5/13/2022 5:57 PM, Ben wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> On 5/13/2022 3:58 PM, Ben wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> On 5/13/2022 2:12 PM, Ben wrote: >>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>> >>>>>>> On 5/13/2022 1:45 PM, Ben wrote: >>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>> >>>>>>>>> Flibble found a case where my member functions would need to be >>>>>>>>> extended and this extension may have a worse Big-O than std::deque in >>>>>>>>> some cases. >>>>>>>> >>>>>>>> As did everyone who glanced at the code for more than a few seconds. Or >>>>>>>> at least I sincerely hope they did. It's not hard to see that your code >>>>>>>> was wrong. >>>>>>> >>>>>>> The details of std::deque is almost brand new to me. >>>>>> >>>>>> I guessed as much. Yet you claimed to have done better than the teams >>>>>> of experienced programmers who've worked on various C++ standard >>>>>> libraries after writing only a few lines of code? That level of >>>>>> delusion might lead someone to think they can solve the halting problem. >>>>> >>>>> None-the-less my version does perform better and is much simpler on >>>>> the operations that I need. >>>> What new delusion is this? Your "version" is not a deque. What is it a >>>> version of? What does it perform better than? >>>> >>>>>>> None-the-less my Tape_Type does seem optimal for a TM tape as long as >>>>>>> the speed with Tape_Type::reserve() beats some and matches the rest of >>>>>>> the speed of every operation of your std::string, otherwise I would go >>>>>>> for the simpler std::string version. >>>>>> >>>>>> Using reserve has no effect on the one test case I have for timing. >>>>> >>>>> What is the speed difference? >>>> >>>> Not reliably measurable. I could do more robust tests but that's not >>>> what I want to do today. >>> >>> This always works well for me. >>> https://www.tutorialspoint.com/c_standard_library/c_function_clock.htm >> It's not a method I like. When yours program is working, you can >> do timings any way you like. (And since the code is C++ you might want >> to look at std::chrono::high_resolution_clock.) >> >>> I want to know if your version is better than mine. >>> When I am all done I want to have the best version. >> Well, it's better because it's finished. It may be worse in other ways, >> but you don't say what "best" means to you. > > Mine is certainly designed to scale so on this basis I will keep mine. You don't have a TM interpreter yet! So presumably you mean you'll keep your design even though you don't know if mine scales. You have always stated strong opinions based on little knowledge. -- Ben. "le génie humain a des limites, quand la bêtise humaine n’en a pas" Alexandre Dumas (fils)
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.theory
csiph-web