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 5 of 15 — ← Prev page 1 … 3 4 [5] 6 7 … 15 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-01 13:59 -0700 |
| Message-ID | <10e5sbe$1irmc$1@dont-email.me> |
| In reply to | #134725 |
On 11/1/2025 1:18 PM, olcott wrote:
> On 11/1/2025 3:12 PM, Tristan Wibberley wrote:
>> On 01/11/2025 13:51, dbush wrote:
>>> ... The input to both H(D) and H1(D), i.e. finite string D, is the
>>> description of machine D and therefore is stipulated to specify all
>>> semantic properties of machine D, including the fact that machine D
>>> halts when executed directly.
>>
>> Is D a machine?
>>
>
> I have been saying that D is this C code for weeks now.
>
> int D()
> {
> int Halt_Status = H(D);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
>> I think H(D) might be, except that it's an imperative program for the
>> prevailing publicly discussed type of system in the last few decades so
>> H and H1 will provide a closure to it somehow.
>>
>
> Its C code that can be construed as a virtual machine.
Did you choose C because you don't know C?
[...]
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2025-11-02 14:17 +0200 |
| Message-ID | <10e7i4o$233ff$1@dont-email.me> |
| In reply to | #134657 |
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.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-02 07:29 -0600 |
| Message-ID | <10e7mbb$24a4l$1@dont-email.me> |
| In reply to | #134801 |
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.
--
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-02 22:26 +0000 |
| Message-ID | <20251102142602.101@kylheku.com> |
| In reply to | #134814 |
On 2025-11-02, olcott <polcott333@gmail.com> wrote: >> 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. Can you show that concretely with C? -- 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 | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-03 20:43 +0000 |
| Message-ID | <20251103124322.237@kylheku.com> |
| In reply to | #134852 |
On 2025-11-02, Kaz Kylheku <643-408-1753@kylheku.com> wrote: > On 2025-11-02, olcott <polcott333@gmail.com> wrote: >>> 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. > > Can you show that concretely with C? Didn't think so. -- 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-03 14:47 -0600 |
| Message-ID | <10eb4cf$35h0l$2@dont-email.me> |
| In reply to | #134953 |
On 11/3/2025 2:43 PM, Kaz Kylheku wrote: > On 2025-11-02, Kaz Kylheku <643-408-1753@kylheku.com> wrote: >> On 2025-11-02, olcott <polcott333@gmail.com> wrote: >>>> 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. >> >> Can you show that concretely with C? > > Didn't think so. > I have done that hundreds of times and you just ignore it. -- 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 22:40 +0000 |
| Message-ID | <20251103143853.925@kylheku.com> |
| In reply to | #134955 |
On 2025-11-03, olcott <polcott333@gmail.com> wrote: > On 11/3/2025 2:43 PM, Kaz Kylheku wrote: >> On 2025-11-02, Kaz Kylheku <643-408-1753@kylheku.com> wrote: >>> On 2025-11-02, olcott <polcott333@gmail.com> wrote: >>>>> 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. >>> >>> Can you show that concretely with C? >> >> Didn't think so. > > I have done that hundreds of times and you just ignore it. What? Where? All you ever post these days is useless talk. Where is the URL to a project with .c files and a Makefile, etc? -- 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-03 16:56 -0600 |
| Message-ID | <10ebbuc$37n04$1@dont-email.me> |
| In reply to | #134969 |
On 11/3/2025 4:40 PM, Kaz Kylheku wrote: > On 2025-11-03, olcott <polcott333@gmail.com> wrote: >> On 11/3/2025 2:43 PM, Kaz Kylheku wrote: >>> On 2025-11-02, Kaz Kylheku <643-408-1753@kylheku.com> wrote: >>>> On 2025-11-02, olcott <polcott333@gmail.com> wrote: >>>>>> 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. >>>> >>>> Can you show that concretely with C? >>> >>> Didn't think so. >> >> I have done that hundreds of times and you just ignore it. > > What? Where? All you ever post these days is useless talk. > > Where is the URL to a project with .c files and a Makefile, etc? > Are you saying that you are smart enough to do this: On 10/31/2025 7:44 PM, Kaz Kylheku wrote: > I can write a C interpreter which can interpret itself. Yet not smart enough to do a simple execution trace in your head? -- 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 00:24 +0000 |
| Message-ID | <20251103160903.321@kylheku.com> |
| In reply to | #134970 |
On 2025-11-03, olcott <polcott333@gmail.com> wrote: > On 11/3/2025 4:40 PM, Kaz Kylheku wrote: >> On 2025-11-03, olcott <polcott333@gmail.com> wrote: >>> On 11/3/2025 2:43 PM, Kaz Kylheku wrote: >>>> On 2025-11-02, Kaz Kylheku <643-408-1753@kylheku.com> wrote: >>>>> On 2025-11-02, olcott <polcott333@gmail.com> wrote: >>>>>>> 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. >>>>> >>>>> Can you show that concretely with C? >>>> >>>> Didn't think so. >>> >>> I have done that hundreds of times and you just ignore it. >> >> What? Where? All you ever post these days is useless talk. >> >> Where is the URL to a project with .c files and a Makefile, etc? >> > > Are you saying that you are smart enough to do this: > > On 10/31/2025 7:44 PM, Kaz Kylheku wrote: > > I can write a C interpreter which can interpret itself. > > Yet not smart enough to do a simple execution trace in your head? Bleeping idiot, of course it was the "execution trace in my head" which led me to the realization that abandoned simulations of D have a continuable future which leads to termination. But exeution traces in one's head ARE NOT WORTH A FUCK. You have to turn them into some kind of real work in the world. I did that. To TEST THE VALIDITY OF MY IDEA with SOMETHING REAL, I took the available platform for nested simulations, the mighty x86utm, and showed to myself what I'm talking about. Now you want to move the goalposts back to mental-trace land, since you can't handle the results. I WARNED YOU since August or early September that this would be possible; that someone might come along and start tinkering with your x86utm to see what happens if abandoned simulations are stepped. You had several months to do that yourself, and prepare a defense; to validate that your simulated D under H indeed behaves differently from the direct D, and fails to terminate. (You have the code for that in place, it just isn't working!!!) You had all this time to look into this, do it yoursel and fix up your code and accompanying rhetoric in some suitable way. Now you are just dodging and trying to steer things to mental-trace land, which is all you had before the x86utm. That's the wrong direction! Ideas generally go form "in your head" to "real thing in the world showing a result", not the other way around. Since x86utm is suddenly no good any more (I wonder why) post your new project where you have differently re-worked your ideas about aborting H simulating D, again with real executable traces. I will shoot that down easily, too. Until then, you have less than nothing. Just empty clap trap with obvious logical inconsistencies, and digital parrots on your shoulder whispering what you want to hear. -- 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-03 18:43 -0600 |
| Subject | Re: Semantic properties of finite string inputs --- Closure ??? |
| Message-ID | <10ebi7i$39l5v$1@dont-email.me> |
| In reply to | #134982 |
On 11/3/2025 6:24 PM, Kaz Kylheku wrote:
> On 2025-11-03, olcott <polcott333@gmail.com> wrote:
>> On 11/3/2025 4:40 PM, Kaz Kylheku wrote:
>>> On 2025-11-03, olcott <polcott333@gmail.com> wrote:
>>>> On 11/3/2025 2:43 PM, Kaz Kylheku wrote:
>>>>> On 2025-11-02, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>>>>> On 2025-11-02, olcott <polcott333@gmail.com> wrote:
>>>>>>>> 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.
>>>>>>
>>>>>> Can you show that concretely with C?
>>>>>
>>>>> Didn't think so.
>>>>
>>>> I have done that hundreds of times and you just ignore it.
>>>
>>> What? Where? All you ever post these days is useless talk.
>>>
>>> Where is the URL to a project with .c files and a Makefile, etc?
>>>
>>
>> Are you saying that you are smart enough to do this:
>>
>> On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
>>> I can write a C interpreter which can interpret itself.
>>
>> Yet not smart enough to do a simple execution trace in your head?
>
> Bleeping idiot, of course it was the "execution trace in my head"
> which led me to the realization that abandoned simulations of D have
> a continuable future which leads to termination.
>
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then try and prove this by showing an execution
trace of D simulated by H entirely in C.
Don't show any execution trace of anything besides
D and do this entirely in C. I will get you started:
H simulates D that calls H(D) that simulates D that calls H(D)
What step(s) of D come next in C?
--
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 02:22 +0000 |
| Subject | Re: Semantic properties of finite string inputs --- Closure ??? |
| Message-ID | <20251103181346.107@kylheku.com> |
| In reply to | #134985 |
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 just snipped it and ignored it, repeating your question. My trace showed which part of the syntax was being currently interpreted, and the values of some variables. Not only have you no idea what the trace is supposed looks like, you can't even recognize it when you see it in some concrete form. You are making every effort to make communicating with you impossible, because that's how you think you can ward off threat. -- 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-03 21:02 -0600 |
| Subject | Re: Semantic properties of finite string inputs --- Closure ??? |
| Message-ID | <10ebqbv$3bp3f$1@dont-email.me> |
| In reply to | #134991 |
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. *This is the only thread that I will speak to you on* -- 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 04:28 +0000 |
| Subject | Re: Semantic properties of finite string inputs --- Closure ??? |
| Message-ID | <20251103195844.661@kylheku.com> |
| In reply to | #134992 |
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.
The D simulation is not "totally killed"; it (the #<interp0> object)
continues to exist.
The interpreter machine can identify it and continue to step it: to do
the reckoning.
Level Step Code Vars
1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
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;
At simulation level 1, step 9, the simulated H(D) returns false.
Step 10 is back in the simulated D(). The evaluated value of H(D)
is false, shown by #<false>. The if statement falls through.
Step 11 is the return statement reached by D.
When we continue the simulation D that H started and abandoned,
its return statement is reached.
What continues the simulation? The "reckoning" machinery in the UTM
which runs the H(D) test case. When the test case returns, this code
kicks in to check for the oldest unfinished simulation and keeps
stepping it to try to show whether H(D) returning false was the right
verdict.
I have shown the concept using a simple simulating halt decider H wth a
minimal viable abort test, consisting of trying to run the input for
three instructions and then abandoning it as non-terminating.
You may find the criteria too simple, but if you drill into it, you will
find they don't matter. More complicated criteria which try to detect a
repeating pattern of some kind will not change the outcome.
All that matters is that the simulated D gets a false return value from
the simulated H(D) somehow. It could take three steps, or three billion.
--
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 13:52 -0600 |
| Subject | Re: Semantic properties of finite string inputs --- Closure ??? |
| Message-ID | <10edlis$3t706$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.
>
All of these details must be assumed. When you
try to specify these additional steps the essential
truth gets lost in the details.
> 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.
>
> The D simulation is not "totally killed"; it (the #<interp0> object)
> continues to exist.
>
> The interpreter machine can identify it and continue to step it: to do
> the reckoning.
>
> Level Step Code Vars
>
> 1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
> 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;
>
> At simulation level 1, step 9, the simulated H(D) returns false.
>
> Step 10 is back in the simulated D(). The evaluated value of H(D)
> is false, shown by #<false>. The if statement falls through.
>
> Step 11 is the return statement reached by D.
>
> When we continue the simulation D that H started and abandoned,
> its return statement is reached.
Sure we can do that the same way that
you said we could do it for this:
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
>
> What continues the simulation? The "reckoning" machinery in the UTM
> which runs the H(D) test case. When the test case returns, this code
> kicks in to check for the oldest unfinished simulation and keeps
> stepping it to try to show whether H(D) returning false was the right
> verdict.
>
Or you could have much more simply made N larger.
The convolution of these extra steps merely hides
the simple essential truth.
> I have shown the concept using a simple simulating halt decider H wth a
> minimal viable abort test, consisting of trying to run the input for
> three instructions and then abandoning it as non-terminating.
>
Yes that part was an excellent empirical proof.
You could just keep increasing N until out-of-memory
error. This would form a reasonably plausible proof
that comes short of absolute certainty.
The absolute certainty comes by simply recognizing
the behavior pattern that D simulated cannot possibly
reach its own "return" statement no matter what H does.
Almost everyone here should have recognized that
this is only slightly more complex than infinite
recursion three years ago.
> You may find the criteria too simple, but if you drill into it, you will
> find they don't matter. More complicated criteria which try to detect a
> repeating pattern of some kind will not change the outcome.
>
> All that matters is that the simulated D gets a false return value from
> the simulated H(D) somehow. It could take three steps, or three billion.
>
--
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 20:20 +0000 |
| Subject | Re: Semantic properties of finite string inputs --- Closure ??? |
| Message-ID | <20251104120709.477@kylheku.com> |
| In reply to | #135021 |
On 2025-11-04, olcott <polcott333@gmail.com> wrote:
> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>> Step 11 is the return statement reached by D.
>>
>> When we continue the simulation D that H started and abandoned,
>> its return statement is reached.
>
> Sure we can do that the same way that
> you said we could do it for this:
Remember, I had only been joking that you might as well regard
Infinite_Loop as halting. Obviously it isn't
> void Infinite_Loop()
> {
> HERE: goto HERE;
> return;
> }
If you substitute that for D in my above simulation, you will find
that, no, that doesn't terminate. The example H will give up after the
three steps, just like before, and return 0, leaving an abandoned
#<interp0> simulation.
When we continue stepping the abandoned #<interp0>, it will just be
trapped in the HERE: goto HERE (confirming that 0 was the
correct return value).
It is specifically the diagonal D which reaches its return statement
due to H's return value being 0, including in simulation.
Mike Terry posted some new execution traces from the x86utm with
reckoning continuation. He wrote a new test case: a clean version
of HHH and DDD (called MJT_HHH and MJT_DDD) which do not rely on
mutated static data:
He's getting a nice "infinite tower" in which every MJT_HHH
returns 0 to its respective MJT_DDD, which then terminates.
He posted this:
Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as HHH, but
without the global variable misuse. HHH[0] decides non-halting.
Resumed simulations all halt with same behaviour as HHH[n] deciding
non-halting (like HHH[0]) then DDD[n] returning.
DDD[1] ends, after HHH[1] detects "infinite recursion" and returns 0.
DDD[2] ends, after HHH[2] detects "infinite recursion" and returns 0.
DDD[3] ends, after HHH[3] detects "infinite recursion" and returns 0.
DDD[4] ends, after HHH[4] detects "infinite recursion" and returns 0.
Mike added back your square brackets level indication, so we can see
the increasing simulation levels.
The tower keeps going, but the DDD's terminate.
If the memory management is done right, this should execute indefinitely.
Because it is not recursion, it is not chewing up space in a linear
stack. Every simuation gets a stack and state buffers from Allocate,
which can be released when the simulation terminates, keeping the peak
memory use constant.
--
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 | Mr Flibble <flibble@red-dwarf.jmc.corp> |
|---|---|
| Date | 2025-11-04 21:04 +0000 |
| Subject | Re: Semantic properties of finite string inputs --- Closure ??? |
| Message-ID | <sTtOQ.125396$O5fb.73199@fx01.ams4> |
| In reply to | #135023 |
On Tue, 04 Nov 2025 20:20:04 +0000, Kaz Kylheku wrote:
> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>> Step 11 is the return statement reached by D.
>>>
>>> When we continue the simulation D that H started and abandoned,
>>> its return statement is reached.
>>
>> Sure we can do that the same way that you said we could do it for this:
>
> Remember, I had only been joking that you might as well regard
> Infinite_Loop as halting. Obviously it isn't
>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> return;
>> }
>
> If you substitute that for D in my above simulation, you will find that,
> no, that doesn't terminate. The example H will give up after the three
> steps, just like before, and return 0, leaving an abandoned #<interp0>
> simulation.
>
> When we continue stepping the abandoned #<interp0>, it will just be
> trapped in the HERE: goto HERE (confirming that 0 was the correct return
> value).
>
> It is specifically the diagonal D which reaches its return statement due
> to H's return value being 0, including in simulation.
>
> Mike Terry posted some new execution traces from the x86utm with
> reckoning continuation. He wrote a new test case: a clean version of HHH
> and DDD (called MJT_HHH and MJT_DDD) which do not rely on mutated static
> data:
>
> He's getting a nice "infinite tower" in which every MJT_HHH returns 0 to
> its respective MJT_DDD, which then terminates.
> He posted this:
>
> Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as HHH, but
> without the global variable misuse. HHH[0] decides
> non-halting. Resumed simulations all halt with same behaviour
> as HHH[n] deciding non-halting (like HHH[0]) then DDD[n]
> returning.
> DDD[1] ends, after HHH[1] detects "infinite recursion" and returns
> 0.
> DDD[2] ends, after HHH[2] detects "infinite recursion" and returns
> 0.
> DDD[3] ends, after HHH[3] detects "infinite recursion" and returns
> 0.
> DDD[4] ends, after HHH[4] detects "infinite recursion" and returns
> 0.
>
> Mike added back your square brackets level indication, so we can see the
> increasing simulation levels.
>
> The tower keeps going, but the DDD's terminate.
>
> If the memory management is done right, this should execute
> indefinitely.
>
> Because it is not recursion, it is not chewing up space in a linear
> stack. Every simuation gets a stack and state buffers from Allocate,
> which can be released when the simulation terminates, keeping the peak
> memory use constant.
Why are you complicating things, Kaz? It is really quite simple: D does
the opposite of what H(D) reports thus H is wrong. Nothing more needs to
be said on the matter.
/Flibble
--
meet ever shorter deadlines, known as "beat the clock"
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-11-05 20:04 +0800 |
| Subject | Re: Semantic properties of finite string inputs --- Closure ??? |
| Message-ID | <21ac013b99d4a0420586bcae80cb4ccf7bab3b04.camel@gmail.com> |
| In reply to | #135028 |
On Tue, 2025-11-04 at 21:04 +0000, Mr Flibble wrote:
> On Tue, 04 Nov 2025 20:20:04 +0000, Kaz Kylheku wrote:
>
> > On 2025-11-04, olcott <polcott333@gmail.com> wrote:
> > > On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
> > > > Step 11 is the return statement reached by D.
> > > >
> > > > When we continue the simulation D that H started and abandoned,
> > > > its return statement is reached.
> > >
> > > Sure we can do that the same way that you said we could do it for this:
> >
> > Remember, I had only been joking that you might as well regard
> > Infinite_Loop as halting. Obviously it isn't
> >
> > > void Infinite_Loop()
> > > {
> > > HERE: goto HERE;
> > > return;
> > > }
> >
> > If you substitute that for D in my above simulation, you will find that,
> > no, that doesn't terminate. The example H will give up after the three
> > steps, just like before, and return 0, leaving an abandoned #<interp0>
> > simulation.
> >
> > When we continue stepping the abandoned #<interp0>, it will just be
> > trapped in the HERE: goto HERE (confirming that 0 was the correct return
> > value).
> >
> > It is specifically the diagonal D which reaches its return statement due
> > to H's return value being 0, including in simulation.
> >
> > Mike Terry posted some new execution traces from the x86utm with
> > reckoning continuation. He wrote a new test case: a clean version of HHH
> > and DDD (called MJT_HHH and MJT_DDD) which do not rely on mutated static
> > data:
> >
> > He's getting a nice "infinite tower" in which every MJT_HHH returns 0 to
> > its respective MJT_DDD, which then terminates.
> > He posted this:
> >
> > Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as HHH, but
> > without the global variable misuse. HHH[0] decides
> > non-halting. Resumed simulations all halt with same behaviour
> > as HHH[n] deciding non-halting (like HHH[0]) then DDD[n]
> > returning.
> > DDD[1] ends, after HHH[1] detects "infinite recursion" and returns
> > 0.
> > DDD[2] ends, after HHH[2] detects "infinite recursion" and returns
> > 0.
> > DDD[3] ends, after HHH[3] detects "infinite recursion" and returns
> > 0.
> > DDD[4] ends, after HHH[4] detects "infinite recursion" and returns
> > 0.
> >
> > Mike added back your square brackets level indication, so we can see the
> > increasing simulation levels.
> >
> > The tower keeps going, but the DDD's terminate.
> >
> > If the memory management is done right, this should execute
> > indefinitely.
> >
> > Because it is not recursion, it is not chewing up space in a linear
> > stack. Every simuation gets a stack and state buffers from Allocate,
> > which can be released when the simulation terminates, keeping the peak
> > memory use constant.
>
> Why are you complicating things, Kaz? It is really quite simple: D does
> the opposite of what H(D) reports thus H is wrong. Nothing more needs to
> be said on the matter.
>
> /Flibble
>
I think Kaz and Mike were discussing their model of theory, not really
the HP.
To me, the basic idea of HP proof is a simple fact. All theories cannot
defy, whatever they are. If they can address the HP problem, they must
conform the fact.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-05 09:50 -0600 |
| Subject | Re: Semantic properties of finite string inputs --- Closure !!! |
| Message-ID | <10efrod$ghhe$1@dont-email.me> |
| In reply to | #135062 |
On 11/5/2025 6:04 AM, wij wrote:
> On Tue, 2025-11-04 at 21:04 +0000, Mr Flibble wrote:
>> On Tue, 04 Nov 2025 20:20:04 +0000, Kaz Kylheku wrote:
>>
>>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>>> Step 11 is the return statement reached by D.
>>>>>
>>>>> When we continue the simulation D that H started and abandoned,
>>>>> its return statement is reached.
>>>>
>>>> Sure we can do that the same way that you said we could do it for this:
>>>
>>> Remember, I had only been joking that you might as well regard
>>> Infinite_Loop as halting. Obviously it isn't
>>>
>>>> void Infinite_Loop()
>>>> {
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>
>>> If you substitute that for D in my above simulation, you will find that,
>>> no, that doesn't terminate. The example H will give up after the three
>>> steps, just like before, and return 0, leaving an abandoned #<interp0>
>>> simulation.
>>>
>>> When we continue stepping the abandoned #<interp0>, it will just be
>>> trapped in the HERE: goto HERE (confirming that 0 was the correct return
>>> value).
>>>
>>> It is specifically the diagonal D which reaches its return statement due
>>> to H's return value being 0, including in simulation.
>>>
>>> Mike Terry posted some new execution traces from the x86utm with
>>> reckoning continuation. He wrote a new test case: a clean version of HHH
>>> and DDD (called MJT_HHH and MJT_DDD) which do not rely on mutated static
>>> data:
>>>
>>> He's getting a nice "infinite tower" in which every MJT_HHH returns 0 to
>>> its respective MJT_DDD, which then terminates.
>>> He posted this:
>>>
>>> Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as HHH, but
>>> without the global variable misuse. HHH[0] decides
>>> non-halting. Resumed simulations all halt with same behaviour
>>> as HHH[n] deciding non-halting (like HHH[0]) then DDD[n]
>>> returning.
>>> DDD[1] ends, after HHH[1] detects "infinite recursion" and returns
>>> 0.
>>> DDD[2] ends, after HHH[2] detects "infinite recursion" and returns
>>> 0.
>>> DDD[3] ends, after HHH[3] detects "infinite recursion" and returns
>>> 0.
>>> DDD[4] ends, after HHH[4] detects "infinite recursion" and returns
>>> 0.
>>>
>>> Mike added back your square brackets level indication, so we can see the
>>> increasing simulation levels.
>>>
>>> The tower keeps going, but the DDD's terminate.
>>>
>>> If the memory management is done right, this should execute
>>> indefinitely.
>>>
>>> Because it is not recursion, it is not chewing up space in a linear
>>> stack. Every simuation gets a stack and state buffers from Allocate,
>>> which can be released when the simulation terminates, keeping the peak
>>> memory use constant.
>>
>> Why are you complicating things, Kaz? It is really quite simple: D does
>> the opposite of what H(D) reports thus H is wrong. Nothing more needs to
>> be said on the matter.
>>
>> /Flibble
>>
>
> I think Kaz and Mike were discussing their model of theory, not really
> the HP.
>
> To me, the basic idea of HP proof is a simple fact. All theories cannot
> defy, whatever they are. If they can address the HP problem, they must
> conform the fact.
>
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
> On 2025-11-05, olcott <polcott333@gmail.com> wrote:
>>
>> The whole point is that D simulated by H
>> cannot possbly reach its own simulated
>> "return" statement no matter what H does.
>
> Yes; this doesn't happen while H is running.
>
> So while H does /something/, no matter what H does,
> that D simulation won't reach the return statement.
>
Kaz finally affirmed the key element of my proof
after waiting three years for this.
--
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 17:51 +0000 |
| Subject | Re: Semantic properties of finite string inputs --- Closure !!! |
| Message-ID | <20251105094033.724@kylheku.com> |
| In reply to | #135066 |
On 2025-11-05, olcott <polcott333@gmail.com> wrote:
> On 11/5/2025 6:04 AM, wij wrote:
>> On Tue, 2025-11-04 at 21:04 +0000, Mr Flibble wrote:
>>> On Tue, 04 Nov 2025 20:20:04 +0000, Kaz Kylheku wrote:
>>>
>>>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>>>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>>>> Step 11 is the return statement reached by D.
>>>>>>
>>>>>> When we continue the simulation D that H started and abandoned,
>>>>>> its return statement is reached.
>>>>>
>>>>> Sure we can do that the same way that you said we could do it for this:
>>>>
>>>> Remember, I had only been joking that you might as well regard
>>>> Infinite_Loop as halting. Obviously it isn't
>>>>
>>>>> void Infinite_Loop()
>>>>> {
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>
>>>> If you substitute that for D in my above simulation, you will find that,
>>>> no, that doesn't terminate. The example H will give up after the three
>>>> steps, just like before, and return 0, leaving an abandoned #<interp0>
>>>> simulation.
>>>>
>>>> When we continue stepping the abandoned #<interp0>, it will just be
>>>> trapped in the HERE: goto HERE (confirming that 0 was the correct return
>>>> value).
>>>>
>>>> It is specifically the diagonal D which reaches its return statement due
>>>> to H's return value being 0, including in simulation.
>>>>
>>>> Mike Terry posted some new execution traces from the x86utm with
>>>> reckoning continuation. He wrote a new test case: a clean version of HHH
>>>> and DDD (called MJT_HHH and MJT_DDD) which do not rely on mutated static
>>>> data:
>>>>
>>>> He's getting a nice "infinite tower" in which every MJT_HHH returns 0 to
>>>> its respective MJT_DDD, which then terminates.
>>>> He posted this:
>>>>
>>>> Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as HHH, but
>>>> without the global variable misuse. HHH[0] decides
>>>> non-halting. Resumed simulations all halt with same behaviour
>>>> as HHH[n] deciding non-halting (like HHH[0]) then DDD[n]
>>>> returning.
>>>> DDD[1] ends, after HHH[1] detects "infinite recursion" and returns
>>>> 0.
>>>> DDD[2] ends, after HHH[2] detects "infinite recursion" and returns
>>>> 0.
>>>> DDD[3] ends, after HHH[3] detects "infinite recursion" and returns
>>>> 0.
>>>> DDD[4] ends, after HHH[4] detects "infinite recursion" and returns
>>>> 0.
>>>>
>>>> Mike added back your square brackets level indication, so we can see the
>>>> increasing simulation levels.
>>>>
>>>> The tower keeps going, but the DDD's terminate.
>>>>
>>>> If the memory management is done right, this should execute
>>>> indefinitely.
>>>>
>>>> Because it is not recursion, it is not chewing up space in a linear
>>>> stack. Every simuation gets a stack and state buffers from Allocate,
>>>> which can be released when the simulation terminates, keeping the peak
>>>> memory use constant.
>>>
>>> Why are you complicating things, Kaz? It is really quite simple: D does
>>> the opposite of what H(D) reports thus H is wrong. Nothing more needs to
>>> be said on the matter.
>>>
>>> /Flibble
>>>
>>
>> I think Kaz and Mike were discussing their model of theory, not really
>> the HP.
>>
>> To me, the basic idea of HP proof is a simple fact. All theories cannot
>> defy, whatever they are. If they can address the HP problem, they must
>> conform the fact.
>>
>
>
> On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
> > On 2025-11-05, olcott <polcott333@gmail.com> wrote:
> >>
> >> The whole point is that D simulated by H
> >> cannot possbly reach its own simulated
> >> "return" statement no matter what H does.
> >
> > Yes; this doesn't happen while H is running.
> >
> > So while H does /something/, no matter what H does,
> > that D simulation won't reach the return statement.
> >
>
> Kaz finally affirmed the key element of my proof
> after waiting three years for this.
But that has never been controversial.
The simulating procedure H(P) can never finish simulating its diagonal
case D, because no matter how H is defined, D requires more steps than H
performs.
H "spends" a certain "budget" of simulation steps and returns false;
that budget is always too short to cover the full cost of simulating D,
which requires a bunch more steps.
You propose the idea that a machine is nonterminating if the initial
portion of its execution steps is carried out by a simulating decider
which quits before that machine reaches its halting state.
Surely you must realize that looks crazy!?
It's not because of poor communication any more: everything is crystal
clear.
What is the rational argument why anyone should adopt your viewpoint?
We have a simulating decider H which rejects anything as nonterminating
if it requires four or more steps.
Obviously, that is incorrect for any machine which terminates in
four steps. And for any machine which terminqates in five steps.
And for any machine which terminates in six steps ...
And then we have D, which terminates in 11 steps; yet for that one,
the false is correct?
I just don't see how that is going to get you written into history
as the researcher who dismantled the halting problem.
--
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-05 12:18 -0800 |
| Subject | Re: Semantic properties of finite string inputs --- Closure !!! |
| Message-ID | <10egbeu$lagb$3@dont-email.me> |
| In reply to | #135073 |
On 11/5/2025 9:51 AM, Kaz Kylheku wrote:
> On 2025-11-05, olcott <polcott333@gmail.com> wrote:
>> On 11/5/2025 6:04 AM, wij wrote:
>>> On Tue, 2025-11-04 at 21:04 +0000, Mr Flibble wrote:
>>>> On Tue, 04 Nov 2025 20:20:04 +0000, Kaz Kylheku wrote:
>>>>
>>>>> On 2025-11-04, olcott <polcott333@gmail.com> wrote:
>>>>>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>>>>> Step 11 is the return statement reached by D.
>>>>>>>
>>>>>>> When we continue the simulation D that H started and abandoned,
>>>>>>> its return statement is reached.
>>>>>>
>>>>>> Sure we can do that the same way that you said we could do it for this:
>>>>>
>>>>> Remember, I had only been joking that you might as well regard
>>>>> Infinite_Loop as halting. Obviously it isn't
>>>>>
>>>>>> void Infinite_Loop()
>>>>>> {
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>
>>>>> If you substitute that for D in my above simulation, you will find that,
>>>>> no, that doesn't terminate. The example H will give up after the three
>>>>> steps, just like before, and return 0, leaving an abandoned #<interp0>
>>>>> simulation.
>>>>>
>>>>> When we continue stepping the abandoned #<interp0>, it will just be
>>>>> trapped in the HERE: goto HERE (confirming that 0 was the correct return
>>>>> value).
>>>>>
>>>>> It is specifically the diagonal D which reaches its return statement due
>>>>> to H's return value being 0, including in simulation.
>>>>>
>>>>> Mike Terry posted some new execution traces from the x86utm with
>>>>> reckoning continuation. He wrote a new test case: a clean version of HHH
>>>>> and DDD (called MJT_HHH and MJT_DDD) which do not rely on mutated static
>>>>> data:
>>>>>
>>>>> He's getting a nice "infinite tower" in which every MJT_HHH returns 0 to
>>>>> its respective MJT_DDD, which then terminates.
>>>>> He posted this:
>>>>>
>>>>> Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as HHH, but
>>>>> without the global variable misuse. HHH[0] decides
>>>>> non-halting. Resumed simulations all halt with same behaviour
>>>>> as HHH[n] deciding non-halting (like HHH[0]) then DDD[n]
>>>>> returning.
>>>>> DDD[1] ends, after HHH[1] detects "infinite recursion" and returns
>>>>> 0.
>>>>> DDD[2] ends, after HHH[2] detects "infinite recursion" and returns
>>>>> 0.
>>>>> DDD[3] ends, after HHH[3] detects "infinite recursion" and returns
>>>>> 0.
>>>>> DDD[4] ends, after HHH[4] detects "infinite recursion" and returns
>>>>> 0.
>>>>>
>>>>> Mike added back your square brackets level indication, so we can see the
>>>>> increasing simulation levels.
>>>>>
>>>>> The tower keeps going, but the DDD's terminate.
>>>>>
>>>>> If the memory management is done right, this should execute
>>>>> indefinitely.
>>>>>
>>>>> Because it is not recursion, it is not chewing up space in a linear
>>>>> stack. Every simuation gets a stack and state buffers from Allocate,
>>>>> which can be released when the simulation terminates, keeping the peak
>>>>> memory use constant.
>>>>
>>>> Why are you complicating things, Kaz? It is really quite simple: D does
>>>> the opposite of what H(D) reports thus H is wrong. Nothing more needs to
>>>> be said on the matter.
>>>>
>>>> /Flibble
>>>>
>>>
>>> I think Kaz and Mike were discussing their model of theory, not really
>>> the HP.
>>>
>>> To me, the basic idea of HP proof is a simple fact. All theories cannot
>>> defy, whatever they are. If they can address the HP problem, they must
>>> conform the fact.
>>>
>>
>>
>> On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
>>> On 2025-11-05, olcott <polcott333@gmail.com> wrote:
>>>>
>>>> The whole point is that D simulated by H
>>>> cannot possbly reach its own simulated
>>>> "return" statement no matter what H does.
>>>
>>> Yes; this doesn't happen while H is running.
>>>
>>> So while H does /something/, no matter what H does,
>>> that D simulation won't reach the return statement.
>>>
>>
>> Kaz finally affirmed the key element of my proof
>> after waiting three years for this.
>
> But that has never been controversial.
>
> The simulating procedure H(P) can never finish simulating its diagonal
> case D, because no matter how H is defined, D requires more steps than H
> performs.
>
> H "spends" a certain "budget" of simulation steps and returns false;
> that budget is always too short to cover the full cost of simulating D,
> which requires a bunch more steps.
>
> You propose the idea that a machine is nonterminating if the initial
> portion of its execution steps is carried out by a simulating decider
> which quits before that machine reaches its halting state.
>
> Surely you must realize that looks crazy!?
>
> It's not because of poor communication any more: everything is crystal
> clear.
>
> What is the rational argument why anyone should adopt your viewpoint?
>
> We have a simulating decider H which rejects anything as nonterminating
> if it requires four or more steps.
>
> Obviously, that is incorrect for any machine which terminates in
> four steps. And for any machine which terminqates in five steps.
> And for any machine which terminates in six steps ...
>
> And then we have D, which terminates in 11 steps; yet for that one,
> the false is correct?
>
> I just don't see how that is going to get you written into history
> as the researcher who dismantled the halting problem.
>
He might be too daft to explore the fuzzer. It makes sure all paths are
hit. It will play along for infinity... Say the user/fuzzer exposes DD
to data that makes it hit the non-halt path over and over again...
Olcott swoops in and cancels it before the program was completed!
Actually, it would have halted, but the PO moron said no, I know better.
Scary!
Good thing that Olcott is not going to make any processors any time
soon. Heck... A server loop gets aborted because Olcott says it ran too
long. All of the open and running connections get cut off, the server
dies. Olcott is there on a soap box saying I told you it was
non-terminating, that why I aborted it.
[toc] | [prev] | [next] | [standalone]
Page 5 of 15 — ← Prev page 1 … 3 4 [5] 6 7 … 15 Next page →
Back to top | Article view | comp.theory
csiph-web