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 4 of 15 — ← Prev page 1 2 3 [4] 5 6 … 15 Next page →
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-10-30 22:59 -0400 |
| Message-ID | <10e18n8$5qnl$4@dont-email.me> |
| In reply to | #134428 |
On 10/30/2025 10:56 PM, olcott wrote:
> On 10/30/2025 9:50 PM, dbush wrote:
>> On 10/30/2025 10:48 PM, olcott wrote:
>>> On 10/30/2025 9:10 PM, dbush wrote:
>>>> On 10/30/2025 10:07 PM, olcott wrote:
>>>>> On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote:
>>>>>>> THERE IS A DIFFERENT FUCKING SEQUENCE OF
>>>>>>> INSTRUCTIONS DIP SHIT !!!
>>>>>>
>>>>>> While the overall sequence of instructions in the entire scenario is
>>>>>> different between H(D) and UTM(D), if we just at /just/ the
>>>>>> instructions
>>>>>> of the simulated D, those are the same.
>>>>>
>>>>> No not even that. D is simulated by H more than once
>>>>> and only simulated by H1 once.
>>>>
>>>> False. D is simulated by the top level H (which is the only one
>>>> that matters)
>>>
>>> What the fuck kind of lame bullshit is this dip shit?
>>> Unless H aborts
>> Strawman. Then you're not longer talking about H and D.
>
> Yes I am you stupid fuck.
No you're not. These are not the same machine:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-31 03:35 +0000 |
| Message-ID | <20251030203007.148@kylheku.com> |
| In reply to | #134424 |
On 2025-10-31, olcott <polcott333@gmail.com> wrote: > *I tried being nice and you took that as weakness* I wish you luck with your career transition to Hip Hop Lyricist. -- 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-10-31 03:29 +0000 |
| Message-ID | <20251030201848.941@kylheku.com> |
| In reply to | #134414 |
On 2025-10-31, olcott <polcott333@gmail.com> wrote:
> On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
>> On 2025-10-30, olcott <polcott333@gmail.com> wrote:
>>> THERE IS A DIFFERENT FUCKING SEQUENCE OF
>>> INSTRUCTIONS DIP SHIT !!!
>>
>> While the overall sequence of instructions in the entire scenario is
>> different between H(D) and UTM(D), if we just at /just/ the instructions
>> of the simulated D, those are the same.
>
> No not even that. D is simulated by H more than once
> and only simulated by H1 once.
>
>> In the case of H, the
>> simulation is left incomplete,
>
> In the same way that the simulation of
>
> void Infinite_Recursion()
> {
> Infinite_Recursion();
> return;
> }
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> return;
> }
>
> is left incomplete in that an infinite simulation
Yes, those are also incomplete. More steps of them can be performed; but
of course they can never be completed.
D is a terminating procedure of which a simulation is left incomplete.
>> but the instructions up to the point
>> where it is are the same as those for UTM(D), and so from there it
>> continues to be the same.
>>
>
> Not at all. at the point where D calls H(D) they
> diverge.
You have not showed with code that they do.
I have showed with code that they don't.
Showed beats not showed.
>> You obviously don't understand this and are taking guesses
>> without making any specific references to specific code.
>
> That is such a ridiculously stupid thing to say that
> I cannot imagine that it is not simply a damned lie.
Then stop giving evidence for it with every empty puff of air you push
from under your keyboard membrane.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-30 22:47 -0500 |
| Message-ID | <10e1bfo$6q9m$1@dont-email.me> |
| In reply to | #134447 |
On 10/30/2025 10:29 PM, Kaz Kylheku wrote:
> On 2025-10-31, olcott <polcott333@gmail.com> wrote:
>> On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote:
>>>> THERE IS A DIFFERENT FUCKING SEQUENCE OF
>>>> INSTRUCTIONS DIP SHIT !!!
>>>
>>> While the overall sequence of instructions in the entire scenario is
>>> different between H(D) and UTM(D), if we just at /just/ the instructions
>>> of the simulated D, those are the same.
>>
>> No not even that. D is simulated by H more than once
>> and only simulated by H1 once.
>>
>>> In the case of H, the
>>> simulation is left incomplete,
>>
>> In the same way that the simulation of
>>
>> void Infinite_Recursion()
>> {
>> Infinite_Recursion();
>> return;
>> }
>>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> return;
>> }
>>
>> is left incomplete in that an infinite simulation
>
> Yes, those are also incomplete. More steps of them can be performed; but
> of course they can never be completed.
>
> D is a terminating procedure of which a simulation is left incomplete.
>
>>> but the instructions up to the point
>>> where it is are the same as those for UTM(D), and so from there it
>>> continues to be the same.
>>>
>>
>> Not at all. at the point where D calls H(D) they
>> diverge.
>
> You have not showed with code that they do.
>
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H1 simulates D --- ONCE
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
H simulates D --- SIX TIMES
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;
You can't be that stupid.
Are you much more stupid than Ben?
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
--
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-10-31 04:39 +0000 |
| Message-ID | <20251030212645.97@kylheku.com> |
| In reply to | #134450 |
On 2025-10-31, olcott <polcott333@gmail.com> wrote:
> On 10/30/2025 10:29 PM, Kaz Kylheku wrote:
>> On 2025-10-31, olcott <polcott333@gmail.com> wrote:
>>> On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote:
>>>>> THERE IS A DIFFERENT FUCKING SEQUENCE OF
>>>>> INSTRUCTIONS DIP SHIT !!!
>>>>
>>>> While the overall sequence of instructions in the entire scenario is
>>>> different between H(D) and UTM(D), if we just at /just/ the instructions
>>>> of the simulated D, those are the same.
>>>
>>> No not even that. D is simulated by H more than once
>>> and only simulated by H1 once.
>>>
>>>> In the case of H, the
>>>> simulation is left incomplete,
>>>
>>> In the same way that the simulation of
>>>
>>> void Infinite_Recursion()
>>> {
>>> Infinite_Recursion();
>>> return;
>>> }
>>>
>>> void Infinite_Loop()
>>> {
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> is left incomplete in that an infinite simulation
>>
>> Yes, those are also incomplete. More steps of them can be performed; but
>> of course they can never be completed.
>>
>> D is a terminating procedure of which a simulation is left incomplete.
>>
>>>> but the instructions up to the point
>>>> where it is are the same as those for UTM(D), and so from there it
>>>> continues to be the same.
>>>>
>>>
>>> Not at all. at the point where D calls H(D) they
>>> diverge.
>>
>> You have not showed with code that they do.
>>
>
>
> int D()
> {
> int Halt_Status = H(D);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> H1 simulates D --- ONCE
> that calls H(D) to simulate D
> then H(D) returns 0 to caller D
... that D returns and ...
> then H1 returns 1;
>
> H simulates D --- SIX TIMES
> 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;
I've not seen a test case which goes six deep;
Maybe you had such at some some point?
It is possible tweak the abort criteria so that a depth of six has to be
seen; it will take a considerably large execution trace buffer (even
my sliding window modification may not help; some filtering will
have to be added to only record those events that are needed for
the abort decision).
There is an interpretation factor at each level; it takes many
instructions at one level to run one complete DebugStep cycle and the
rest of the loop around it, which achieves just one instruction at the
level below.
Let's say that the factor is 100: 100 instructions.
To have these levels:
H simulates D --- SIX TIMES (10000000000 instructions)
that calls H(D) to simulate D (100000000 instructions)
that calls H(D) to simulate D (1000000 instructions)
that calls H(D) to simulate D (10000 instructions)
that calls H(D) to simulate D (100 instructions)
that calls H(D) to simulate D (1 instruction)
With all these levels, one instruction at the most nested level takes
ten billion instructions (under an in terpretation factor of 100, which
seems conservative for the x86emu and the DebugStep and Decide_Halting
wrappers around it.) Every DebugStep does a LoadState and SaveState and
such. It all costs cycles; the real interpretation factor is probably
much higher, probably several hundred? We can add instrumentation
to figure that out.
You must have run this 6-stack sandwich for days and days ...
> You can't be that stupid.
The only thing stupid about me is giving this any time at all.
There are talented devs out there who can't get anyone to try
their application. You are ungrateful.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-31 07:27 -0500 |
| Message-ID | <10e2a07$fgln$1@dont-email.me> |
| In reply to | #134456 |
On 10/30/2025 11:39 PM, Kaz Kylheku wrote:
> On 2025-10-31, olcott <polcott333@gmail.com> wrote:
>> On 10/30/2025 10:29 PM, Kaz Kylheku wrote:
>>> On 2025-10-31, olcott <polcott333@gmail.com> wrote:
>>>> On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote:
>>>>>> THERE IS A DIFFERENT FUCKING SEQUENCE OF
>>>>>> INSTRUCTIONS DIP SHIT !!!
>>>>>
>>>>> While the overall sequence of instructions in the entire scenario is
>>>>> different between H(D) and UTM(D), if we just at /just/ the instructions
>>>>> of the simulated D, those are the same.
>>>>
>>>> No not even that. D is simulated by H more than once
>>>> and only simulated by H1 once.
>>>>
>>>>> In the case of H, the
>>>>> simulation is left incomplete,
>>>>
>>>> In the same way that the simulation of
>>>>
>>>> void Infinite_Recursion()
>>>> {
>>>> Infinite_Recursion();
>>>> return;
>>>> }
>>>>
>>>> void Infinite_Loop()
>>>> {
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> is left incomplete in that an infinite simulation
>>>
>>> Yes, those are also incomplete. More steps of them can be performed; but
>>> of course they can never be completed.
>>>
>>> D is a terminating procedure of which a simulation is left incomplete.
>>>
>>>>> but the instructions up to the point
>>>>> where it is are the same as those for UTM(D), and so from there it
>>>>> continues to be the same.
>>>>>
>>>>
>>>> Not at all. at the point where D calls H(D) they
>>>> diverge.
>>>
>>> You have not showed with code that they do.
>>>
>>
>>
>> int D()
>> {
>> int Halt_Status = H(D);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> H1 simulates D --- ONCE
>> that calls H(D) to simulate D
>> then H(D) returns 0 to caller D
>
> ... that D returns and ...
>
That D does not call its own simulator in
recursive simulation.
>> then H1 returns 1;
>>
>> H simulates D --- SIX TIMES
>> 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;
>
> I've not seen a test case which goes six deep;
>
> Maybe you had such at some some point?
>
This is H and D not HHH and DD.
The basis can be construed as being run in a C interpreter.
> It is possible tweak the abort criteria so that a depth of six has to be
> seen; it will take a considerably large execution trace buffer (even
> my sliding window modification may not help; some filtering will
> have to be added to only record those events that are needed for
> the abort decision).
>
> There is an interpretation factor at each level; it takes many
> instructions at one level to run one complete DebugStep cycle and the
> rest of the loop around it, which achieves just one instruction at the
> level below.
>
> Let's say that the factor is 100: 100 instructions.
>
> To have these levels:
>
> H simulates D --- SIX TIMES (10000000000 instructions)
> that calls H(D) to simulate D (100000000 instructions)
> that calls H(D) to simulate D (1000000 instructions)
> that calls H(D) to simulate D (10000 instructions)
> that calls H(D) to simulate D (100 instructions)
> that calls H(D) to simulate D (1 instruction)
>
> With all these levels, one instruction at the most nested level takes
> ten billion instructions (under an in terpretation factor of 100, which
> seems conservative for the x86emu and the DebugStep and Decide_Halting
> wrappers around it.) Every DebugStep does a LoadState and SaveState and
> such. It all costs cycles; the real interpretation factor is probably
> much higher, probably several hundred? We can add instrumentation
> to figure that out.
>
> You must have run this 6-stack sandwich for days and days ...
>
>> You can't be that stupid.
>
> The only thing stupid about me is giving this any time at all.
>
> There are talented devs out there who can't get anyone to try
> their application. You are ungrateful.
>
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-30 17:32 -0500 |
| Message-ID | <10e0p20$2479$1@dont-email.me> |
| In reply to | #134400 |
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
> On 2025-10-30, olcott <polcott333@gmail.com> wrote:
>> On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote:
>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote:
>>>>>> H and H1 are identical except that D does not call H1.
>>>>>
>>>>> This is idiotic and exposes you as someone with the mathematical
>>>>> maturity of a toddler.
>>>>>
>>>>> Function names are not significant in the mathematics of
>>>>> recursive functions.
>>>>>
>>>>
>>>> Sure they are nitwit otherwise how the fuck
>>>> can to do-the-opposite case be constructed nitwit?
>>>
>>> The diagonal test case does not depend on name equivalence of functions.
>>> (The idea that two otherwise identical functions with different names
>>> are different functions.)
>>>
>>> There is no such preposterious garbage in the theory of
>>> recursive functions, or pretty much anywhere in math.
>>>
>>
>> Then show me how the fuck that this Linz case works
>> without names dip shit!
>
> I didn't say "without names", but "without an entity
> being considered two different entities juwst because
> it is referenced by two names".
>
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;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-10-30 17:01 -0700 |
| Message-ID | <10e0u9m$3ne3$2@dont-email.me> |
| In reply to | #134403 |
On 10/30/2025 3:32 PM, olcott wrote:
> On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
>> On 2025-10-30, olcott <polcott333@gmail.com> wrote:
>>> On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote:
>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote:
>>>>>>> H and H1 are identical except that D does not call H1.
>>>>>>
>>>>>> This is idiotic and exposes you as someone with the mathematical
>>>>>> maturity of a toddler.
>>>>>>
>>>>>> Function names are not significant in the mathematics of
>>>>>> recursive functions.
>>>>>>
>>>>>
>>>>> Sure they are nitwit otherwise how the fuck
>>>>> can to do-the-opposite case be constructed nitwit?
>>>>
>>>> The diagonal test case does not depend on name equivalence of
>>>> functions.
>>>> (The idea that two otherwise identical functions with different names
>>>> are different functions.)
>>>>
>>>> There is no such preposterious garbage in the theory of
>>>> recursive functions, or pretty much anywhere in math.
>>>>
>>>
>>> Then show me how the fuck that this Linz case works
>>> without names dip shit!
>>
>> I didn't say "without names", but "without an entity
>> being considered two different entities juwst because
>> it is referenced by two names".
>>
>
> 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;
>
> THERE IS A DIFFERENT FUCKING SEQUENCE OF
> INSTRUCTIONS DIP SHIT !!!
>
>
Try not to channel dart?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2025-10-31 00:57 +0000 |
| Message-ID | <87pla3nb0e.fsf@bsb.me.uk> |
| In reply to | #134400 |
Kaz Kylheku <643-408-1753@kylheku.com> writes: > But, yes, come to think of it, the diagonal halting situation > can be worked without names. > > Using a construction known as the Y combinator, we can pass > a function to itself as an argument without giving it > a defined name. > > The decider can also be passed in as a lambda. > > We can eliminate parameter names. using De Bruijn indices. > > So there you have homework: look up lambda calculus, Y combinator, > De Bruijn indices. And, as I am sure you know, the whole of combinatory logic was developed as an alternative way to do away with all names, in particular the parameter names of the lambda calculus. With combinator logic, you don't need De Bruijn indices. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-10-30 16:44 -0400 |
| Message-ID | <10e0inm$3v5mk$1@dont-email.me> |
| In reply to | #134388 |
On 10/30/2025 4:25 PM, olcott wrote:
> On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
>> On 2025-10-30, olcott <polcott333@gmail.com> wrote:
>>> H and H1 are identical except that D does not call H1.
>>
>> This is idiotic and exposes you as someone with the mathematical
>> maturity of a toddler.
>>
>> Function names are not significant in the mathematics of
>> recursive functions.
>>
>
> Sure they are nitwit otherwise how the fuck
> can to do-the-opposite case be constructed nitwit?
Like this:
Given algorithm X contained in function bar:
int bar(void *p)
{
int rval;
{
void(p);
rval = 0;
}
return 0;
}
And algorithm Y contained in function foo:
void foo()
{
void *p = foo;
int rval;
{
void(p);
rval = 0;
}
if (rval == 0)
while(1);
}
Algorithm Y is the diagonal case for algorithm X.
i.e. when algorithm X is given algorithm Y as input (implemented as the
C function call bar(foo)) it gives the wrong answer.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2025-10-31 13:28 +0200 |
| Message-ID | <10e26gc$eavi$1@dont-email.me> |
| In reply to | #134369 |
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.
> 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.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-31 07:44 -0500 |
| Message-ID | <10e2av3$ft23$1@dont-email.me> |
| In reply to | #134467 |
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.
>
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2025-11-01 10:42 +0200 |
| Message-ID | <10e4h5o$14jq9$1@dont-email.me> |
| In reply to | #134485 |
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.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-01 08:25 -0500 |
| Message-ID | <10e51om$19ngq$1@dont-email.me> |
| In reply to | #134631 |
On 11/1/2025 3:42 AM, Mikko wrote:
> On 2025-10-31 12:44:17 +0000, olcott said:
>
>> On 10/31/2025 6:28 AM, Mikko wrote:
>>> On 2025-10-30 14:49:08 +0000, olcott said:
>>>
>>>> D simulated by H measures the semantic property
>>>> of the actual input as opposed to and contrast
>>>> with the semantic property of a non-input. H and
>>>> H1 are identical except that D does not call H1.
>>>
>>> Being identical means that H and H1 compute the same semantic
>>> property.
>>>
>>
>> int D()
>> {
>> int Halt_Status = H(D);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> H simulates D
>> that calls H(D) to simulate D
>> that calls H(D) to simulate D
>> that calls H(D) to simulate D
>> that calls H(D) to simulate D
>> that calls H(D) to simulate D
>> until H sees this repeating pattern
>> Then H returns 0;
>>
>> H1 simulates D
>> that calls H(D) to simulate D
>> then H(D) returns 0 to caller D
>> then H1 returns 1;
>>
>> It turns out that my big discovery the overturns
>> part of the foundation of computer science is that
>> the semantic property can be relative to the decider.
>>
>> It actually always relative to the decider yet this
>> has never made any difference with non-self-referential
>> inputs. H(D) != UTM(D) == H1(D)
>>
>> The halting problem has always been an issue where
>> the halt decider has never been smart enough to
>> figure out halting for self-contradictory inputs.
>> That never has been the real issue.
>>
>> int D()
>> {
>> int Halt_Status = H(D);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> With a simulating halt decider D simulated by
>> H never reaches the contradictory part. It
>> stays stuck on its first line.
>>
>> H and D do get stuck in recursive simulation. H
>> can and does see this. H does abort its own simulation
>> of D to prevent its own non-termination.
>>
>> The real issue (that could not be seen until I created
>> the notion of a simulating halt decider in 2016) is
>> that the halting problem requires H to report on
>> behavior other than the behavior that its actual input
>> actually specifies.
>>
>> int sum(int x, int y){ return x + y; }
>> this is the same as requiring sum(3,4) to report on
>> the sum of 5 + 6.
>>
>>
>>>> We can tell an input from a non-input because an
>>>> input is an argument to the function H.
>>>>
>>>> D.input_to_H
>>>> specifies different behavior than
>>>> D.input_to_H1.
>>>>
>>>> int D()
>>>> {
>>>> int Halt_Status = H(D);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> H simulates D
>>>> that calls H(D) to simulate D
>>>> that calls H(D) to simulate D
>>>> that calls H(D) to simulate D
>>>> that calls H(D) to simulate D
>>>> that calls H(D) to simulate D
>>>> until H sees this repeating pattern
>>>> Then H returns 0;
>>>>
>>>> H1 simulates D
>>>> that calls H(D) to simulate D
>>>> then H(D) returns 0 to caller D
>>>> then H1 returns 1;
>>>
>>> As H and H1 return different values for the same input they are
>>> found to be non-identical, contrary to the initial claim.
>
> The above confirms that H and H1 give different results for the same
> input. By the meanngs of the words H and H1 are not equivalent.
>
I never claimed that the were equivalent.
I claimed that HD)==0 and H1(D)==1 proving
that they are not equivalent.
The key thing here is that they are both reporting
on the actual sequence of steps that their actual
input actually specifies.
Anything more than this is outside of the scope
of deciders in general.
--
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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-11-01 09:51 -0400 |
| Message-ID | <10e5396$19neq$3@dont-email.me> |
| In reply to | #134657 |
On 11/1/2025 9:25 AM, olcott wrote:
> On 11/1/2025 3:42 AM, Mikko wrote:
>> On 2025-10-31 12:44:17 +0000, olcott said:
>>
>>> On 10/31/2025 6:28 AM, Mikko wrote:
>>>> On 2025-10-30 14:49:08 +0000, olcott said:
>>>>
>>>>> D simulated by H measures the semantic property
>>>>> of the actual input as opposed to and contrast
>>>>> with the semantic property of a non-input. H and
>>>>> H1 are identical except that D does not call H1.
>>>>
>>>> Being identical means that H and H1 compute the same semantic
>>>> property.
>>>>
>>>
>>> int D()
>>> {
>>> int Halt_Status = H(D);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> H simulates D
>>> that calls H(D) to simulate D
>>> that calls H(D) to simulate D
>>> that calls H(D) to simulate D
>>> that calls H(D) to simulate D
>>> that calls H(D) to simulate D
>>> until H sees this repeating pattern
>>> Then H returns 0;
>>>
>>> H1 simulates D
>>> that calls H(D) to simulate D
>>> then H(D) returns 0 to caller D
>>> then H1 returns 1;
>>>
>>> It turns out that my big discovery the overturns
>>> part of the foundation of computer science is that
>>> the semantic property can be relative to the decider.
>>>
>>> It actually always relative to the decider yet this
>>> has never made any difference with non-self-referential
>>> inputs. H(D) != UTM(D) == H1(D)
>>>
>>> The halting problem has always been an issue where
>>> the halt decider has never been smart enough to
>>> figure out halting for self-contradictory inputs.
>>> That never has been the real issue.
>>>
>>> int D()
>>> {
>>> int Halt_Status = H(D);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> With a simulating halt decider D simulated by
>>> H never reaches the contradictory part. It
>>> stays stuck on its first line.
>>>
>>> H and D do get stuck in recursive simulation. H
>>> can and does see this. H does abort its own simulation
>>> of D to prevent its own non-termination.
>>>
>>> The real issue (that could not be seen until I created
>>> the notion of a simulating halt decider in 2016) is
>>> that the halting problem requires H to report on
>>> behavior other than the behavior that its actual input
>>> actually specifies.
>>>
>>> int sum(int x, int y){ return x + y; }
>>> this is the same as requiring sum(3,4) to report on
>>> the sum of 5 + 6.
>>>
>>>
>>>>> We can tell an input from a non-input because an
>>>>> input is an argument to the function H.
>>>>>
>>>>> D.input_to_H
>>>>> specifies different behavior than
>>>>> D.input_to_H1.
>>>>>
>>>>> int D()
>>>>> {
>>>>> int Halt_Status = H(D);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>>
>>>>> H simulates D
>>>>> that calls H(D) to simulate D
>>>>> that calls H(D) to simulate D
>>>>> that calls H(D) to simulate D
>>>>> that calls H(D) to simulate D
>>>>> that calls H(D) to simulate D
>>>>> until H sees this repeating pattern
>>>>> Then H returns 0;
>>>>>
>>>>> H1 simulates D
>>>>> that calls H(D) to simulate D
>>>>> then H(D) returns 0 to caller D
>>>>> then H1 returns 1;
>>>>
>>>> As H and H1 return different values for the same input they are
>>>> found to be non-identical, contrary to the initial claim.
>>
>> The above confirms that H and H1 give different results for the same
>> input. By the meanngs of the words H and H1 are not equivalent.
>>
>
> I never claimed that the were equivalent.
> I claimed that HD)==0 and H1(D)==1 proving
> that they are not equivalent.
>
> The key thing here is that they are both reporting
> on the actual sequence of steps that their actual
> input actually specifies.
False. 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.
Therefore H1(D)==1 is correct and H(D)==0 is incorrect.
>
> Anything more than this is outside of the scope
> of deciders in general.
>
[toc] | [prev] | [next] | [standalone]
| From | Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> |
|---|---|
| Date | 2025-11-01 20:12 +0000 |
| Message-ID | <10e5pjv$1i3jo$1@dont-email.me> |
| In reply to | #134670 |
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 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. That closure can be different because of the different levels of simulation (do we call it "levels of inception" now because of the movie) because H1 and H themselves both need closure, one of which is provided by the physical machine and one by the simulation. -- Tristan Wibberley The message body is Copyright (C) 2025 Tristan Wibberley except citations and quotations noted. All Rights Reserved except that you may, of course, cite it academically giving credit to me, distribute it verbatim as part of a usenet system or its archives, and use it to promote my greatness and general superiority without misrepresentation of my opinions other than my opinion of my greatness and general superiority which you _may_ misrepresent. You definitely MAY NOT train any production AI system with it but you may train experimental AI that will only be used for evaluation of the AI methods it implements.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-01 15:18 -0500 |
| Message-ID | <10e5pum$1i5ig$1@dont-email.me> |
| In reply to | #134721 |
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.
> That closure can be different because of the different levels of
> simulation (do we call it "levels of inception" now because of the
> movie) because H1 and H themselves both need closure, one of which is
> provided by the physical machine and one by the simulation.
>
> --
> Tristan Wibberley
>
> The message body is Copyright (C) 2025 Tristan Wibberley except
> citations and quotations noted. All Rights Reserved except that you may,
> of course, cite it academically giving credit to me, distribute it
> verbatim as part of a usenet system or its archives, and use it to
> promote my greatness and general superiority without misrepresentation
> of my opinions other than my opinion of my greatness and general
> superiority which you _may_ misrepresent. You definitely MAY NOT train
> any production AI system with it but you may train experimental AI that
> will only be used for evaluation of the AI methods it implements.
>
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> |
|---|---|
| Date | 2025-11-01 20:53 +0000 |
| Message-ID | <10e5s0k$1i3jo$7@dont-email.me> |
| In reply to | #134725 |
On 01/11/2025 20:18, olcott wrote: > On 11/1/2025 3:12 PM, Tristan Wibberley wrote: >> I think H(D) might be [a machine], 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. Welll... not really, the machine provides the closures that D requires. I think it might normally be said to be in this case, perhaps, a conditionally fault-injecting C-machine emulator. Outside of your quotes I discuss the ultimate closure from a real machine required to make the virtual machines. -- Tristan Wibberley The message body is Copyright (C) 2025 Tristan Wibberley except citations and quotations noted. All Rights Reserved except that you may, of course, cite it academically giving credit to me, distribute it verbatim as part of a usenet system or its archives, and use it to promote my greatness and general superiority without misrepresentation of my opinions other than my opinion of my greatness and general superiority which you _may_ misrepresent. You definitely MAY NOT train any production AI system with it but you may train experimental AI that will only be used for evaluation of the AI methods it implements.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-01 16:08 -0500 |
| Message-ID | <10e5sst$1j7td$1@dont-email.me> |
| In reply to | #134735 |
On 11/1/2025 3:53 PM, Tristan Wibberley wrote:
> On 01/11/2025 20:18, olcott wrote:
>> On 11/1/2025 3:12 PM, Tristan Wibberley wrote:
>>> I think H(D) might be [a machine], 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.
>
> Welll... not really, the machine provides the closures that D requires.
> I think it might normally be said to be in this case, perhaps, a
> conditionally fault-injecting C-machine emulator.
>
> Outside of your quotes I discuss the ultimate closure from a real
> machine required to make the virtual machines.
>
I have no idea what you are saying.
The C programming language does seem
to define a virtual machine that C
interpreters implement.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am only concerned with D simulated by H
showing the execution trace in C.
I haven't gotten a straight answer to that
simple question from anyone here in three years
of daily posts.
>
> --
> Tristan Wibberley
>
> The message body is Copyright (C) 2025 Tristan Wibberley except
> citations and quotations noted. All Rights Reserved except that you may,
> of course, cite it academically giving credit to me, distribute it
> verbatim as part of a usenet system or its archives, and use it to
> promote my greatness and general superiority without misrepresentation
> of my opinions other than my opinion of my greatness and general
> superiority which you _may_ misrepresent. You definitely MAY NOT train
> any production AI system with it but you may train experimental AI that
> will only be used for evaluation of the AI methods it implements.
>
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@red-dwarf.jmc.corp> |
|---|---|
| Date | 2025-11-01 21:12 +0000 |
| Message-ID | <aJuNQ.39570$kzA2.35849@fx06.ams4> |
| In reply to | #134740 |
On Sat, 01 Nov 2025 16:08:43 -0500, olcott wrote:
> On 11/1/2025 3:53 PM, Tristan Wibberley wrote:
>> On 01/11/2025 20:18, olcott wrote:
>>> On 11/1/2025 3:12 PM, Tristan Wibberley wrote:
>>>> I think H(D) might be [a machine], 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.
>>
>> Welll... not really, the machine provides the closures that D requires.
>> I think it might normally be said to be in this case, perhaps, a
>> conditionally fault-injecting C-machine emulator.
>>
>> Outside of your quotes I discuss the ultimate closure from a real
>> machine required to make the virtual machines.
>>
>>
> I have no idea what you are saying.
> The C programming language does seem to define a virtual machine that C
> interpreters implement.
>
> int D()
> {
> int Halt_Status = H(D);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
>
> I am only concerned with D simulated by H showing the execution trace in
> C.
>
> I haven't gotten a straight answer to that simple question from anyone
> here in three years of daily posts.
>
>
>> --
>> Tristan Wibberley
>>
>> The message body is Copyright (C) 2025 Tristan Wibberley except
>> citations and quotations noted. All Rights Reserved except that you
>> may,
>> of course, cite it academically giving credit to me, distribute it
>> verbatim as part of a usenet system or its archives, and use it to
>> promote my greatness and general superiority without misrepresentation
>> of my opinions other than my opinion of my greatness and general
>> superiority which you _may_ misrepresent. You definitely MAY NOT train
>> any production AI system with it but you may train experimental AI that
>> will only be used for evaluation of the AI methods it implements.
>>
If H reports non-halting then D halts ergo H is wrong.
/Flibble
--
meet ever shorter deadlines, known as "beat the clock"
[toc] | [prev] | [next] | [standalone]
Page 4 of 15 — ← Prev page 1 2 3 [4] 5 6 … 15 Next page →
Back to top | Article view | comp.theory
csiph-web