Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #134369 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2025-10-30 09:49 -0500 |
| Last post | 2025-11-01 12:42 -0700 |
| Articles | 20 on this page of 293 — 15 participants |
Back to article view | Back to comp.theory
Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-30 09:49 -0500
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-30 20:11 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-30 15:25 -0500
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-30 20:42 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-30 16:05 -0500
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-30 21:15 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-30 16:49 -0500
Re: Semantic properties of finite string inputs dbush <dbush.mobile@gmail.com> - 2025-10-30 20:13 -0400
Re: Semantic properties of finite string inputs --- Mike never did get this olcott <polcott333@gmail.com> - 2025-10-30 21:14 -0500
Re: Semantic properties of finite string inputs --- Mike never did get this "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-30 19:15 -0700
Re: Semantic properties of finite string inputs --- Mike never did get this dbush <dbush.mobile@gmail.com> - 2025-10-30 22:33 -0400
Re: Semantic properties of finite string inputs --- Mike never did get this olcott <polcott333@gmail.com> - 2025-10-30 21:45 -0500
Re: Semantic properties of finite string inputs --- Mike never did get this dbush <dbush.mobile@gmail.com> - 2025-10-30 22:49 -0400
Re: Semantic properties of finite string inputs --- Mike never did get this olcott <polcott333@gmail.com> - 2025-10-30 21:54 -0500
Re: Semantic properties of finite string inputs --- Mike never did get this dbush <dbush.mobile@gmail.com> - 2025-10-30 22:56 -0400
Re: Semantic properties of finite string inputs --- Mike never did get this olcott <polcott333@gmail.com> - 2025-10-30 21:59 -0500
Re: Semantic properties of finite string inputs --- Mike never did get this dbush <dbush.mobile@gmail.com> - 2025-10-30 23:00 -0400
Re: Semantic properties of finite string inputs --- Mike never did get this olcott <polcott333@gmail.com> - 2025-10-30 22:03 -0500
Re: Semantic properties of finite string inputs --- Mike never did get this dbush <dbush.mobile@gmail.com> - 2025-10-30 23:04 -0400
Re: Semantic properties of finite string inputs --- Mike never did get this olcott <polcott333@gmail.com> - 2025-10-30 22:15 -0500
Re: Semantic properties of finite string inputs --- Mike never did get this dbush <dbush.mobile@gmail.com> - 2025-10-30 23:19 -0400
Re: Semantic properties of finite string inputs --- Mike never did get this olcott <polcott333@gmail.com> - 2025-10-30 22:25 -0500
Re: Semantic properties of finite string inputs --- Mike never did get this dbush <dbush.mobile@gmail.com> - 2025-10-30 23:28 -0400
Re: Semantic properties of finite string inputs --- Mike never did get this olcott <polcott333@gmail.com> - 2025-10-30 22:49 -0500
Re: Semantic properties of finite string inputs --- Mike never did get this dbush <dbush.mobile@gmail.com> - 2025-10-31 00:00 -0400
Re: Semantic properties of finite string inputs --- Mike never did get this olcott <polcott333@gmail.com> - 2025-10-30 23:06 -0500
Re: Semantic properties of finite string inputs --- Mike never did get this dbush <dbush.mobile@gmail.com> - 2025-10-31 07:22 -0400
Re: Semantic properties of finite string inputs --- Mike never did get this olcott <polcott333@gmail.com> - 2025-10-31 06:55 -0500
Re: Semantic properties of finite string inputs --- Mike never did get this dbush <dbush.mobile@gmail.com> - 2025-10-31 08:08 -0400
Re: Semantic properties of finite string inputs --- Mike never did get this olcott <polcott333@gmail.com> - 2025-10-31 07:30 -0500
Re: Semantic properties of finite string inputs --- Mike never did get this dbush <dbush.mobile@gmail.com> - 2025-10-31 08:33 -0400
Re: Semantic properties of finite string inputs --- Mike never did get this olcott <polcott333@gmail.com> - 2025-10-31 09:02 -0500
Re: Semantic properties of finite string inputs --- Mike never did get this dbush <dbush.mobile@gmail.com> - 2025-10-31 10:15 -0400
Re: Semantic properties of finite string inputs --- Mike never did get this olcott <polcott333@gmail.com> - 2025-10-31 09:24 -0500
Re: Semantic properties of finite string inputs --- Mike never did get this dbush <dbush.mobile@gmail.com> - 2025-10-31 10:28 -0400
Re: Semantic properties of finite string inputs --- Mike never did get this "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-31 12:36 -0700
Re: Semantic properties of finite string inputs --- Mike never did get this "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-31 12:35 -0700
Re: Semantic properties of finite string inputs --- Mike never did get this Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 04:55 +0000
Re: Semantic properties of finite string inputs --- Mike never did get this olcott <polcott333@gmail.com> - 2025-10-31 06:57 -0500
Re: Semantic properties of finite string inputs --- Mike never did get this Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 17:17 +0000
Re: Semantic properties of finite string inputs --- Mike never did get this Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 17:20 +0000
Re: Semantic properties of finite string inputs --- Mike never did get this "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-31 12:32 -0700
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 00:22 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-30 21:07 -0500
Re: Semantic properties of finite string inputs dbush <dbush.mobile@gmail.com> - 2025-10-30 22:10 -0400
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-30 21:17 -0500
Re: Semantic properties of finite string inputs "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-30 19:18 -0700
Re: Semantic properties of finite string inputs dbush <dbush.mobile@gmail.com> - 2025-10-30 22:35 -0400
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-30 21:48 -0500
Re: Semantic properties of finite string inputs dbush <dbush.mobile@gmail.com> - 2025-10-30 22:50 -0400
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-30 21:56 -0500
Re: Semantic properties of finite string inputs dbush <dbush.mobile@gmail.com> - 2025-10-30 22:58 -0400
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-30 22:01 -0500
Re: Semantic properties of finite string inputs dbush <dbush.mobile@gmail.com> - 2025-10-30 23:03 -0400
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-30 22:05 -0500
Re: Semantic properties of finite string inputs dbush <dbush.mobile@gmail.com> - 2025-10-30 23:06 -0400
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-30 22:16 -0500
Re: Semantic properties of finite string inputs dbush <dbush.mobile@gmail.com> - 2025-10-30 23:20 -0400
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-30 22:27 -0500
Re: Semantic properties of finite string inputs dbush <dbush.mobile@gmail.com> - 2025-10-30 23:30 -0400
Re: Semantic properties of finite string inputs dbush <dbush.mobile@gmail.com> - 2025-10-30 22:59 -0400
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 03:35 +0000
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 03:29 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-30 22:47 -0500
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 04:39 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-31 07:27 -0500
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-30 17:32 -0500
Re: Semantic properties of finite string inputs "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-30 17:01 -0700
Re: Semantic properties of finite string inputs Ben Bacarisse <ben@bsb.me.uk> - 2025-10-31 00:57 +0000
Re: Semantic properties of finite string inputs dbush <dbush.mobile@gmail.com> - 2025-10-30 16:44 -0400
Re: Semantic properties of finite string inputs Mikko <mikko.levanto@iki.fi> - 2025-10-31 13:28 +0200
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-31 07:44 -0500
Re: Semantic properties of finite string inputs Mikko <mikko.levanto@iki.fi> - 2025-11-01 10:42 +0200
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 08:25 -0500
Re: Semantic properties of finite string inputs dbush <dbush.mobile@gmail.com> - 2025-11-01 09:51 -0400
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 20:12 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 15:18 -0500
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 20:53 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 16:08 -0500
Re: Semantic properties of finite string inputs Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-11-01 21:12 +0000
Re: Semantic properties of finite string inputs "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-01 13:59 -0700
Re: Semantic properties of finite string inputs Mikko <mikko.levanto@iki.fi> - 2025-11-02 14:17 +0200
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-02 07:29 -0600
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-02 22:26 +0000
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-03 20:43 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-03 14:47 -0600
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-03 22:40 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-03 16:56 -0600
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 00:24 +0000
Re: Semantic properties of finite string inputs --- Closure ??? olcott <polcott333@gmail.com> - 2025-11-03 18:43 -0600
Re: Semantic properties of finite string inputs --- Closure ??? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 02:22 +0000
Re: Semantic properties of finite string inputs --- Closure ??? olcott <polcott333@gmail.com> - 2025-11-03 21:02 -0600
Re: Semantic properties of finite string inputs --- Closure ??? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 04:28 +0000
Re: Semantic properties of finite string inputs --- Closure ??? olcott <polcott333@gmail.com> - 2025-11-04 13:52 -0600
Re: Semantic properties of finite string inputs --- Closure ??? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 20:20 +0000
Re: Semantic properties of finite string inputs --- Closure ??? Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-11-04 21:04 +0000
Re: Semantic properties of finite string inputs --- Closure ??? wij <wyniijj5@gmail.com> - 2025-11-05 20:04 +0800
Re: Semantic properties of finite string inputs --- Closure !!! olcott <polcott333@gmail.com> - 2025-11-05 09:50 -0600
Re: Semantic properties of finite string inputs --- Closure !!! Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-05 17:51 +0000
Re: Semantic properties of finite string inputs --- Closure !!! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-05 12:18 -0800
Re: Semantic properties of finite string inputs --- Closure !!! olcott <polcott333@gmail.com> - 2025-11-05 19:29 -0600
Re: Semantic properties of finite string inputs --- Closure !!! dbush <dbush.mobile@gmail.com> - 2025-11-05 20:43 -0500
Re: Semantic properties of finite string inputs --- Closure !!! Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-07 16:03 +0000
Re: Semantic properties of finite string inputs --- Closure !!! Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-07 15:59 +0000
Re: Semantic properties of finite string inputs --- Closure !!! olcott <polcott333@gmail.com> - 2025-11-07 10:13 -0600
Re: Semantic properties of finite string inputs --- Closure !!! Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-07 16:41 +0000
Re: Semantic properties of finite string inputs --- Closure !!! olcott <polcott333@gmail.com> - 2025-11-07 10:44 -0600
Re: Semantic properties of finite string inputs --- Closure !!! olcott <polcott333@gmail.com> - 2025-11-07 10:27 -0600
Re: Semantic properties of finite string inputs --- Closure ??? joes <noreply@example.org> - 2025-11-05 14:52 +0000
Re: Semantic properties of finite string inputs --- Closure ??? olcott <polcott333@gmail.com> - 2025-11-05 09:54 -0600
Re: Semantic properties of finite string inputs --- Closure ??? joes <noreply@example.org> - 2025-11-05 16:52 +0000
Re: Semantic properties of finite string inputs --- Closure on one point olcott <polcott333@gmail.com> - 2025-11-05 11:10 -0600
Re: Semantic properties of finite string inputs --- Closure on one point "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-05 12:11 -0800
Re: Semantic properties of finite string inputs --- Closure ??? Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-04 20:10 +0000
Re: Semantic properties of finite string inputs --- Closure ??? olcott <polcott333@gmail.com> - 2025-11-04 14:35 -0600
Re: Semantic properties of finite string inputs --- Closure ??? joes <noreply@example.org> - 2025-11-04 20:51 +0000
Re: Semantic properties of finite string inputs --- Closure ??? olcott <polcott333@gmail.com> - 2025-11-04 14:55 -0600
Re: Semantic properties of finite string inputs --- Closure ??? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 21:43 +0000
Re: Semantic properties of finite string inputs --- Closure ??? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 21:35 +0000
Re: Semantic properties of finite string inputs --- Kaz made a great test olcott <polcott333@gmail.com> - 2025-11-04 15:52 -0600
Re: Semantic properties of finite string inputs --- Kaz made a great test Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 22:12 +0000
Re: Semantic properties of finite string inputs --- Kaz code Deviation olcott <polcott333@gmail.com> - 2025-11-04 16:13 -0600
Re: Semantic properties of finite string inputs --- Kaz code Deviation Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 22:33 +0000
Re: Semantic properties of finite string inputs --- Kaz code Deviation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-04 14:41 -0800
Re: Semantic properties of finite string inputs --- Kaz code Deviation olcott <polcott333@gmail.com> - 2025-11-04 17:18 -0600
Re: Semantic properties of finite string inputs --- Kaz code Deviation Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-05 02:08 +0000
Re: Semantic properties of finite string inputs --- Kaz code Deviation olcott <polcott333@gmail.com> - 2025-11-04 20:24 -0600
Re: Semantic properties of finite string inputs --- Kaz makes a very smart example olcott <polcott333@gmail.com> - 2025-11-04 18:16 -0600
Re: Semantic properties of finite string inputs Mikko <mikko.levanto@iki.fi> - 2025-11-03 12:05 +0200
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-03 17:16 +0000
Re: Semantic properties of finite string inputs Alan Mackenzie <acm@muc.de> - 2025-11-03 20:19 +0000
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-03 21:35 +0000
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-03 21:36 +0000
Olcott's revised position statement olcott <polcott333@gmail.com> - 2025-11-03 15:48 -0600
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-03 21:57 +0000
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-11-02 14:10 -0500
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-31 12:35 +0000
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 18:00 +0000
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-31 19:46 +0000
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 23:10 +0000
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 02:47 +0000
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-11-01 00:14 -0400
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 18:09 +0000
Re: Semantic properties of finite string inputs "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-01 12:53 -0700
A decider for the proposition "Tristan is Olcott" (Was: Semantic properties of finite string inputs) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 20:15 +0000
Re: A decider for the proposition "Tristan is Olcott" (Was: Semantic properties of finite string inputs) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-01 14:06 -0700
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-10-31 22:13 -0400
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 02:53 +0000
Re: Semantic properties of finite string inputs --- More precisely olcott <polcott333@gmail.com> - 2025-10-31 21:58 -0500
Re: Semantic properties of finite string inputs --- More precisely Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 04:23 +0000
Re: Semantic properties of finite string inputs --- More precisely olcott <polcott333@gmail.com> - 2025-10-31 23:37 -0500
Re: Semantic properties of finite string inputs --- More precisely Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 07:47 +0000
Re: Semantic properties of finite string inputs --- More precisely olcott <polcott333@gmail.com> - 2025-11-01 08:22 -0500
Re: Semantic properties of finite string inputs --- More precisely Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 16:54 +0000
Re: Semantic properties of finite string inputs --- More precisely olcott <polcott333@gmail.com> - 2025-11-01 12:50 -0500
Re: Semantic properties of finite string inputs --- More precisely Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 20:59 +0000
Re: Semantic properties of finite string inputs --- More precisely olcott <polcott333@gmail.com> - 2025-11-01 16:32 -0500
Re: Semantic properties of finite string inputs --- More precisely "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-01 14:37 -0700
Re: Semantic properties of finite string inputs --- More precisely Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 22:11 +0000
Re: Semantic properties of finite string inputs --- More precisely olcott <polcott333@gmail.com> - 2025-11-01 17:17 -0500
Re: Semantic properties of finite string inputs --- More precisely Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 23:51 +0000
Re: Semantic properties of finite string inputs --- More precisely Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 18:14 +0000
Re: Semantic properties of finite string inputs --- deliberately misleading olcott <polcott333@gmail.com> - 2025-11-01 13:38 -0500
Re: Semantic properties of finite string inputs --- deliberately misleading dbush <dbush.mobile@gmail.com> - 2025-11-01 14:45 -0400
Re: Semantic properties of finite string inputs --- deliberately misleading olcott <polcott333@gmail.com> - 2025-11-01 14:01 -0500
Re: Semantic properties of finite string inputs --- deliberately misleading dbush <dbush.mobile@gmail.com> - 2025-11-01 15:05 -0400
Re: Semantic properties of finite string inputs --- deliberately misleading olcott <polcott333@gmail.com> - 2025-11-01 14:13 -0500
Re: Semantic properties of finite string inputs --- deliberately misleading Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 22:46 +0000
Re: Semantic properties of finite string inputs --- olcott <polcott333@gmail.com> - 2025-11-01 17:50 -0500
Re: Semantic properties of finite string inputs --- Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 23:47 +0000
Re: Semantic properties of finite string inputs --- olcott <polcott333@gmail.com> - 2025-11-01 18:56 -0500
Re: Semantic properties of finite string inputs --- Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-02 00:12 +0000
Re: Semantic properties of finite string inputs --- olcott <polcott333@gmail.com> - 2025-11-01 19:18 -0500
Re: Semantic properties of finite string inputs --- Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-02 00:50 +0000
Re: Semantic properties of finite string inputs --- olcott <polcott333@gmail.com> - 2025-11-01 20:13 -0500
Re: Semantic properties of finite string inputs --- Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-02 02:40 +0000
Re: Semantic properties of finite string inputs --- olcott <polcott333@gmail.com> - 2025-11-01 21:49 -0500
Re: Semantic properties of finite string inputs --- Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-02 17:47 +0000
Re: Semantic properties of finite string inputs --- Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-02 07:39 +0000
Re: Semantic properties of finite string inputs --- olcott <polcott333@gmail.com> - 2025-11-02 07:19 -0600
Re: Semantic properties of finite string inputs --- deliberately misleading dbush <dbush.mobile@gmail.com> - 2025-11-01 22:13 -0400
Re: Semantic properties of finite string inputs --- deliberately misleading Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 22:19 +0000
Re: Semantic properties of finite string inputs --- olcott <polcott333@gmail.com> - 2025-11-01 17:31 -0500
Re: Semantic properties of finite string inputs --- Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-02 17:57 +0000
Re: Semantic properties of finite string inputs --- deliberately misleading Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 22:36 +0000
Re: Semantic properties of finite string inputs --- deliberately misleading olcott <polcott333@gmail.com> - 2025-11-01 17:38 -0500
Re: Semantic properties of finite string inputs --- deliberately misleading Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-02 07:43 +0000
Re: Semantic properties of finite string inputs --- deliberately misleading Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 22:59 +0000
Re: Semantic properties of finite string inputs --- deliberately misleading olcott <polcott333@gmail.com> - 2025-11-01 18:09 -0500
Re: Semantic properties of finite string inputs --- deliberately misleading Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-02 22:32 +0000
Re: Semantic properties of finite string inputs --- deliberately misleading "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-01 19:51 -0700
Re: Semantic properties of finite string inputs --- deliberately misleading "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-01 12:50 -0700
Re: Semantic properties of finite string inputs --- deliberately misleading Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 20:23 +0000
Re: Semantic properties of finite string inputs --- deliberately misleading olcott <polcott333@gmail.com> - 2025-11-01 15:32 -0500
Re: Semantic properties of finite string inputs --- deliberately misleading Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 21:16 +0000
Re: Semantic properties of finite string inputs --- deliberately misleading Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 22:00 +0000
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 03:38 +0000
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-11-01 00:19 -0400
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-31 17:37 -0500
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 23:16 +0000
Re: Semantic properties of finite string inputs dbush <dbush.mobile@gmail.com> - 2025-10-31 19:38 -0400
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 01:05 +0000
Re: Semantic properties of finite string inputs Richard Heathfield <rjh@cpax.org.uk> - 2025-11-01 02:38 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-31 21:43 -0500
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-10-31 22:17 -0400
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-31 12:48 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-31 08:58 -0500
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-31 17:43 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-31 13:25 -0500
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-10-31 22:26 -0400
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 17:49 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-31 17:38 -0500
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 23:06 +0000
Monty Python (Was: Semantic properties of finite string inputs) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 20:30 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 15:36 -0500
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-10-31 14:06 -0400
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-31 19:57 +0000
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-10-31 22:32 -0400
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 20:36 +0000
Re: Semantic properties of finite string inputs James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-11-02 20:49 -0500
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-11-02 22:44 -0500
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-03 17:32 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-03 11:57 -0600
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-11-02 22:48 -0500
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 03:46 +0000
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-10-31 12:17 -0400
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-31 11:51 -0500
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-10-31 13:42 -0400
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-31 13:45 -0500
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-31 20:10 +0000
Re: Semantic properties of finite string inputs --- many months of careful crafting olcott <polcott333@gmail.com> - 2025-10-31 16:00 -0500
Re: Semantic properties of finite string inputs --- many months of careful crafting Richard Damon <Richard@Damon-Family.org> - 2025-10-31 22:45 -0400
Re: Semantic properties of finite string inputs --- many months of careful crafting Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 21:39 +0000
Re: Semantic properties of finite string inputs --- many months of careful crafting joes <noreply@example.org> - 2025-11-01 12:01 +0000
Re: Semantic properties of finite string inputs --- many months of careful crafting olcott <polcott333@gmail.com> - 2025-11-01 08:14 -0500
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-10-31 22:38 -0400
Re: Semantic properties of finite string inputs joes <noreply@example.org> - 2025-11-01 12:10 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 08:18 -0500
Re: Semantic properties of finite string inputs joes <noreply@example.org> - 2025-11-01 13:23 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 08:55 -0500
Re: Semantic properties of finite string inputs dbush <dbush.mobile@gmail.com> - 2025-11-01 09:45 -0400
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 22:49 +0000
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 16:59 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 12:53 -0500
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 20:34 +0000
Re: Semantic properties of finite string inputs --- damned liars olcott <polcott333@gmail.com> - 2025-11-01 16:45 -0500
Re: Semantic properties of finite string inputs --- damned liars Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 23:40 +0000
Re: Semantic properties of finite string inputs --- Breakthrough olcott <polcott333@gmail.com> - 2025-11-01 17:11 -0500
Re: Semantic properties of finite string inputs --- Breakthrough Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 23:33 +0000
Re: Semantic properties of finite string inputs --- Breakthrough olcott <polcott333@gmail.com> - 2025-11-01 18:42 -0500
Re: Semantic properties of finite string inputs --- Breakthrough Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 23:58 +0000
Re: Semantic properties of finite string inputs --- Breakthrough olcott <polcott333@gmail.com> - 2025-11-01 19:01 -0500
Re: Semantic properties of finite string inputs --- Breakthrough Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-02 00:14 +0000
Re: Semantic properties of finite string inputs --- Breakthrough olcott <polcott333@gmail.com> - 2025-11-01 19:21 -0500
Re: Semantic properties of finite string inputs --- Breakthrough Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-02 01:13 +0000
Re: Semantic properties of finite string inputs --- Breakthrough "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-01 18:27 -0700
Re: Semantic properties of finite string inputs --- Breakthrough Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-02 01:59 +0000
Re: Semantic properties of finite string inputs --- Breakthrough "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-01 19:24 -0700
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 17:10 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 12:15 -0500
Re: Semantic properties of finite string inputs Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-11-01 17:25 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 12:29 -0500
Re: Semantic properties of finite string inputs Richard Heathfield <rjh@cpax.org.uk> - 2025-11-01 18:03 +0000
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 20:38 +0000
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-31 17:46 +0000
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-10-31 13:57 -0400
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-31 20:16 +0000
Re: Semantic properties of finite string inputs "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-31 13:26 -0700
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-31 20:43 +0000
Re: Semantic properties of finite string inputs "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-31 13:57 -0700
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-10-31 16:06 -0500
Re: Semantic properties of finite string inputs "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-31 14:22 -0700
Re: Semantic properties of finite string inputs joes <noreply@example.org> - 2025-11-01 11:55 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 08:12 -0500
Re: Semantic properties of finite string inputs joes <noreply@example.org> - 2025-11-01 13:26 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 08:56 -0500
Re: Semantic properties of finite string inputs "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-31 14:23 -0700
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-10-31 22:50 -0400
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 21:47 +0000
Re: Semantic properties of finite string inputs Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-01 00:38 +0000
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 21:50 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 16:57 -0500
Re: Semantic properties of finite string inputs Richard Damon <Richard@Damon-Family.org> - 2025-10-31 22:49 -0400
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 21:54 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 16:59 -0500
Re: Semantic properties of finite string inputs Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-01 22:28 +0000
Re: Semantic properties of finite string inputs Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-11-01 13:44 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 08:57 -0500
Re: Semantic properties of finite string inputs Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-11-01 16:07 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 12:07 -0500
Re: Semantic properties of finite string inputs Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-11-01 17:26 +0000
Re: Semantic properties of finite string inputs olcott <polcott333@gmail.com> - 2025-11-01 12:31 -0500
Re: Semantic properties of finite string inputs "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-01 12:42 -0700
Page 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
| From | Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> |
|---|---|
| Date | 2025-11-01 02:47 +0000 |
| Message-ID | <10e3sbc$vibk$1@dont-email.me> |
| In reply to | #134552 |
On 31/10/2025 23:10, Kaz Kylheku wrote: > Nominal equivalence is not good enough if you're trying to prove > something about halting. Suppose that's not what his situation statement for the current topic is for? I do. -- Tristan Wibberley The message body is Copyright (C) 2025 Tristan Wibberley except citations and quotations noted. All Rights Reserved except that you may, of course, cite it academically giving credit to me, distribute it verbatim as part of a usenet system or its archives, and use it to promote my greatness and general superiority without misrepresentation of my opinions other than my opinion of my greatness and general superiority which you _may_ misrepresent. You definitely MAY NOT train any production AI system with it but you may train experimental AI that will only be used for evaluation of the AI methods it implements.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2025-11-01 00:14 -0400 |
| Message-ID | <dOfNQ.94673$fBxc.73628@fx08.iad> |
| In reply to | #134588 |
On 10/31/25 10:47 PM, Tristan Wibberley wrote: > On 31/10/2025 23:10, Kaz Kylheku wrote: > >> Nominal equivalence is not good enough if you're trying to prove >> something about halting. > > Suppose that's not what his situation statement for the current topic is > for? I do. > > -- > Tristan Wibberley That is part of his problem, NOTHING he talks about is actualy about halting, as he just ignores the definitons needed to talk about halting. He wants someone to say something that he can misuse to try to support his theory to claim it is actually about halting, when it never was.
[toc] | [prev] | [next] | [standalone]
| From | Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> |
|---|---|
| Date | 2025-11-01 18:09 +0000 |
| Message-ID | <10e5ibt$1eurs$1@dont-email.me> |
| In reply to | #134619 |
On 01/11/2025 04:14, Richard Damon wrote: > ... NOTHING he talks about is actualy about > halting, as he just ignores the definitons needed to talk about halting. It doesn't have to be about halting, it's comp.theory not halt.theory. > He wants someone to say something that he can misuse to try to support > his theory to claim it is actually about halting, when it never was. Suppose for a moment, if you can bring yourself to do so, that he's normal; then he will have multiple topics of research at once: they and their number will vary over time. -- Tristan Wibberley The message body is Copyright (C) 2025 Tristan Wibberley except citations and quotations noted. All Rights Reserved except that you may, of course, cite it academically giving credit to me, distribute it verbatim as part of a usenet system or its archives, and use it to promote my greatness and general superiority without misrepresentation of my opinions other than my opinion of my greatness and general superiority which you _may_ misrepresent. You definitely MAY NOT train any production AI system with it but you may train experimental AI that will only be used for evaluation of the AI methods it implements.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-01 12:53 -0700 |
| Message-ID | <10e5ogc$1gpab$3@dont-email.me> |
| In reply to | #134702 |
On 11/1/2025 11:09 AM, Tristan Wibberley wrote: > On 01/11/2025 04:14, Richard Damon wrote: > >> ... NOTHING he talks about is actualy about >> halting, as he just ignores the definitons needed to talk about halting. > > It doesn't have to be about halting, it's comp.theory not halt.theory. > >> He wants someone to say something that he can misuse to try to support >> his theory to claim it is actually about halting, when it never was. > > Suppose for a moment, if you can bring yourself to do so, that he's > normal; then he will have multiple topics of research at once: they and > their number will vary over time. Are you sure your not Olcott? Humm...
[toc] | [prev] | [next] | [standalone]
| From | Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> |
|---|---|
| Date | 2025-11-01 20:15 +0000 |
| Subject | A decider for the proposition "Tristan is Olcott" (Was: Semantic properties of finite string inputs) |
| Message-ID | <10e5ppi$1i3jo$2@dont-email.me> |
| In reply to | #134720 |
On 01/11/2025 19:53, Chris M. Thomasson wrote: >> Suppose for a moment, if you can bring yourself to do so, that he's >> normal; then he will have multiple topics of research at once: they and >> their number will vary over time. > > Are you sure your not Olcott? Humm... A decider CMT accepts usenet posts as input and reports "No TW is not Olcott." -- Tristan Wibberley The message body is Copyright (C) 2025 Tristan Wibberley except citations and quotations noted. All Rights Reserved except that you may, of course, cite it academically giving credit to me, distribute it verbatim as part of a usenet system or its archives, and use it to promote my greatness and general superiority without misrepresentation of my opinions other than my opinion of my greatness and general superiority which you _may_ misrepresent. You definitely MAY NOT train any production AI system with it but you may train experimental AI that will only be used for evaluation of the AI methods it implements.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-01 14:06 -0700 |
| Subject | Re: A decider for the proposition "Tristan is Olcott" (Was: Semantic properties of finite string inputs) |
| Message-ID | <10e5so8$1irmc$2@dont-email.me> |
| In reply to | #134723 |
On 11/1/2025 1:15 PM, Tristan Wibberley wrote: > On 01/11/2025 19:53, Chris M. Thomasson wrote: >>> Suppose for a moment, if you can bring yourself to do so, that he's >>> normal; then he will have multiple topics of research at once: they and >>> their number will vary over time. >> >> Are you sure your not Olcott? Humm... > > A decider CMT accepts usenet posts as input and reports "No TW is not > Olcott." Okay. Just checking. lol. Sorry.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2025-10-31 22:13 -0400 |
| Message-ID | <y1eNQ.224672$ol44.30188@fx33.iad> |
| In reply to | #134533 |
On 10/31/25 3:46 PM, Tristan Wibberley wrote: > On 31/10/2025 18:00, Kaz Kylheku wrote: >> An algorithm recognizing the presence of itself in its input is an >> undecidable problem. > > An algorithm recognizing the presence of a specific nominal expression > of itself is not. But who says the copy has the same nominal expression? And, WHICH of the expression of the decider are you comparing to? Remember, when you are actually rumming the machines, you don't have an expression of them, you have the actual mathematical machines, not a symbolic expression of them. Your seem to forget that Turing Machines *ARE* the processor, not just a program. > > -- > Tristan Wibberley > > The message body is Copyright (C) 2025 Tristan Wibberley except > citations and quotations noted. All Rights Reserved except that you may, > of course, cite it academically giving credit to me, distribute it > verbatim as part of a usenet system or its archives, and use it to > promote my greatness and general superiority without misrepresentation > of my opinions other than my opinion of my greatness and general > superiority which you _may_ misrepresent. You definitely MAY NOT train > any production AI system with it but you may train experimental AI that > will only be used for evaluation of the AI methods it implements. >
[toc] | [prev] | [next] | [standalone]
| From | Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> |
|---|---|
| Date | 2025-11-01 02:53 +0000 |
| Message-ID | <10e3sn3$vibk$2@dont-email.me> |
| In reply to | #134579 |
On 01/11/2025 02:13, Richard Damon wrote: > On 10/31/25 3:46 PM, Tristan Wibberley wrote: >> On 31/10/2025 18:00, Kaz Kylheku wrote: >>> An algorithm recognizing the presence of itself in its input is an >>> undecidable problem. >> >> An algorithm recognizing the presence of a specific nominal expression >> of itself is not. > > But who says the copy has the same nominal expression? The author of the situation statement. > And, WHICH of the expression of the decider are you comparing to? The one and only one he gave in the input string "H". There's no other to consider. The situation statement describes one in which the input string specifies calling H(D), and provides for a C interpreter in which the call remains recognisable. It does not provide for any generality in the decision that there's a loop of more than 5 calls. If there is a challenge for us, it is to notice that those are the facts of this particular situation statement. -- Tristan Wibberley The message body is Copyright (C) 2025 Tristan Wibberley except citations and quotations noted. All Rights Reserved except that you may, of course, cite it academically giving credit to me, distribute it verbatim as part of a usenet system or its archives, and use it to promote my greatness and general superiority without misrepresentation of my opinions other than my opinion of my greatness and general superiority which you _may_ misrepresent. You definitely MAY NOT train any production AI system with it but you may train experimental AI that will only be used for evaluation of the AI methods it implements.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-31 21:58 -0500 |
| Subject | Re: Semantic properties of finite string inputs --- More precisely |
| Message-ID | <10e3t0b$vkhk$3@dont-email.me> |
| In reply to | #134593 |
On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
> On 01/11/2025 02:13, Richard Damon wrote:
>> On 10/31/25 3:46 PM, Tristan Wibberley wrote:
>>> On 31/10/2025 18:00, Kaz Kylheku wrote:
>>>> An algorithm recognizing the presence of itself in its input is an
>>>> undecidable problem.
>>>
>>> An algorithm recognizing the presence of a specific nominal expression
>>> of itself is not.
>>
>> But who says the copy has the same nominal expression?
>
> The author of the situation statement.
>
>> And, WHICH of the expression of the decider are you comparing to?
>
> The one and only one he gave in the input string "H". There's no other
> to consider.
>
> The situation statement describes one in which the input string
> specifies calling H(D), and provides for a C interpreter in which the
> call remains recognisable.
>
> It does not provide for any generality in the decision that there's a
> loop of more than 5 calls.
>
> If there is a challenge for us, it is to notice that those are the facts
> of this particular situation statement.
>
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
D simulated by H according to the semantics of C
programming language (until H sees the repeating
pattern) does enable H to report that its simulated
input cannot possibly reach its own simulated
"return" statement final halt state.
> --
> Tristan Wibberley
>
> The message body is Copyright (C) 2025 Tristan Wibberley except
> citations and quotations noted. All Rights Reserved except that you may,
> of course, cite it academically giving credit to me, distribute it
> verbatim as part of a usenet system or its archives, and use it to
> promote my greatness and general superiority without misrepresentation
> of my opinions other than my opinion of my greatness and general
> superiority which you _may_ misrepresent. You definitely MAY NOT train
> any production AI system with it but you may train experimental AI that
> will only be used for evaluation of the AI methods it implements.
>
--
Copyright 2025 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 | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-01 04:23 +0000 |
| Subject | Re: Semantic properties of finite string inputs --- More precisely |
| Message-ID | <20251031212218.459@kylheku.com> |
| In reply to | #134594 |
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
> On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
>> On 01/11/2025 02:13, Richard Damon wrote:
>>> On 10/31/25 3:46 PM, Tristan Wibberley wrote:
>>>> On 31/10/2025 18:00, Kaz Kylheku wrote:
>>>>> An algorithm recognizing the presence of itself in its input is an
>>>>> undecidable problem.
>>>>
>>>> An algorithm recognizing the presence of a specific nominal expression
>>>> of itself is not.
>>>
>>> But who says the copy has the same nominal expression?
>>
>> The author of the situation statement.
>>
>>> And, WHICH of the expression of the decider are you comparing to?
>>
>> The one and only one he gave in the input string "H". There's no other
>> to consider.
>>
>> The situation statement describes one in which the input string
>> specifies calling H(D), and provides for a C interpreter in which the
>> call remains recognisable.
>>
>> It does not provide for any generality in the decision that there's a
>> loop of more than 5 calls.
>>
>> If there is a challenge for us, it is to notice that those are the facts
>> of this particular situation statement.
>>
>
> int D()
> {
> int Halt_Status = H(D);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> D simulated by H according to the semantics of C
> programming language (until H sees the repeating
> pattern) does enable H to report that its simulated
> input cannot possibly reach its own simulated
> "return" statement final halt state.
You have used up the name H for something else already;
do not confuse things by claiming H just simulates now!
From your Halt7.c, February 2025 commit:
// Original version of H that uses static local data and is
// capable of recursive simulations. I restored this one
// because it was too difficult for people to see that H(P,P)
// matches the infinite recursion behavior pattern with only
// a single call from, P to H(P,P).
//
u32 H(ptr P, ptr I) // 2024-09-15 was HH
{
u32* Aborted;
u32* execution_trace;
u32 End_Of_Code;
goto SKIP;
DATA1:
#ifdef _WIN32
__asm nop // The purpose of creating static local memory
__asm nop // directly in the function body is to make it
__asm nop // clear that a Turing machine computatation has
__asm nop // this ability by simply writing to its own tape
#elif __linux__
__asm__("nop"); // The purpose of creating static local memory
__asm__("nop"); // directly in the function body is to make it
__asm__("nop"); // clear that a Turing machine computatation has
__asm__("nop"); // this ability by simply writing to its own tape
#endif
DATA2:
#ifdef _WIN32
__asm nop // The purpose of creating static local memory
__asm nop // directly in the function body is to make it
__asm nop // clear that a Turing machine computatation has
__asm nop // this ability by simply writing to its own tape
#elif __linux__
__asm__("nop"); // The purpose of creating static local memory
__asm__("nop"); // directly in the function body is to make it
__asm__("nop"); // clear that a Turing machine computatation has
__asm__("nop"); // this ability by simply writing to its own tape
#endif
SKIP:
#ifdef _WIN32
__asm lea eax, DATA1
__asm mov Aborted, eax // Data stored directly in the function body
__asm lea eax, DATA2
__asm mov execution_trace, eax // Data stored directly in the function body
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
#elif __linux__
__asm__("lea eax, DATA1");
__asm__("mov Aborted, eax"); // Data stored directly in the function body
__asm__("lea eax, DATA2");
__asm__("mov execution_trace, eax"); // Data stored directly in the function body
__asm__("mov eax, END_OF_CODE");
__asm__("mov End_Of_Code, eax");
#endif
Decoded_Line_Of_Code *decoded;
u32 code_end;
Registers* master_state;
Registers* slave_state;
u32* slave_stack;
u32 Root = Init_Halts_HH(&Aborted, &execution_trace, &decoded, &code_end, (u32)P,
&master_state, &slave_state, &slave_stack);
//Output("H_Root:", Root);
Init_slave_state((u32)P, (u32)I, End_Of_Code, slave_state, slave_stack);
if (Decide_Halting_HH(&Aborted, &execution_trace, &decoded,
code_end, End_Of_Code, &master_state,
&slave_state, &slave_stack, Root))
goto END_OF_CODE;
// Output_Decoded_Instructions(*execution_trace);
*Aborted = 0x90909090;
*execution_trace = 0x90909090;
return 0; // Does not halt
END_OF_CODE:
// Output_Decoded_Instructions(*execution_trace);
*Aborted = 0x90909090;
*execution_trace = 0x90909090;
return 1; // Input has normally terminated
}
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-31 23:37 -0500 |
| Subject | Re: Semantic properties of finite string inputs --- More precisely |
| Message-ID | <10e42qu$115hq$1@dont-email.me> |
| In reply to | #134622 |
On 10/31/2025 11:23 PM, Kaz Kylheku wrote:
> On 2025-11-01, olcott <polcott333@gmail.com> wrote:
>> On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
>>> On 01/11/2025 02:13, Richard Damon wrote:
>>>> On 10/31/25 3:46 PM, Tristan Wibberley wrote:
>>>>> On 31/10/2025 18:00, Kaz Kylheku wrote:
>>>>>> An algorithm recognizing the presence of itself in its input is an
>>>>>> undecidable problem.
>>>>>
>>>>> An algorithm recognizing the presence of a specific nominal expression
>>>>> of itself is not.
>>>>
>>>> But who says the copy has the same nominal expression?
>>>
>>> The author of the situation statement.
>>>
>>>> And, WHICH of the expression of the decider are you comparing to?
>>>
>>> The one and only one he gave in the input string "H". There's no other
>>> to consider.
>>>
>>> The situation statement describes one in which the input string
>>> specifies calling H(D), and provides for a C interpreter in which the
>>> call remains recognisable.
>>>
>>> It does not provide for any generality in the decision that there's a
>>> loop of more than 5 calls.
>>>
>>> If there is a challenge for us, it is to notice that those are the facts
>>> of this particular situation statement.
>>>
>>
>> int D()
>> {
>> int Halt_Status = H(D);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> D simulated by H according to the semantics of C
>> programming language (until H sees the repeating
>> pattern) does enable H to report that its simulated
>> input cannot possibly reach its own simulated
>> "return" statement final halt state.
>
> You have used up the name H for something else already;
> do not confuse things by claiming H just simulates now!
>
That is the same as this one that has been dumbed down
You can't possible provide a correct execution trace
in C because you know that will prove you stupidly wrong.
H simulates D that calls H(D)
and according to your magic proof somehow
reaches its own simulated return instruction.
You cannot show the steps in C only because
you know that you are a liar.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0 to reject its input as non-halting.
--
Copyright 2025 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 | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-01 07:47 +0000 |
| Subject | Re: Semantic properties of finite string inputs --- More precisely |
| Message-ID | <20251101003957.99@kylheku.com> |
| In reply to | #134624 |
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
> On 10/31/2025 11:23 PM, Kaz Kylheku wrote:
>> On 2025-11-01, olcott <polcott333@gmail.com> wrote:
>>> On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
>>>> On 01/11/2025 02:13, Richard Damon wrote:
>>>>> On 10/31/25 3:46 PM, Tristan Wibberley wrote:
>>>>>> On 31/10/2025 18:00, Kaz Kylheku wrote:
>>>>>>> An algorithm recognizing the presence of itself in its input is an
>>>>>>> undecidable problem.
>>>>>>
>>>>>> An algorithm recognizing the presence of a specific nominal expression
>>>>>> of itself is not.
>>>>>
>>>>> But who says the copy has the same nominal expression?
>>>>
>>>> The author of the situation statement.
>>>>
>>>>> And, WHICH of the expression of the decider are you comparing to?
>>>>
>>>> The one and only one he gave in the input string "H". There's no other
>>>> to consider.
>>>>
>>>> The situation statement describes one in which the input string
>>>> specifies calling H(D), and provides for a C interpreter in which the
>>>> call remains recognisable.
>>>>
>>>> It does not provide for any generality in the decision that there's a
>>>> loop of more than 5 calls.
>>>>
>>>> If there is a challenge for us, it is to notice that those are the facts
>>>> of this particular situation statement.
>>>>
>>>
>>> int D()
>>> {
>>> int Halt_Status = H(D);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> D simulated by H according to the semantics of C
>>> programming language (until H sees the repeating
>>> pattern) does enable H to report that its simulated
>>> input cannot possibly reach its own simulated
>>> "return" statement final halt state.
>>
>> You have used up the name H for something else already;
>> do not confuse things by claiming H just simulates now!
>>
>
> That is the same as this one that has been dumbed down
> You can't possible provide a correct execution trace
> in C because you know that will prove you stupidly wrong.
>
> H simulates D that calls H(D)
> and according to your magic proof somehow
> reaches its own simulated return instruction.
>
> You cannot show the steps in C only because
> you know that you are a liar.
/I/ cannot show the steps in C only precisely because /you/ cannot show
the steps in C only.
I have only the C-to-x86 thing you made, remember?
I added a small amount of code to it to continue the executions
that your existing code sets up.
Once you have your C-only simulation machine, and make it public,
the same thing will be shown.
I mean, after you. You show me your C-only execution trace
where up to where H reaches the abort criteria and stops simulating.
Until you have that, you have no claim that is substantiated
by execution traces, and I have nothing to do.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-01 08:22 -0500 |
| Subject | Re: Semantic properties of finite string inputs --- More precisely |
| Message-ID | <10e51i7$19jfq$2@dont-email.me> |
| In reply to | #134630 |
On 11/1/2025 2:47 AM, Kaz Kylheku wrote:
> On 2025-11-01, olcott <polcott333@gmail.com> wrote:
>> On 10/31/2025 11:23 PM, Kaz Kylheku wrote:
>>> On 2025-11-01, olcott <polcott333@gmail.com> wrote:
>>>> On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
>>>>> On 01/11/2025 02:13, Richard Damon wrote:
>>>>>> On 10/31/25 3:46 PM, Tristan Wibberley wrote:
>>>>>>> On 31/10/2025 18:00, Kaz Kylheku wrote:
>>>>>>>> An algorithm recognizing the presence of itself in its input is an
>>>>>>>> undecidable problem.
>>>>>>>
>>>>>>> An algorithm recognizing the presence of a specific nominal expression
>>>>>>> of itself is not.
>>>>>>
>>>>>> But who says the copy has the same nominal expression?
>>>>>
>>>>> The author of the situation statement.
>>>>>
>>>>>> And, WHICH of the expression of the decider are you comparing to?
>>>>>
>>>>> The one and only one he gave in the input string "H". There's no other
>>>>> to consider.
>>>>>
>>>>> The situation statement describes one in which the input string
>>>>> specifies calling H(D), and provides for a C interpreter in which the
>>>>> call remains recognisable.
>>>>>
>>>>> It does not provide for any generality in the decision that there's a
>>>>> loop of more than 5 calls.
>>>>>
>>>>> If there is a challenge for us, it is to notice that those are the facts
>>>>> of this particular situation statement.
>>>>>
>>>>
>>>> int D()
>>>> {
>>>> int Halt_Status = H(D);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> D simulated by H according to the semantics of C
>>>> programming language (until H sees the repeating
>>>> pattern) does enable H to report that its simulated
>>>> input cannot possibly reach its own simulated
>>>> "return" statement final halt state.
>>>
>>> You have used up the name H for something else already;
>>> do not confuse things by claiming H just simulates now!
>>>
>>
>> That is the same as this one that has been dumbed down
>> You can't possible provide a correct execution trace
>> in C because you know that will prove you stupidly wrong.
>>
>> H simulates D that calls H(D)
>> and according to your magic proof somehow
>> reaches its own simulated return instruction.
>>
>> You cannot show the steps in C only because
>> you know that you are a liar.
>
> /I/ cannot show the steps in C only precisely because /you/ cannot show
> the steps in C only.
>
I did show the execution trace in C and then
you erased this and lied about it. That might
get you condemned to actual Hell if such a
place exists.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0 to reject its input as non-halting.
--
Copyright 2025 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 | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-01 16:54 +0000 |
| Subject | Re: Semantic properties of finite string inputs --- More precisely |
| Message-ID | <20251101094810.895@kylheku.com> |
| In reply to | #134655 |
On 2025-11-01, olcott <polcott333@gmail.com> wrote: >> /I/ cannot show the steps in C only precisely because /you/ cannot show >> the steps in C only. >> > > I did show the execution trace in C and then You positively did not; you showed something you wrote by hand. You must show an actual trace from a C interpreter, which can interpret itself interpreting C. Then when you provide the URL to the GitHub repository (or other hosting place), I may take a look at it. Until then, you are only pushing empty air from under your keyboard membrane, in order to dodging the reality that the x86utm now has a way of identifying and continuing abandoned simulations after the test case announces a decision, and can show those decisions to be incorrect. The same thing can be worked into a system based on interpreting C abstract syntax, rather than x86 code. The issue already exists in your adaptation of Linz. There we also have an abandoned state machine which has actually has a halting state. The C interpreter system will be extensible with a way to identify interpretations that havre have abandoned by a decision procedure that proclaimed them to be nonterminating, and potentially show them to be terminating. Your entire program based on the wrong adaptation of that page 319 from Linz is washed up. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-01 12:50 -0500 |
| Subject | Re: Semantic properties of finite string inputs --- More precisely |
| Message-ID | <10e5h8t$1emqd$1@dont-email.me> |
| In reply to | #134687 |
On 11/1/2025 11:54 AM, Kaz Kylheku wrote:
> On 2025-11-01, olcott <polcott333@gmail.com> wrote:
>>> /I/ cannot show the steps in C only precisely because /you/ cannot show
>>> the steps in C only.
>>>
>>
>> I did show the execution trace in C and then
>
> You positively did not; you showed something you wrote by hand.
>
Anyone with these credentials could certainly show the
execution trace in C of the steps of how D simulated
by H reaches its own simulated "return" statement.
On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
> I can write a C interpreter which can interpret itself.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) then what?
--
Copyright 2025 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 | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-01 20:59 +0000 |
| Subject | Re: Semantic properties of finite string inputs --- More precisely |
| Message-ID | <20251101133851.710@kylheku.com> |
| In reply to | #134699 |
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
> On 11/1/2025 11:54 AM, Kaz Kylheku wrote:
>> On 2025-11-01, olcott <polcott333@gmail.com> wrote:
>>>> /I/ cannot show the steps in C only precisely because /you/ cannot show
>>>> the steps in C only.
>>>>
>>>
>>> I did show the execution trace in C and then
>>
>> You positively did not; you showed something you wrote by hand.
>>
>
> Anyone with these credentials could certainly show the
> execution trace in C of the steps of how D simulated
> by H reaches its own simulated "return" statement.
>
> On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
> > I can write a C interpreter which can interpret itself.
>
> int D()
> {
> int Halt_Status = H(D);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> H simulates D then D calls H(D) then what?
We need an impementation of H to show the detailed trace.
Let's assume that we have primitives built into the
framework for managing simulations: interp_create,
interp_step.
Let's start with a non-aborting H:
int H(ptr P)
{
interp *s = interp_create(P);
while (interp_step(s)) { }
return 1;
}
H simulates D, trace:
Step: Trace: Vars:
1. { int Halt_Status = H(D); ... } Halt_Status = <uninited>
2. { ... H(D); ... }
3. { interp *s = interp_create(P); ... } P = D; s = <uninited>
4. { interp_create(P); ... }
5. { interp *s = <sim_value>; while ... } P = D; s = <sim_obj>
6 { while (interp_step(s)) ... } P = D; s = <sim_obj>
7 { interp_step(s); }
At ths point, a nested interpretation of P starts and is stepped.
It has not terminated so true is returned by interp_step:
1. { int Halt_Status = H(D); ... } Halt_Status = <uninited>
We are back in the outer simulation after one step: interp_step(s)
has returned true:
7 { while (<true>) { } ... }
Empty body of while is executed:
8. { { } ... }
Back to top of while
9. { while (interp_step(s)) ... } P = D; s = <sim_obj>
Nested simulation steps:
2. { ... H(D); ... }
10. { while (<true>) { } ... }
11. { { } ... }
12. { while (interp_step(s)) ... } P = D; s = <sim_obj>
This is getting boring, shall we keep going? The nested
simulation s is about to call H(D) which will create one more
nested simulation, but it keeps going like this.
At this point, there is zero effort comign from your side.
You've not looked at the code added to the x86utm to continue
abandoned simulations.
Now you're having me show C statement traces.
All the while you do fuck all, other than calling people liars
and other name calling.
You appear to be finished. Washed up.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-01 16:32 -0500 |
| Subject | Re: Semantic properties of finite string inputs --- More precisely |
| Message-ID | <10e5uaa$1jn51$1@dont-email.me> |
| In reply to | #134738 |
On 11/1/2025 3:59 PM, Kaz Kylheku wrote:
> On 2025-11-01, olcott <polcott333@gmail.com> wrote:
>> On 11/1/2025 11:54 AM, Kaz Kylheku wrote:
>>> On 2025-11-01, olcott <polcott333@gmail.com> wrote:
>>>>> /I/ cannot show the steps in C only precisely because /you/ cannot show
>>>>> the steps in C only.
>>>>>
>>>>
>>>> I did show the execution trace in C and then
>>>
>>> You positively did not; you showed something you wrote by hand.
>>>
>>
>> Anyone with these credentials could certainly show the
>> execution trace in C of the steps of how D simulated
>> by H reaches its own simulated "return" statement.
>>
>> On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
>>> I can write a C interpreter which can interpret itself.
>>
>> int D()
>> {
>> int Halt_Status = H(D);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> H simulates D then D calls H(D) then what?
>
> We need an impementation of H to show the detailed trace.
>
> Let's assume that we have primitives built into the
> framework for managing simulations: interp_create,
> interp_step.
>
> Let's start with a non-aborting H:
>
Just the C and nothing else.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) then what?
I know that you are trying to make it as
confusing as possible. I will not tolerate that.
--
Copyright 2025 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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-01 14:37 -0700 |
| Subject | Re: Semantic properties of finite string inputs --- More precisely |
| Message-ID | <10e5uif$1irme$1@dont-email.me> |
| In reply to | #134743 |
On 11/1/2025 2:32 PM, olcott wrote:
> On 11/1/2025 3:59 PM, Kaz Kylheku wrote:
>> On 2025-11-01, olcott <polcott333@gmail.com> wrote:
>>> On 11/1/2025 11:54 AM, Kaz Kylheku wrote:
>>>> On 2025-11-01, olcott <polcott333@gmail.com> wrote:
>>>>>> /I/ cannot show the steps in C only precisely because /you/ cannot
>>>>>> show
>>>>>> the steps in C only.
>>>>>>
>>>>>
>>>>> I did show the execution trace in C and then
>>>>
>>>> You positively did not; you showed something you wrote by hand.
>>>>
>>>
>>> Anyone with these credentials could certainly show the
>>> execution trace in C of the steps of how D simulated
>>> by H reaches its own simulated "return" statement.
>>>
>>> On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
>>>> I can write a C interpreter which can interpret itself.
>>>
>>> int D()
>>> {
>>> int Halt_Status = H(D);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> H simulates D then D calls H(D) then what?
>>
>> We need an impementation of H to show the detailed trace.
>>
>> Let's assume that we have primitives built into the
>> framework for managing simulations: interp_create,
>> interp_step.
>>
>> Let's start with a non-aborting H:
>>
>
> Just the C and nothing else.
>
> int D()
> {
> int Halt_Status = H(D);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
Show H in C, see?
>
> H simulates D then D calls H(D) then what?
>
> I know that you are trying to make it as
> confusing as possible. I will not tolerate that.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-01 22:11 +0000 |
| Subject | Re: Semantic properties of finite string inputs --- More precisely |
| Message-ID | <20251101150608.149@kylheku.com> |
| In reply to | #134743 |
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
> On 11/1/2025 3:59 PM, Kaz Kylheku wrote:
>> On 2025-11-01, olcott <polcott333@gmail.com> wrote:
>>> On 11/1/2025 11:54 AM, Kaz Kylheku wrote:
>>>> On 2025-11-01, olcott <polcott333@gmail.com> wrote:
>>>>>> /I/ cannot show the steps in C only precisely because /you/ cannot show
>>>>>> the steps in C only.
>>>>>>
>>>>>
>>>>> I did show the execution trace in C and then
>>>>
>>>> You positively did not; you showed something you wrote by hand.
>>>>
>>>
>>> Anyone with these credentials could certainly show the
>>> execution trace in C of the steps of how D simulated
>>> by H reaches its own simulated "return" statement.
>>>
>>> On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
>>>> I can write a C interpreter which can interpret itself.
>>>
>>> int D()
>>> {
>>> int Halt_Status = H(D);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> H simulates D then D calls H(D) then what?
>>
>> We need an impementation of H to show the detailed trace.
>>
>> Let's assume that we have primitives built into the
>> framework for managing simulations: interp_create,
>> interp_step.
>>
>> Let's start with a non-aborting H:
>>
>
> Just the C and nothing else.
I have no idea what you are asking for; I made an attempt in the
above post to follow a statement-by-statement trace, of the above
simulated by H as a C syntax tree.
I had to fill in an imaginary H since you did not supply it.
That H uses primitives provided by the master interpreter:
it assumes that the interpreter can handle certain functions
like interp_create and interp_step. Thus we don't have to
trace into those.
(You did similar things in the x86utm: for instance when a
simulated subject calls DebugTrace, it doesn't actually
call a subroutine; it is a primitive recognized by the
simulator and executes natively.)
> I know that you are trying to make it as
> confusing as possible. I will not tolerate that.
Do you have any questions about the ad hoc C trace
format I made up? Or ... what exactly is confusing?
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-01 17:17 -0500 |
| Subject | Re: Semantic properties of finite string inputs --- More precisely |
| Message-ID | <10e60t4$1kgnu$1@dont-email.me> |
| In reply to | #134754 |
On 11/1/2025 5:11 PM, Kaz Kylheku wrote:
> On 2025-11-01, olcott <polcott333@gmail.com> wrote:
>> On 11/1/2025 3:59 PM, Kaz Kylheku wrote:
>>> On 2025-11-01, olcott <polcott333@gmail.com> wrote:
>>>> On 11/1/2025 11:54 AM, Kaz Kylheku wrote:
>>>>> On 2025-11-01, olcott <polcott333@gmail.com> wrote:
>>>>>>> /I/ cannot show the steps in C only precisely because /you/ cannot show
>>>>>>> the steps in C only.
>>>>>>>
>>>>>>
>>>>>> I did show the execution trace in C and then
>>>>>
>>>>> You positively did not; you showed something you wrote by hand.
>>>>>
>>>>
>>>> Anyone with these credentials could certainly show the
>>>> execution trace in C of the steps of how D simulated
>>>> by H reaches its own simulated "return" statement.
>>>>
>>>> On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
>>>>> I can write a C interpreter which can interpret itself.
>>>>
>>>> int D()
>>>> {
>>>> int Halt_Status = H(D);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> H simulates D then D calls H(D) then what?
>>>
>>> We need an impementation of H to show the detailed trace.
>>>
>>> Let's assume that we have primitives built into the
>>> framework for managing simulations: interp_create,
>>> interp_step.
>>>
>>> Let's start with a non-aborting H:
>>>
>>
>> Just the C and nothing else.
>
> I have no idea what you are asking for;
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) what comes next?
You have no idea that: H simulates D comes next?
--
Copyright 2025 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 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
Back to top | Article view | comp.theory
csiph-web