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 7 of 15 — ← Prev page 1 … 5 6 [7] 8 9 … 15 Next page →
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-04 22:12 +0000 |
| Subject | Re: Semantic properties of finite string inputs --- Kaz made a great test |
| Message-ID | <20251104135919.327@kylheku.com> |
| In reply to | #135031 |
On 2025-11-04, olcott <polcott333@gmail.com> wrote:
> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>> On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
>>>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>>>> What step(s) of D come next in C?
>>>>
>>>> When I posted a detailed symbolic statement-by-statememnt trace using C
>>>> syntax several days ago,
>>> You did not stick with an execution trace of D and only D
>>> showing that and how D reaches its own "return" statement
>>> final halt state when simulated and only simulated by H.
>>
>> It was a warm-up exercise. The example H wasn't the aborting H.
>>
>> You made no remarks on the format: is that a good way or bad
>> way to trace executions of just C.
>>
>> I invented some fictitious API's into the interpreter that H could use
>> for setting up and stepping a simulation; you made no comments about it.
>>
>> The first thing D does when entered is call H(D), so we need an H
>> to trace concretely.
>>
>> How about this minimal viable H:
>>
>> #include <interpret.h> // C interpreter's own API
>>
>> bool H(fptr P)
>> {
>> interp *s = interp_init(P);
>>
>> for (int i = 0; i < 3; i++) {
>> if (interp_step(s))
>> return true;
>> }
>>
>> return false;
>> }
>>
>> H initializes an interpreter for its argument P. Then it applies a very
>> simple abort logic: it steps the interpreter state three times. If
>> during those three steps, P terminates, it returns true. Otherwise it
>> assumes P is nonterminating and returns false.
>>
>> (Pretend that more complicated abort criteria are there.)
>>
>> The interpreter API consists of primitives built into the system, so
>> it isn't traced.
>>
>> So then we have D:
>>
>> void D(void)
>> {
>> if (H(D)) { for (;;); }
>> return;
>> }
>>
>> Let's trace H(D). We indicate the simulation levels from 0,
>> step numbers from 1 within each level, with a bit of indentation
>> to tell apart the levels:
>>
>
> That seems to be a great empirical test.
I'm glad you like this. It is loosely inspired by Common Lisp stepping.
[1]> (step (let ((a 3) (b 4)) (+ a b)))
step 1 --> (LET ((A 3) (B 4)) (+ A B))
Step 1 [2]> :s
step 2 --> 3
Step 2 [3]> :s
step 2 ==> value: 3
step 2 --> 4
Step 2 [4]> :s
step 2 ==> value: 4
step 2 --> (+ A B)
Step 2 [5]> :s
step 3 --> A
Step 3 [6]> :s
step 3 ==> value: 3
step 3 --> B
Step 3 [7]> :s
step 3 ==> value: 4
step 2 ==> value: 7
step 1 ==> value: 7
7
Lisp is the best language for exploring towers of interpreters.
Remember that 1973 Tony Hoare "Incomputability" paper I recently referenced
again; the one in which he and his co-author explore interpreting deciders?
Among the introductory paragraphs, the paper states this:
"In this paper we draw on the programming language LISP [7] for
writing most of the example programs. We have chosen this language
for the following reasons: 1) it is fairly widely known, 2) it is a
small and simple language, 3) it is easy to represent Lisp programs as
data (S-expressions) which can then be manipulated, 4) it is relatively
easy to write an interpreter of the language in Lisp itself, and 5)
it might initially seem to be easy to write a program which tells
whether another program will terminate or not.
In fact, the first specification of Lisp was written as small amount
of Lisp code, on paper. No running implementation existed.
MacCarthy intended it as an abstract specification to guide the project.
(And didn't intend that notation to be usd for programming; he
wanted a different surface syntax.)
Steve Russel, his student, took the specification and hand-translated its
definitions to assembly language. The result was a working interpreter.
MacCarthy was taken aback, thinking there was some mistake; the
spec wasn't meant to be excuted.
If you want to explore nested interpretation using a higher level language, you
are a fool if you use C rather than Lisp, because you're just throwing
irrelevant obstacles in your path.
The representation of code and all the parsing and all that is already
done in Lisp, so you can dive right into the interpretation and related
semantic parts of what you are doing.
>> Level Step Code Vars
>>
>> 0 1 if (H(D)) ...
>> 0 2 H(D)
>> 0 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
>> 0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0
>> 0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
>> 1 1 if (H(D)) ...
>> 0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1
>> 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
>> 1 2 H(D)
>> 0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2
>> 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
>> 1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
>> 0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3
>> 0 9 return false; P = D; s = #<interp0>; i = 3
>>
>> OK, so after those 3 steps, H(D) has returned false. The D simulation
>> proceeded far enough to hit the "interp_init(P)" calculation, to create
>> the next simulation level.
>>
>
> I don't think so
> i == 0 reaches if (interp_step(s))
> i == 1 reaches if (interp_step(s))
> i == 2 reaches if (interp_step(s))
> i == 3 NEVER reaches if (interp_step(s))
> Then bool H(fptr P) returns false.
When the loop hits i == 3, it reaches "return false;".
That first happens at level 0, above. we see this:
0 9 return false; P = D; s = #<interp0>; i = 3
So now we have H's conclusion H(D) returns false.
The #<interp0> simulation exists in the system though; the interesting
thing takes place after that is picked up and continued.
The simulated H(D) also hits i == 3 and return;. But since it is D() being
simulated, that return is still in the simulation: it goes back into D() which
terminates.
--
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-04 16:13 -0600 |
| Subject | Re: Semantic properties of finite string inputs --- Kaz code Deviation |
| Message-ID | <10edtr1$3vp53$1@dont-email.me> |
| In reply to | #134993 |
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>> On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
>>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>>> What step(s) of D come next in C?
>>>
>>> When I posted a detailed symbolic statement-by-statememnt trace using C
>>> syntax several days ago,
>> You did not stick with an execution trace of D and only D
>> showing that and how D reaches its own "return" statement
>> final halt state when simulated and only simulated by H.
>
> It was a warm-up exercise. The example H wasn't the aborting H.
>
> You made no remarks on the format: is that a good way or bad
> way to trace executions of just C.
>
> I invented some fictitious API's into the interpreter that H could use
> for setting up and stepping a simulation; you made no comments about it.
>
> The first thing D does when entered is call H(D), so we need an H
> to trace concretely.
>
> How about this minimal viable H:
>
> #include <interpret.h> // C interpreter's own API
>
> bool H(fptr P)
> {
> interp *s = interp_init(P);
>
> for (int i = 0; i < 3; i++) {
> if (interp_step(s))
> return true;
> }
>
> return false;
> }
>
> H initializes an interpreter for its argument P. Then it applies a very
> simple abort logic: it steps the interpreter state three times. If
> during those three steps, P terminates, it returns true. Otherwise it
> assumes P is nonterminating and returns false.
>
> (Pretend that more complicated abort criteria are there.)
>
> The interpreter API consists of primitives built into the system, so
> it isn't traced.
>
> So then we have D:
>
> void D(void)
> {
> if (H(D)) { for (;;); }
> return;
> }
>
> Let's trace H(D). We indicate the simulation levels from 0,
> step numbers from 1 within each level, with a bit of indentation
> to tell apart the levels:
>
> Level Step Code Vars
>
> 0 1 if (H(D)) ...
> 0 2 H(D)
> 0 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
> 0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0
> 0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
> 1 1 if (H(D)) ...
> 0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1
> 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
> 1 2 H(D)
> 0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2
> 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
> 1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
> 0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3
> 0 9 return false; P = D; s = #<interp0>; i = 3
>
> OK, so after those 3 steps, H(D) has returned false. The D simulation
> proceeded far enough to hit the "interp_init(P)" calculation, to create
> the next simulation level.
>
I don't think so
i == 0 reaches if (interp_step(s))
i == 1 reaches if (interp_step(s))
i == 2 reaches if (interp_step(s))
i == 3 NEVER reaches if (interp_step(s))
Then bool H(fptr P) returns false.
--
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-04 22:33 +0000 |
| Subject | Re: Semantic properties of finite string inputs --- Kaz code Deviation |
| Message-ID | <20251104141933.432@kylheku.com> |
| In reply to | #135034 |
On 2025-11-04, olcott <polcott333@gmail.com> wrote:
> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>> On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
>>>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>>>> What step(s) of D come next in C?
>>>>
>>>> When I posted a detailed symbolic statement-by-statememnt trace using C
>>>> syntax several days ago,
>>> You did not stick with an execution trace of D and only D
>>> showing that and how D reaches its own "return" statement
>>> final halt state when simulated and only simulated by H.
>>
>> It was a warm-up exercise. The example H wasn't the aborting H.
>>
>> You made no remarks on the format: is that a good way or bad
>> way to trace executions of just C.
>>
>> I invented some fictitious API's into the interpreter that H could use
>> for setting up and stepping a simulation; you made no comments about it.
>>
>> The first thing D does when entered is call H(D), so we need an H
>> to trace concretely.
>>
>> How about this minimal viable H:
>>
>> #include <interpret.h> // C interpreter's own API
>>
>> bool H(fptr P)
>> {
>> interp *s = interp_init(P);
>>
>> for (int i = 0; i < 3; i++) {
>> if (interp_step(s))
>> return true;
>> }
>>
>> return false;
>> }
>>
>> H initializes an interpreter for its argument P. Then it applies a very
>> simple abort logic: it steps the interpreter state three times. If
>> during those three steps, P terminates, it returns true. Otherwise it
>> assumes P is nonterminating and returns false.
>>
>> (Pretend that more complicated abort criteria are there.)
>>
>> The interpreter API consists of primitives built into the system, so
>> it isn't traced.
>>
>> So then we have D:
>>
>> void D(void)
>> {
>> if (H(D)) { for (;;); }
>> return;
>> }
>>
>> Let's trace H(D). We indicate the simulation levels from 0,
>> step numbers from 1 within each level, with a bit of indentation
>> to tell apart the levels:
>>
>> Level Step Code Vars
>>
>> 0 1 if (H(D)) ...
>> 0 2 H(D)
>> 0 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
>> 0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0
>> 0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
>> 1 1 if (H(D)) ...
>> 0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1
>> 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
>> 1 2 H(D)
>> 0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2
>> 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
>> 1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
>> 0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3
>> 0 9 return false; P = D; s = #<interp0>; i = 3
>>
>> OK, so after those 3 steps, H(D) has returned false. The D simulation
>> proceeded far enough to hit the "interp_init(P)" calculation, to create
>> the next simulation level.
>>
>
> I don't think so
> i == 0 reaches if (interp_step(s))
> i == 1 reaches if (interp_step(s))
> i == 2 reaches if (interp_step(s))
> i == 3 NEVER reaches if (interp_step(s))
> Then bool H(fptr P) returns false.
Yes, but then the #<interp0> simulation still exists, and the machine
continues it:
Previously we have this ending of H(D):
0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3
0 9 return false; P = D; s = #<interp0>; i = 3
Then #<interp0> is picked up in order to validate H(D)'s claim. This
is continuing D inside the simulated H(D): so the level is 1:
Notice that "1 3" already appeared previously; I only repeated it
for informational purposes, to indicate where the simulation had left
off:
1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
Then first step of the resumption of #<interp0> is actually "1 4":
the variable has been initialized by the above to a new simulation #<interp1>
and we get into the 0 to 2 for loop:
1 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp1>; i = 0
1 5 if (interp_step(s)) ... P = D; s = #<interp1>; i = 0
2 1 if (H(D)) ...
1 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp1>; i = 1
1 7 if (interp_step(s)) ... P = D; s = #<interp1>; i = 0
2 2 H(D)
1 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp1>; i = 2
1 7 if (interp_step(s)) ... P = D; s = #<interp1>; i = 0
2 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
1 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp1>; i = 3
1 9 return false; P = D; s = #<interp1>; i = 3
1 10 if (#<false>) { for(;;); }
1 11 return;
So we get to "1 9 return false;" which is an exact mirror of the
previuos "0 9 return false;".
Same step number, 9, but one level down!
Since this is the simulated H(D): the "return false;" goes back to the
simulated D where the if (H(D)) statement now has evaluated its
expression to false: "1 10 if (#<false>) { ... }". So it skips
the loop and goes to "1 11 return;": D terminates!
In order to believe that D does not terminate we have to believe irrational
ideas like that when the outer H returns false, D is "totally dead". (How can
something "totally dead' be nonterminating?)
You've always correctly claimed that discontinuing the simulation is
not the same as halting. But the flipside of that is that it is not
the same as a non-halting, either!
The arbitrary cessation of a simulation isn't a determiner of whether
the simulated subject is halting or not.
--
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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-04 14:41 -0800 |
| Subject | Re: Semantic properties of finite string inputs --- Kaz code Deviation |
| Message-ID | <10edve8$6q5$1@dont-email.me> |
| In reply to | #135035 |
On 11/4/2025 2:33 PM, Kaz Kylheku wrote: [...] > The arbitrary cessation of a simulation isn't a determiner of whether > the simulated subject is halting or not. > Actually, it reminds me of saying anything other than "YES" in my BASIC simulation of DD, say, 100,000,000 times... Olcott says this proves it does not halt. The user said I was just about to say "YES" and the bastard cut me off at the knees!
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-04 17:18 -0600 |
| Subject | Re: Semantic properties of finite string inputs --- Kaz code Deviation |
| Message-ID | <10ee1jn$u40$1@dont-email.me> |
| In reply to | #135035 |
On 11/4/2025 4:33 PM, Kaz Kylheku wrote:
> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>>> On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
>>>>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>>>>> What step(s) of D come next in C?
>>>>>
>>>>> When I posted a detailed symbolic statement-by-statememnt trace using C
>>>>> syntax several days ago,
>>>> You did not stick with an execution trace of D and only D
>>>> showing that and how D reaches its own "return" statement
>>>> final halt state when simulated and only simulated by H.
>>>
>>> It was a warm-up exercise. The example H wasn't the aborting H.
>>>
>>> You made no remarks on the format: is that a good way or bad
>>> way to trace executions of just C.
>>>
>>> I invented some fictitious API's into the interpreter that H could use
>>> for setting up and stepping a simulation; you made no comments about it.
>>>
>>> The first thing D does when entered is call H(D), so we need an H
>>> to trace concretely.
>>>
>>> How about this minimal viable H:
>>>
>>> #include <interpret.h> // C interpreter's own API
>>>
>>> bool H(fptr P)
>>> {
>>> interp *s = interp_init(P);
>>>
>>> for (int i = 0; i < 3; i++) {
>>> if (interp_step(s))
>>> return true;
>>> }
>>>
>>> return false;
>>> }
>>>
>>> H initializes an interpreter for its argument P. Then it applies a very
>>> simple abort logic: it steps the interpreter state three times. If
>>> during those three steps, P terminates, it returns true. Otherwise it
>>> assumes P is nonterminating and returns false.
>>>
>>> (Pretend that more complicated abort criteria are there.)
>>>
>>> The interpreter API consists of primitives built into the system, so
>>> it isn't traced.
>>>
>>> So then we have D:
>>>
>>> void D(void)
>>> {
>>> if (H(D)) { for (;;); }
>>> return;
>>> }
>>>
>>> Let's trace H(D). We indicate the simulation levels from 0,
>>> step numbers from 1 within each level, with a bit of indentation
>>> to tell apart the levels:
>>>
>>> Level Step Code Vars
>>>
>>> 0 1 if (H(D)) ...
>>> 0 2 H(D)
>>> 0 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
>>> 0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0
>>> 0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
>>> 1 1 if (H(D)) ...
>>> 0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1
>>> 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
>>> 1 2 H(D)
>>> 0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2
>>> 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
>>> 1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
>>> 0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3
>>> 0 9 return false; P = D; s = #<interp0>; i = 3
>>>
>>> OK, so after those 3 steps, H(D) has returned false. The D simulation
>>> proceeded far enough to hit the "interp_init(P)" calculation, to create
>>> the next simulation level.
>>>
>>
>> I don't think so
>> i == 0 reaches if (interp_step(s))
>> i == 1 reaches if (interp_step(s))
>> i == 2 reaches if (interp_step(s))
>> i == 3 NEVER reaches if (interp_step(s))
>> Then bool H(fptr P) returns false.
>
> Yes, but then the #<interp0> simulation still exists, and the machine
> continues it:
>
No. As soon as i == 3 it does not begin another simulation.
--
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-05 02:08 +0000 |
| Subject | Re: Semantic properties of finite string inputs --- Kaz code Deviation |
| Message-ID | <20251104175857.393@kylheku.com> |
| In reply to | #135037 |
On 2025-11-04, olcott <polcott333@gmail.com> wrote:
> On 11/4/2025 4:33 PM, Kaz Kylheku wrote:
>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>>>> On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
>>>>>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>>>>>> What step(s) of D come next in C?
>>>>>>
>>>>>> When I posted a detailed symbolic statement-by-statememnt trace using C
>>>>>> syntax several days ago,
>>>>> You did not stick with an execution trace of D and only D
>>>>> showing that and how D reaches its own "return" statement
>>>>> final halt state when simulated and only simulated by H.
>>>>
>>>> It was a warm-up exercise. The example H wasn't the aborting H.
>>>>
>>>> You made no remarks on the format: is that a good way or bad
>>>> way to trace executions of just C.
>>>>
>>>> I invented some fictitious API's into the interpreter that H could use
>>>> for setting up and stepping a simulation; you made no comments about it.
>>>>
>>>> The first thing D does when entered is call H(D), so we need an H
>>>> to trace concretely.
>>>>
>>>> How about this minimal viable H:
>>>>
>>>> #include <interpret.h> // C interpreter's own API
>>>>
>>>> bool H(fptr P)
>>>> {
>>>> interp *s = interp_init(P);
>>>>
>>>> for (int i = 0; i < 3; i++) {
>>>> if (interp_step(s))
>>>> return true;
>>>> }
>>>>
>>>> return false;
>>>> }
>>>>
>>>> H initializes an interpreter for its argument P. Then it applies a very
>>>> simple abort logic: it steps the interpreter state three times. If
>>>> during those three steps, P terminates, it returns true. Otherwise it
>>>> assumes P is nonterminating and returns false.
>>>>
>>>> (Pretend that more complicated abort criteria are there.)
>>>>
>>>> The interpreter API consists of primitives built into the system, so
>>>> it isn't traced.
>>>>
>>>> So then we have D:
>>>>
>>>> void D(void)
>>>> {
>>>> if (H(D)) { for (;;); }
>>>> return;
>>>> }
>>>>
>>>> Let's trace H(D). We indicate the simulation levels from 0,
>>>> step numbers from 1 within each level, with a bit of indentation
>>>> to tell apart the levels:
>>>>
>>>> Level Step Code Vars
>>>>
>>>> 0 1 if (H(D)) ...
>>>> 0 2 H(D)
>>>> 0 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
>>>> 0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0
>>>> 0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
>>>> 1 1 if (H(D)) ...
>>>> 0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1
>>>> 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
>>>> 1 2 H(D)
>>>> 0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2
>>>> 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
>>>> 1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
>>>> 0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3
>>>> 0 9 return false; P = D; s = #<interp0>; i = 3
>>>>
>>>> OK, so after those 3 steps, H(D) has returned false. The D simulation
>>>> proceeded far enough to hit the "interp_init(P)" calculation, to create
>>>> the next simulation level.
>>>>
>>>
>>> I don't think so
>>> i == 0 reaches if (interp_step(s))
>>> i == 1 reaches if (interp_step(s))
>>> i == 2 reaches if (interp_step(s))
>>> i == 3 NEVER reaches if (interp_step(s))
>>> Then bool H(fptr P) returns false.
>>
>> Yes, but then the #<interp0> simulation still exists, and the machine
>> continues it:
>>
>
> No. As soon as i == 3 it does not begin another simulation.
What do you mean by "it"?
If "it" refers to H, that's certainly true. H is gone after this; it
does nothing, and so if no action is taken, then H's result remains
unverified.
The framework does the verification.
H is called from some test case:
void test_main()
{
printf("D halts = %s\n", H(D) ? "true" : "false");
}
The test_main() test case is run by some framework.
After test_main returns to the framework, the framework looks for an
unfininished simulation, finding #<interp0> that was created in step "0
3" above.
It begins stepping that simulation, which results in the additional
steps I showed traced after "0 9".
The purpose of these steps is to show whether H's simulation of D
is really nonterminating as it claimed.
H(D) committed a crime against computer science by calling something
nonterminating that terminates. It left incriminating evidence behind,
and we are doing the crime scene forensics.
--
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-04 20:24 -0600 |
| Subject | Re: Semantic properties of finite string inputs --- Kaz code Deviation |
| Message-ID | <10eechb$3q4u$1@dont-email.me> |
| In reply to | #135040 |
On 11/4/2025 8:08 PM, Kaz Kylheku wrote:
> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>> On 11/4/2025 4:33 PM, Kaz Kylheku wrote:
>>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>>>>> On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>>>>>>> What step(s) of D come next in C?
>>>>>>>
>>>>>>> When I posted a detailed symbolic statement-by-statememnt trace using C
>>>>>>> syntax several days ago,
>>>>>> You did not stick with an execution trace of D and only D
>>>>>> showing that and how D reaches its own "return" statement
>>>>>> final halt state when simulated and only simulated by H.
>>>>>
>>>>> It was a warm-up exercise. The example H wasn't the aborting H.
>>>>>
>>>>> You made no remarks on the format: is that a good way or bad
>>>>> way to trace executions of just C.
>>>>>
>>>>> I invented some fictitious API's into the interpreter that H could use
>>>>> for setting up and stepping a simulation; you made no comments about it.
>>>>>
>>>>> The first thing D does when entered is call H(D), so we need an H
>>>>> to trace concretely.
>>>>>
>>>>> How about this minimal viable H:
>>>>>
>>>>> #include <interpret.h> // C interpreter's own API
>>>>>
>>>>> bool H(fptr P)
>>>>> {
>>>>> interp *s = interp_init(P);
>>>>>
>>>>> for (int i = 0; i < 3; i++) {
>>>>> if (interp_step(s))
>>>>> return true;
>>>>> }
>>>>>
>>>>> return false;
>>>>> }
>>>>>
>>>>> H initializes an interpreter for its argument P. Then it applies a very
>>>>> simple abort logic: it steps the interpreter state three times. If
>>>>> during those three steps, P terminates, it returns true. Otherwise it
>>>>> assumes P is nonterminating and returns false.
>>>>>
>>>>> (Pretend that more complicated abort criteria are there.)
>>>>>
>>>>> The interpreter API consists of primitives built into the system, so
>>>>> it isn't traced.
>>>>>
>>>>> So then we have D:
>>>>>
>>>>> void D(void)
>>>>> {
>>>>> if (H(D)) { for (;;); }
>>>>> return;
>>>>> }
>>>>>
>>>>> Let's trace H(D). We indicate the simulation levels from 0,
>>>>> step numbers from 1 within each level, with a bit of indentation
>>>>> to tell apart the levels:
>>>>>
>>>>> Level Step Code Vars
>>>>>
>>>>> 0 1 if (H(D)) ...
>>>>> 0 2 H(D)
>>>>> 0 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
>>>>> 0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0
>>>>> 0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
>>>>> 1 1 if (H(D)) ...
>>>>> 0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1
>>>>> 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
>>>>> 1 2 H(D)
>>>>> 0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2
>>>>> 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
>>>>> 1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
>>>>> 0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3
>>>>> 0 9 return false; P = D; s = #<interp0>; i = 3
>>>>>
>>>>> OK, so after those 3 steps, H(D) has returned false. The D simulation
>>>>> proceeded far enough to hit the "interp_init(P)" calculation, to create
>>>>> the next simulation level.
>>>>>
>>>>
>>>> I don't think so
>>>> i == 0 reaches if (interp_step(s))
>>>> i == 1 reaches if (interp_step(s))
>>>> i == 2 reaches if (interp_step(s))
>>>> i == 3 NEVER reaches if (interp_step(s))
>>>> Then bool H(fptr P) returns false.
>>>
>>> Yes, but then the #<interp0> simulation still exists, and the machine
>>> continues it:
>>>
>>
>> No. As soon as i == 3 it does not begin another simulation.
>
> What do you mean by "it"?
>
> If "it" refers to H, that's certainly true.
Maybe I meant the clown monster that hides
in the storm sewer?
> H is gone after this; it
> does nothing, and so if no action is taken, then H's result remains
> unverified.
>
> The framework does the verification.
>
> H is called from some test case:
>
> void test_main()
> {
> printf("D halts = %s\n", H(D) ? "true" : "false");
> }
>
> The test_main() test case is run by some framework.
>
> After test_main returns to the framework, the framework looks for an
> unfininished simulation, finding #<interp0> that was created in step "0
> 3" above.
>
> It begins stepping that simulation, which results in the additional
> steps I showed traced after "0 9".
>
Not when it begins at the exact same machine state
where H returned zero. If it does not do this then
it is not actually resuming the simulation it is
starting a new simulation. If it does not resume
H with i == 3, then it is not resuming the simulation.
> The purpose of these steps is to show whether H's simulation of D
> is really nonterminating as it claimed.
>
> H(D) committed a crime against computer science by calling something
> nonterminating that terminates. It left incriminating evidence behind,
> and we are doing the crime scene forensics.
>
--
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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-04 18:16 -0600 |
| Subject | Re: Semantic properties of finite string inputs --- Kaz makes a very smart example |
| Message-ID | <10ee50m$20qj$1@dont-email.me> |
| In reply to | #134993 |
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>> On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
>>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>>> What step(s) of D come next in C?
>>>
>>> When I posted a detailed symbolic statement-by-statememnt trace using C
>>> syntax several days ago,
>> You did not stick with an execution trace of D and only D
>> showing that and how D reaches its own "return" statement
>> final halt state when simulated and only simulated by H.
>
> It was a warm-up exercise. The example H wasn't the aborting H.
>
> You made no remarks on the format: is that a good way or bad
> way to trace executions of just C.
>
> I invented some fictitious API's into the interpreter that H could use
> for setting up and stepping a simulation; you made no comments about it.
>
> The first thing D does when entered is call H(D), so we need an H
> to trace concretely.
>
> How about this minimal viable H:
>
> #include <interpret.h> // C interpreter's own API
>
> bool H(fptr P)
> {
> interp *s = interp_init(P);
>
This part seems very smart. Is this actual working code?
> for (int i = 0; i < 3; i++) {
> if (interp_step(s))
> return true;
> }
>
> return false;
> }
>
> H initializes an interpreter for its argument P. Then it applies a very
> simple abort logic: it steps the interpreter state three times. If
> during those three steps, P terminates, it returns true. Otherwise it
> assumes P is nonterminating and returns false.
>
> (Pretend that more complicated abort criteria are there.)
>
> The interpreter API consists of primitives built into the system, so
> it isn't traced.
--
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 | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2025-11-03 12:05 +0200 |
| Message-ID | <10e9upc$2pl6f$1@dont-email.me> |
| In reply to | #134814 |
On 2025-11-02 13:29:15 +0000, olcott said:
> On 11/2/2025 6:17 AM, Mikko wrote:
>> On 2025-11-01 13:25:41 +0000, olcott said:
>>
>>> On 11/1/2025 3:42 AM, Mikko wrote:
>>>> On 2025-10-31 12:44:17 +0000, olcott said:
>>>>
>>>>> On 10/31/2025 6:28 AM, Mikko wrote:
>>>>>> On 2025-10-30 14:49:08 +0000, olcott said:
>>>>>>
>>>>>>> D simulated by H measures the semantic property
>>>>>>> of the actual input as opposed to and contrast
>>>>>>> with the semantic property of a non-input. H and
>>>>>>> H1 are identical except that D does not call H1.
>>>>>>
>>>>>> Being identical means that H and H1 compute the same semantic
>>>>>> property.
>>>>>>
>>>>>
>>>>> 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;
>>>>>
>>>>> H1 simulates D
>>>>> that calls H(D) to simulate D
>>>>> then H(D) returns 0 to caller D
>>>>> then H1 returns 1;
>>>>>
>>>>> It turns out that my big discovery the overturns
>>>>> part of the foundation of computer science is that
>>>>> the semantic property can be relative to the decider.
>>>>>
>>>>> It actually always relative to the decider yet this
>>>>> has never made any difference with non-self-referential
>>>>> inputs. H(D) != UTM(D) == H1(D)
>>>>>
>>>>> The halting problem has always been an issue where
>>>>> the halt decider has never been smart enough to
>>>>> figure out halting for self-contradictory inputs.
>>>>> That never has been the real issue.
>>>>>
>>>>> int D()
>>>>> {
>>>>> int Halt_Status = H(D);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>>
>>>>> With a simulating halt decider D simulated by
>>>>> H never reaches the contradictory part. It
>>>>> stays stuck on its first line.
>>>>>
>>>>> H and D do get stuck in recursive simulation. H
>>>>> can and does see this. H does abort its own simulation
>>>>> of D to prevent its own non-termination.
>>>>>
>>>>> The real issue (that could not be seen until I created
>>>>> the notion of a simulating halt decider in 2016) is
>>>>> that the halting problem requires H to report on
>>>>> behavior other than the behavior that its actual input
>>>>> actually specifies.
>>>>>
>>>>> int sum(int x, int y){ return x + y; }
>>>>> this is the same as requiring sum(3,4) to report on
>>>>> the sum of 5 + 6.
>>>>>
>>>>>
>>>>>>> We can tell an input from a non-input because an
>>>>>>> input is an argument to the function H.
>>>>>>>
>>>>>>> D.input_to_H
>>>>>>> specifies different behavior than
>>>>>>> D.input_to_H1.
>>>>>>>
>>>>>>> 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;
>>>>>>>
>>>>>>> H1 simulates D
>>>>>>> that calls H(D) to simulate D
>>>>>>> then H(D) returns 0 to caller D
>>>>>>> then H1 returns 1;
>>>>>>
>>>>>> As H and H1 return different values for the same input they are
>>>>>> found to be non-identical, contrary to the initial claim.
>>>>
>>>> The above confirms that H and H1 give different results for the same
>>>> input. By the meanngs of the words H and H1 are not equivalent.
>>>
>>> I never claimed that the were equivalent.
>>
>> You said they be identical. If they are not equivlaent they can't
>> be identical.
>
> Identical code and different behavior
> because D calls H in recursive simulation
> and D does not call H1 in recursive simulation.
Identical codes mean the same and specify identical behaviours.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> |
|---|---|
| Date | 2025-11-03 17:16 +0000 |
| Message-ID | <10eao1i$31en2$1@dont-email.me> |
| In reply to | #134905 |
On 03/11/2025 10:05, Mikko wrote: > Identical codes mean the same and specify identical behaviours. ... with respect to closure. -- 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 | Alan Mackenzie <acm@muc.de> |
|---|---|
| Date | 2025-11-03 20:19 +0000 |
| Message-ID | <10eb2oi$qhc$1@news.muc.de> |
| In reply to | #134918 |
Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote: > On 03/11/2025 10:05, Mikko wrote: >> Identical codes mean the same and specify identical behaviours. > ... with respect to closure. You've used the word "closure" quite a number of times. What do you mean by it? It's beyond my powers of guessing from context. Thanks! > -- > 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. -- Alan Mackenzie (Nuremberg, Germany).
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-03 21:35 +0000 |
| Message-ID | <20251103132431.12@kylheku.com> |
| In reply to | #134949 |
On 2025-11-03, Alan Mackenzie <acm@muc.de> wrote:
> Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote:
>> On 03/11/2025 10:05, Mikko wrote:
>
>>> Identical codes mean the same and specify identical behaviours.
>
>> ... with respect to closure.
>
> You've used the word "closure" quite a number of times. What do you
> mean by it? It's beyond my powers of guessing from context.
Tristan also used "dynamic closure".
Over two decades ago I made a Lisp dialect (called VoqLisp, unrelated to
TXR Lisp) which had dynamic closures.
It captured dynamic environments up to a delimiting marker.
(I didn't know about delimited continuations then; the delimitation
was eerily similar, but used only for capturing a segment of dynamic
scope, not the entire activation context.)
A marker was inserted into the dynamic scope by every function call.
But nested interpretation constructs wouldn't insert a marker.
The effect was that the de-facto lexical scope was captured.
When a lambda was invoked, the captured dynamic environment was grafted
to the current one, followed by the binding of the parameters.
Tnus if you had, say
(let ((*dynamic-var* 42))
(lambda () (foo)))
The lambda would capture the dynamic var. When you would call the
lambda, it would reinstante the *dynamic-var* 42 binding, and
call (foo).
But since *dynamic-var* is not actually lexical, foo could
refer to *dynamic-var* and see the value 42.
It was nice for writing test cases for an embedded target.
You could produce configurations using let binding of multiple variables
without having to have all of them as parameters to the functions doing
all the work.
VoqLisp was multithreaded so this all worked nicely with threads.
Some test cases launched several threads in one scope, so the
thread lambdas captured the same variables (same instance).
There were mutex objects whch the threads used to synchronize,
e.g.:
(defun test-foo ()
(let ((*test-param-a* 42)
(*test-param-b* "abc")
(*test-state-variable*)
(*mutex* (create-mutex)))
... create threads here, which execute thread functions
... that can see all these varrs: they use the *mutex*
... when messing with *test-state-variable*
)
--
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 | Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> |
|---|---|
| Date | 2025-11-03 21:36 +0000 |
| Message-ID | <10eb791$36296$1@dont-email.me> |
| In reply to | #134949 |
On 03/11/2025 20:19, Alan Mackenzie wrote: > Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote: >> On 03/11/2025 10:05, Mikko wrote: > >>> Identical codes mean the same and specify identical behaviours. > >> ... with respect to closure. > > You've used the word "closure" quite a number of times. What do you > mean by it? It's beyond my powers of guessing from context. Well, we can see it from a couple of perspectives and find the same result so I'll avoid the hours of checking what I say and be a bit loose. A program (or subprogram) that doesn't define everything itself refers to a definition provided elsewhere. In essence, the provision of the missing piece is closing with a closure. Some of them are lexical, some dynamic, I'm sure there are other kinds. Personally I also don't see I/O as being an awful lot different but I don't know what meaning is assigned conventionally everywhere. I feel even procedure arguments can be seen as a closure though we tend not to talk about them like that in programming as seen conteporarily. In formal systems the concept of closure appears when defining its objects and it seems to me to be highly related. The meaning of an operation that constructs an object is progressively completed by applying its arguments until the consequence of the operation is fully specified whereupon it is closed and the arguments were its closure. To go further into how it applies here and where it might but isn't relevant is a whole essay with lots of care needed, so I won't. I don't say this to sound all secretly knowledgable because I'm not, but I mean to point to what I think is the relevant concept for understanding Olcott's situation statement without saying anything egregiously wrong and without taking forever. -- 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-11-03 15:48 -0600 |
| Subject | Olcott's revised position statement |
| Message-ID | <10eb7uu$36lkv$1@dont-email.me> |
| In reply to | #134965 |
On 11/3/2025 3:36 PM, Tristan Wibberley wrote:
> On 03/11/2025 20:19, Alan Mackenzie wrote:
>> Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote:
>>> On 03/11/2025 10:05, Mikko wrote:
>>
>>>> Identical codes mean the same and specify identical behaviours.
>>
>>> ... with respect to closure.
>>
>> You've used the word "closure" quite a number of times. What do you
>> mean by it? It's beyond my powers of guessing from context.
>
> Well, we can see it from a couple of perspectives and find the same
> result so I'll avoid the hours of checking what I say and be a bit loose.
>
> A program (or subprogram) that doesn't define everything itself refers
> to a definition provided elsewhere. In essence, the provision of the
> missing piece is closing with a closure. Some of them are lexical, some
> dynamic, I'm sure there are other kinds. Personally I also don't see I/O
> as being an awful lot different but I don't know what meaning is
> assigned conventionally everywhere.
>
> I feel even procedure arguments can be seen as a closure though we tend
> not to talk about them like that in programming as seen conteporarily.
>
> In formal systems the concept of closure appears when defining its
> objects and it seems to me to be highly related. The meaning of an
> operation that constructs an object is progressively completed by
> applying its arguments until the consequence of the operation is fully
> specified whereupon it is closed and the arguments were its closure.
>
> To go further into how it applies here and where it might but isn't
> relevant is a whole essay with lots of care needed, so I won't. I don't
> say this to sound all secretly knowledgable because I'm not, but I mean
> to point to what I think is the relevant concept for understanding
> Olcott's situation statement without saying anything egregiously wrong
> and without taking forever.
>
I tested my terse position statement with the LLM's
and only Claude AI got it.
When I got ChatGPT to get it I got ChatGPT to write up
its understanding so that it would get it right away in
a future session. Grok didn't quite get this so below
is the simplest version that they all understand.
It may simply be that the people here just don't have
enough attention span to make sure that they pay 100%
complete attention to ALL of these details.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The function H is a simulating termination analyzer:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
(b) Simulated input reaches its simulated
"return" statement: return 1.
When given a function P, it literally simulates each
step of executing P() to see whether that simulated
execution ever reaches a return statement. Now let H
simulate D. Based only on the outcome of that literal
simulation (not on reasoning about what should happen),
what result should H(D) produce?
> --
> 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-03 21:57 +0000 |
| Message-ID | <20251103134358.926@kylheku.com> |
| In reply to | #134965 |
On 2025-11-03, Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote: > On 03/11/2025 20:19, Alan Mackenzie wrote: >> Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote: >>> On 03/11/2025 10:05, Mikko wrote: >> >>>> Identical codes mean the same and specify identical behaviours. >> >>> ... with respect to closure. >> >> You've used the word "closure" quite a number of times. What do you >> mean by it? It's beyond my powers of guessing from context. > > Well, we can see it from a couple of perspectives and find the same > result so I'll avoid the hours of checking what I say and be a bit loose. > > A program (or subprogram) that doesn't define everything itself refers > to a definition provided elsewhere. In essence, the provision of the > missing piece is closing with a closure. Some of them are lexical, some > dynamic, I'm sure there are other kinds. Personally I also don't see I/O > as being an awful lot different but I don't know what meaning is > assigned conventionally everywhere. > > I feel even procedure arguments can be seen as a closure though we tend > not to talk about them like that in programming as seen conteporarily. > > In formal systems the concept of closure appears when defining its > objects and it seems to me to be highly related. The meaning of an > operation that constructs an object is progressively completed by > applying its arguments until the consequence of the operation is fully > specified whereupon it is closed and the arguments were its closure. This conjures up the image of applying arguments one at a time to a curried function. When we have the last function, everything is bound. The term "binding" is used for the captured arguments under partial application. The term "binding" is also used for giving values (arguments) to parameters. If "binding" can be usd for those two purposes, so can "closure", I suppose. A function body refers to variables. Some of them are free with respect to that body and may refer to a captured surrounding environment, so they are bound up in the closure of hat function. Some of those variables refer to parameters. Formally we think of those as bound variables (not free). But in actual fact, they do not have those bindings until the function is applied to arguments. When the function is applied to arguments, we can legitimately visualise that as the parmeters being added to the closure with those argument values. The closure is then "complete" in a sense---all variables are bound---and the funciton application can proceed with evaluating the body. It's just that in the conventional terminology, we think of the closure as being the bound materials excluding the arguments; this allows us to speak of the same closure being reused with different argument values. Maybe that's a rhetorical disadvantage, concealing that argument values can turn a function into something different. Anyway, I feel I could easily shift between the different modes of discussion. -- 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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2025-11-02 14:10 -0500 |
| Message-ID | <y0ONQ.177729$D_Tb.24494@fx47.iad> |
| In reply to | #134657 |
On 11/1/25 9:25 AM, olcott wrote:
> On 11/1/2025 3:42 AM, Mikko wrote:
>> On 2025-10-31 12:44:17 +0000, olcott said:
>>
>>> On 10/31/2025 6:28 AM, Mikko wrote:
>>>> On 2025-10-30 14:49:08 +0000, olcott said:
>>>>
>>>>> D simulated by H measures the semantic property
>>>>> of the actual input as opposed to and contrast
>>>>> with the semantic property of a non-input. H and
>>>>> H1 are identical except that D does not call H1.
>>>>
>>>> Being identical means that H and H1 compute the same semantic
>>>> property.
>>>>
>>>
>>> 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;
>>>
>>> H1 simulates D
>>> that calls H(D) to simulate D
>>> then H(D) returns 0 to caller D
>>> then H1 returns 1;
>>>
>>> It turns out that my big discovery the overturns
>>> part of the foundation of computer science is that
>>> the semantic property can be relative to the decider.
>>>
>>> It actually always relative to the decider yet this
>>> has never made any difference with non-self-referential
>>> inputs. H(D) != UTM(D) == H1(D)
>>>
>>> The halting problem has always been an issue where
>>> the halt decider has never been smart enough to
>>> figure out halting for self-contradictory inputs.
>>> That never has been the real issue.
>>>
>>> int D()
>>> {
>>> int Halt_Status = H(D);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> With a simulating halt decider D simulated by
>>> H never reaches the contradictory part. It
>>> stays stuck on its first line.
>>>
>>> H and D do get stuck in recursive simulation. H
>>> can and does see this. H does abort its own simulation
>>> of D to prevent its own non-termination.
>>>
>>> The real issue (that could not be seen until I created
>>> the notion of a simulating halt decider in 2016) is
>>> that the halting problem requires H to report on
>>> behavior other than the behavior that its actual input
>>> actually specifies.
>>>
>>> int sum(int x, int y){ return x + y; }
>>> this is the same as requiring sum(3,4) to report on
>>> the sum of 5 + 6.
>>>
>>>
>>>>> We can tell an input from a non-input because an
>>>>> input is an argument to the function H.
>>>>>
>>>>> D.input_to_H
>>>>> specifies different behavior than
>>>>> D.input_to_H1.
>>>>>
>>>>> 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;
>>>>>
>>>>> H1 simulates D
>>>>> that calls H(D) to simulate D
>>>>> then H(D) returns 0 to caller D
>>>>> then H1 returns 1;
>>>>
>>>> As H and H1 return different values for the same input they are
>>>> found to be non-identical, contrary to the initial claim.
>>
>> The above confirms that H and H1 give different results for the same
>> input. By the meanngs of the words H and H1 are not equivalent.
>>
>
> I never claimed that the were equivalent.
> I claimed that HD)==0 and H1(D)==1 proving
> that they are not equivalent.
>
> The key thing here is that they are both reporting
> on the actual sequence of steps that their actual
> input actually specifies.
>
> Anything more than this is outside of the scope
> of deciders in general.
>
Which means you are admitting that the "specification" by the input is a
subjective property, and thus CAN'T be a objective property of the
program D, like halting is (or at least is supposed to be).
This means your concept of a "decider" is wrong, as "Deciders" are BY
DEFINITION based on an OBJECTIVE specification, as the mapping they are
trying to compute is objecitive (not based on who is being asked).
[toc] | [prev] | [next] | [standalone]
| From | Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> |
|---|---|
| Date | 2025-10-31 12:35 +0000 |
| Message-ID | <10e2ae3$f4dt$1@dont-email.me> |
| In reply to | #134369 |
On 30/10/2025 14:49, olcott wrote: [snip] > H can recognize a call to itself in > its input. The whole input is the > text of the function D. The executable > interpreters are named H.exe and H1.exe. Thank you for posting this. It is *super* interesting. -- 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 | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-31 18:00 +0000 |
| Message-ID | <20251031105351.476@kylheku.com> |
| In reply to | #134484 |
On 2025-10-31, Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote: > On 30/10/2025 14:49, olcott wrote: > [snip] >> H can recognize a call to itself in >> its input. The whole input is the >> text of the function D. The executable >> interpreters are named H.exe and H1.exe. > > Thank you for posting this. It is *super* interesting. An algorithm recognizing the presence of itself in its input is an undecidable problem. Equivalence of algoirthms is undecidable; i.e. the function equal_functions(f1, f2) is incomputable. Olcott's "x86utm" and "Halt7" code uses machine address equivalence as a substitute for function equivalence. He has two functions HHH and HHH1 which are absolutely identical except for their name. Yet, they trigger a different behavior, because the abort check in his simulation assumes that if two code addresses are unequal, they are different functions. -- 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 | Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> |
|---|---|
| Date | 2025-10-31 19:46 +0000 |
| Message-ID | <10e33m7$ojqn$1@dont-email.me> |
| In reply to | #134522 |
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. -- 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 | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-31 23:10 +0000 |
| Message-ID | <20251031160630.15@kylheku.com> |
| In reply to | #134533 |
On 2025-10-31, Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> 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. ... useful for confirming that two expressions are /not/ equivalent. It's only useful in cases in which you can accept false negatives. For instance when we take derivative-based regular expression and compile it, we need to recognize equivalent regex terms so that we can close loops in the resulting graph. Implementations of this rely on some some imperfect heuristics that work well in practice. False negatives create a larger state machine. Nominal equivalence is not good enough if you're trying to prove something about halting. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
Page 7 of 15 — ← Prev page 1 … 5 6 [7] 8 9 … 15 Next page →
Back to top | Article view | comp.theory
csiph-web